[C++] Programma in c++ e GUI con WPF: è possibile?

[ingframin]

Buon giorno,
stamattina, mi stavo domandando se ci fosse un modo facile per fare un'interfaccia grafica con WPF da "appiccicare" su un programma in C++.
Al momento le uniche possibilità che vedo è:
1) usare C++/CLI
2) Fare una o più dll in C++ e caricarle con un piccolo wrapper per managed unmanaged e menate varie...
3) fare due processi separati e distinti: Un core in C++ che gira in background e una gui in C# che "chiama" il processo in background in C++ (che è lunga come strada ma sicuramente la meno cervellotica)

Alternative?
Onestamente viste le mie doti di GUI designer (:cry: :muro: ) mi dispiacerebbe abbandonare WPF per cose come WxWidgets o Qt.

[AllerITA]

La butto la, forse sarò ovvio hai provato con l'interoperabilità fra COM e .NET,
qui ecco una breve guida da MSDN:

Introduction to COM Interop (http://msdn.microsoft.com/en-us/library/kew41ycz(v=VS.71).aspx)

COM Interoperability in Visual Basic and Visual C# (http://msdn.microsoft.com/en-us/library/e7a79b4y(v=VS.71).aspx)

[nico159]

Non credo ci siano alternative oltre quelle elencate, e tra le 3 la migliore a mio avviso è l'ultima

Anche nel caso volessi portare la tua app su Mac OS X, Linux, Android, iOS...;)

Quali sono i motivi che ti fanno preferire WPF a Qt?

[vendettaaaaa]

Buon giorno,
stamattina, mi stavo domandando se ci fosse un modo facile per fare un'interfaccia grafica con WPF da "appiccicare" su un programma in C++.
Al momento le uniche possibilità che vedo è:
1) usare C++/CLI
2) Fare una o più dll in C++ e caricarle con un piccolo wrapper per managed unmanaged e menate varie...
3) fare due processi separati e distinti: Un core in C++ che gira in background e una gui in C# che "chiama" il processo in background in C++ (che è lunga come strada ma sicuramente la meno cervellotica)

Alternative?
Onestamente viste le mie doti di GUI designer (:cry: :muro: ) mi dispiacerebbe abbandonare WPF per cose come WxWidgets o Qt.
Io avevo optato per la seconda possibilità, ci sarei riuscito se le librerie C++ (esterne) che linkavo nel mio progetto C++ nativo (scritto da me) non avessero richiesto l'uso di MFC per alcuni MessageBox...col risultato che non compilava :muro:
Però fare il wrapper managed mi era sembrata una soluzione molto elegante. Ma non portabile, come dice nico.

[ingframin]

Non credo ci siano alternative oltre quelle elencate, e tra le 3 la migliore a mio avviso è l'ultima

Anche nel caso volessi portare la tua app su Mac OS X, Linux, Android, iOS...;)

Quali sono i motivi che ti fanno preferire WPF a Qt?

Devo fare una piccola applicazione che si interfaccia con un database e che girerà solo su windows.

Non ho nessuna esigenza di portabilità. Siccome non ho requisiti temporali stringentissimi volevo sfruttare l'occasione per imparare un po'di C++.
Solo che su win WPF mi sembra quasi imbattibile come interfaccia grafica, ma soprattutto ho notato quanto è facile da usare.
Ho provato a compilare un'applicazione che usa WxWidgets da windows ed è un incubo...
(cosa che in Ubuntu a casa mi ha richiesto penso 15 secondi :-/ ).
Io trovo incredibile il fatto che Microsoft da una parte punta a C++ e dall'altra si "dimentica" di portare uno dei framework meglio riusciti della storia proprio a questo linguaggio :eek:

[nico159]

Devo fare una piccola applicazione che si interfaccia con un database e che girerà solo su windows.

Non ho nessuna esigenza di portabilità. Siccome non ho requisiti temporali stringentissimi volevo sfruttare l'occasione per imparare un po'di C++.
Solo che su win WPF mi sembra quasi imbattibile come interfaccia grafica, ma soprattutto ho notato quanto è facile da usare.
Ho provato a compilare un'applicazione che usa WxWidgets da windows ed è un incubo...
(cosa che in Ubuntu a casa mi ha richiesto penso 15 secondi :-/ ).
Io trovo incredibile il fatto che Microsoft da una parte punta a C++ e dall'altra si "dimentica" di portare uno dei framework meglio riusciti della storia proprio a questo linguaggio :eek:
Hai provato Qt? Offrono anche un loro IDE che funziona nativamente anche su Windows, quindi senza nessun problema "e mo come compilo tutto questo"

Io ho usato Qt tramite Python e l'ho trovato semplice nell'utilizzo, poi a te la scelta finale :D

Non è che Microsoft si dimentica, è che .Net non si è evoluto come le sperenza interne a MS
.Net fu pensato per diventare l'unico ambiente di programmazione supportato da MS, qualcosa che avrebbe dovuto inglobare tutti gli altri (vedi C++/Cli, IronPython, IronRuby...)
WPF è stato creato per offrire un tassello in più a questa visione interamente "managed", non è pensato per essere utilizzato da altro che non sia .Net

Poi WPF ha rivelato dei grossi problemi prestazionali in parte sistemati negli anni, lo stesso .Net non ha mai brillato in prestazioni ed alla fine MS da ricreare tutta la shell di Windows in .Net e WPF...è passata a Windows 8 Runtime
MS aveva pensato anche ad un OS interamente managed

La realtà dei fatti è che internalmente a MS .Net non ha avuto i consensi sperati, accusato di essere troppo lento per i bisogni delle altre divisioni (Windows prima di tutte)
Inoltre nel frattempo MS da pensare "al desktop del futuro" se ne è uscita con quella cosa che è Windows 8...dove pare che non ci sia più spazio per app complesse ma solo cose da tablet :)

In Windows 8 Runtime si vedono i nuovi piani di MS, dove .Net non è altro che uno dei vari ambienti di sviluppo insieme a Javascript e C++
Il team Windows ha preso direttamente il controllo della cosa ed ha creato in C/C++ quello che doveva essere fatto da .Net, creando così un set di api come dicono loro "nativo e performante"

Il sogno di avere un OS interamente managed è morto, l'idea di avere un Windows con shell interamente managed in WPF è morto, Silverlight è morto, XNA è morto...

Morale della storia chi è "rimasto" a scrivere app desktop si dovrà accontentare di un lavoro mai completato e forse anche folle

Dubito che a questo punto MS farà altri investimenti importanti per lo sviluppo desktop, lasciando il mercato a soluzioni come Qt . ma quest'ultimo è solo un mio pare

[[Kendall]]

Hai provato Qt? Offrono anche un loro IDE che funziona nativamente anche su Windows, quindi senza nessun problema "e mo come compilo tutto questo"

Io ho usato Qt tramite Python e l'ho trovato semplice nell'utilizzo, poi a te la scelta finale :D

Non è che Microsoft si dimentica, è che .Net non si è evoluto come le sperenza interne a MS
.Net fu pensato per diventare l'unico ambiente di programmazione supportato da MS, qualcosa che avrebbe dovuto inglobare tutti gli altri (vedi C++/Cli, IronPython, IronRuby...)
WPF è stato creato per offrire un tassello in più a questa visione interamente "managed", non è pensato per essere utilizzato da altro che non sia .Net

Poi WPF ha rivelato dei grossi problemi prestazionali in parte sistemati negli anni, lo stesso .Net non ha mai brillato in prestazioni ed alla fine MS da ricreare tutta la shell di Windows in .Net e WPF...è passata a Windows 8 Runtime
MS aveva pensato anche ad un OS interamente managed

La realtà dei fatti è che internalmente a MS .Net non ha avuto i consensi sperati, accusato di essere troppo lento per i bisogni delle altre divisioni (Windows prima di tutte)
Inoltre nel frattempo MS da pensare "al desktop del futuro" se ne è uscita con quella cosa che è Windows 8...dove pare che non ci sia più spazio per app complesse ma solo cose da tablet :)

In Windows 8 Runtime si vedono i nuovi piani di MS, dove .Net non è altro che uno dei vari ambienti di sviluppo insieme a Javascript e C++
Il team Windows ha preso direttamente il controllo della cosa ed ha creato in C/C++ quello che doveva essere fatto da .Net, creando così un set di api come dicono loro "nativo e performante"

Il sogno di avere un OS interamente managed è morto, l'idea di avere un Windows con shell interamente managed in WPF è morto, Silverlight è morto, XNA è morto...

Morale della storia chi è "rimasto" a scrivere app desktop si dovrà accontentare di un lavoro mai completato e forse anche folle

Dubito che a questo punto MS farà altri investimenti importanti per lo sviluppo desktop, lasciando il mercato a soluzioni come Qt . ma quest'ultimo è solo un mio pare

In realtà però questa mi sembra una visione decisamente pessimistica e in parte fuorviante della situazione attuale della piattaforma .NET.
Sinceramente credo che attualmente, in ambito programmazione desktop in ambiente windows, non vi sia alcuno strumento paragonabile alla piattaforma .NET e che questa sia lungi dall'essere messa da parte dalla Microsoft.

Riguardo alla questione performance, è sempre stato un argomento molto dibattutto. Ovviamente per performance particolarmente spinte il C++ è una scelta quasi obbligata, ma è questo il caso di una applicazione desktop? Nel 95% dei casi secondo me no.
Basti pensare che software complessi come lo stesso Visual Studio sono scritto in .NET (e con l'ausilio proprio delle WPF come framework grafico) ed hanno performance molto valide.
Altro esempio di software comune scritto sotto .NET? MusicBee (a mio modo di vedere il miglior player gratuito in circolazione, spanne sopra a quella porcata di iTunes che pure è scritta in C++ e Objective-C).

[nico159]

;39548229']In realtà però questa mi sembra una visione decisamente pessimistica e in parte fuorviante della situazione attuale della piattaforma .NET.
Sinceramente credo che attualmente, in ambito programmazione desktop in ambiente windows, non vi sia alcuno strumento paragonabile alla piattaforma .NET e che questa sia lungi dall'essere messa da parte dalla Microsoft.

Riguardo alla questione performance, è sempre stato un argomento molto dibattutto. Ovviamente per performance particolarmente spinte il C++ è una scelta quasi obbligata, ma è questo il caso di una applicazione desktop? Nel 95% dei casi secondo me no.
Basti pensare che software complessi come lo stesso Visual Studio sono scritto in .NET (e con l'ausilio proprio delle WPF come framework grafico) ed hanno performance molto valide.
Altro esempio di software comune scritto sotto .NET? MusicBee (a mio modo di vedere il miglior player gratuito in circolazione, spanne sopra a quella porcata di iTunes che pure è scritta in C++ e Objective-C).
Se tu vedi futuri investimenti in .Net lato desktop da parte di Microsoft, meglio così

Sono d'accordo che per una app desktop tipica avere delle performance al top sia secondario, ma un conto è dire "Ok, offriremo anche .Net" come stanno facendo da Windows 8 ed un altro è dire "Dovete scrivere i vostri software in .Net, è il futuro per chi scrivere app su Windows"
Visual Studio è un insieme di più linguaggi e sistemi, non mi stupirei di sapere che in .Net sono scritte parti come l'interfaccia grafica, mentre viene lasciato in C++ parti più pesanti come l'analisi del codice
L'azienda che produce ReSharper, plugin famoso per chi programma in .Net, ha dovuto migrare da C# a C++ per l'analisi del codice in ReSharper 7, perchè .Net era troppo lento

Comunque non è questo il luogo per dire ".Net è il futuro/.Net ormai è solo uno delle tante cose che fa MS, non è più una tecnologia chiave"
Era più una analisi sul perchè WPF non è stato pensato per essere usato da altro che non .Net, del perchè il Windows 8 Runtime non è in .Net, della "rinascita del codice nativo" e l'apertura a Microsoft all'ambiente HTML5 come ambiente entry level (di cui prima Visual Basic era il riferimento), dell'abbandono di progetti come Silverlight e XNA

La mia opinione in tutto questo, è visto come MS ha cambiato radicalmente idea (Windows Store! Windows 8 con app castrate!...) sperare in una rinascita del desktop da loro non lo vedo plausibile
Se vuoi usare WPF, è stato pensato per essere usato da C#/VB.Net - C++/Cli non è certo un gran modo per imparare C++, almeno secondo me

Quindi? Affidarsi ad aziende esterne ed usare toolkit come Qt che ti permettono di usare normale C++ su Windows, in un ambiente di facile utilizzo e ben documentato e sopratutto sempre in continuo sviluppo e miglioramento
Poi ad ognuno le sue scelte :cool:

Inoltre questa discussione è nata dal voler usare WPF fuori da .Net - Se usi già .Net su desktop non vedo motivo di porsi queste questioni