UI für C++/Win32
-
audacia schrieb:
Das Problem ist nun, daß ich nicht länger umhinkomme, mein Projekt mit Visual C++ zu übersetzen, weil ich gerne Drittbibliotheken benutzen würde, die den alternden C++Builder-Compiler überfordern.
Das Problem ist mir nicht ganz unbekannt.
Xin schrieb:
Bei mir in der Firma wird noch MFC Software gewartet, daher durfte ich mich im Verlauf des letzten Jahres in MFC ein wenig einarbeiten.
"Nicht vergnügungssteuerpflichtig."
Auch das ist mir nicht unbekannt. An MFC-Kenntnissen kommt man aber kaum vorbei, da wir eine Reihe von Zulieferen haben, die meinen ihre Demoprogramme als MFC-Dialoganwendungen liefern zu müssen. Daher muss man oft zumindest MFC-Code lesen und verstehen können.
Xin schrieb:
audacia schrieb:
[*]WinForms: Managed Code => Brücken bauen erforderlich; wird nicht mehr weiterentwickelt zugunsten von WPF; großer Drittkomponentenmarkt
Das ist bei uns das Mittel der Wahl, um von MFC weg zu kommen.
Wir sind damals von der VCL zu Windows Forms gewechselt, WPF war damals (2003) noch kein Thema.
Mit dem Gluecode zwischen .net und C++ haben wir relativ wenig Arbeit, zuerst war das PInvoke zu C-Schnittstellen, heute ist es C++/CLI. Allerdings ist die Software von vornherein dazu ausgelegt, mit unterschiedlichen Oberflächen verwendet zu werden. Die Architektur hat quasi eine "Wespentaile", nur dort taucht sehr wenig C++/CLI auf. Die Arbeit mit diesen kombinierten C# und C++ Projekten geht in Visual Studio erstaunlich konsistent, auch beim Debuggen. Auch sind wir relativ problemlos auf neue Visual Studio Versionen umgestiegen.
Mittlerweile haben wir auch einige WPF-Clients geschrieben, richtig warm geworden bin ich damit aber noch nicht. Außerdem ist momentan etwas unklar, in welche Richtung sich das entwickelt.
Als mögliches zusätzliches Modell deuten sich mittlerweile WinRT-Apps an, die mit dem lokal oder remote als normale Anwendung laufenden C++ Teil kommunizieren.
Ob das als brauchbare Vorlage für die Umstellung von typischen VCL-Anwendungen taugt, kann ich nicht sagen. Oft sind die sehr "kopflastig" mit sehr viel Logik in irgendwelchen Komponenten.
[Nachtrag:]
Ein Brückenbau von der VCL zu VC++ müsste wohl entweder über ein C-API oder COM gehen, beides halte ich für deutlich größere Brüche, als ein Weg über C++/CLI.
Für richtige Borland Fans gäbe es noch die OWLNext, die Fortführung des VCL-Vorgängers. Die habe ich mal unter VS 2008 gesehen, sah gar nicht so schlecht aus. Eigene Erfahrungen habe ich da aber nicht mehr mit seit 1995.
-
Danke soweit für die Antworten.
Xin schrieb:
wxWidgets habe ich nur mal kurz unter Python probiert und das ging gut.
Ich kann mir vorstellen, daß die Python-Bindings angenehm sind - aber das C++-API soll auch prähistorisch sein.
Xin schrieb:
Die "Brücken" werden mit selbstgeschriebenen Python-Skripts generiert.
Schön ist was anderes.Sowas werde ich mir auch ggf. überlegen müssen. Vielleicht mit Hilfe eines C++-Compilers, der mir erlaubt, meinen eigenen Code zu parsen und Wrapper zu generieren (sollte mit Clang möglich sein).
Xin schrieb:
Ich würde wxWidgets und wxGrid erforschen, ob es für Deine Fälle reicht.
Danke, werde ich tun.
nn schrieb:
[...] Daher muss man oft zumindest MFC-Code lesen und verstehen können.
Daran scheitert's nicht, das habe ich schon öfter getan - aber selber schreiben müssen will ich ihn vielleicht doch lieber nicht.
nn schrieb:
Als mögliches zusätzliches Modell deuten sich mittlerweile WinRT-Apps an, die mit dem lokal oder remote als normale Anwendung laufenden C++ Teil kommunizieren.
Das ist einer der Gründe, die mich noch davon abhalten, meine VCL-Komponenten und Teile des bestehenden Interfaces nach irgendwohin zu portieren. Momentan bedeutet C++Builder/VCL für mich Stillstand; aber wer weiß, ob man nicht in ein paar Jahren ohnehin ein WinRT-Interface braucht, dann war die ganze Mühe der Portierung vergebens. Also vielleicht lieber ein paar Jahre funktionierender Stillstand als redundante Arbeit
nn schrieb:
Ob das als brauchbare Vorlage für die Umstellung von typischen VCL-Anwendungen taugt, kann ich nicht sagen. Oft sind die sehr "kopflastig" mit sehr viel Logik in irgendwelchen Komponenten.
Nein, die Trennung von UI und Code ist schon einigermaßen sauber, das war mir immer wichtig. Außerdem gab es ja mal, wie bereits erwähnt, ein C#/WinForms-Frontend - das es aber nie weit gebracht hat.
nn schrieb:
Ein Brückenbau von der VCL zu VC++ müsste wohl entweder über ein C-API oder COM gehen, beides halte ich für deutlich größere Brüche, als ein Weg über C++/CLI.
Das ist insofern richtig, als daß ich mit zwei IDEs arbeiten müßte; außerdem ist die C++/CLI-Unterstützung in VS 2012 ja wieder besser geworden. Aber beim Bridging mit C++/CLI muß ich alle Interfaces und zudem alle Value-Types duplizieren - einmal das native C++-Interface, einmal ein CLR-kompatibler Wrapper -, beim Bridging via COM reicht es, wenn ich das C++-Interface COM-kompatibel halte. Außerdem bliebe mir das Marshalling erspart.
Eine "Wespentaillen-Schnittstelle" gibt es auch bereits, und für die habe ich auch noch die C++/CLI-Bridge herumliegen, aber sowas wird für das UI, das ich im Sinn habe, nicht ausreichen. Ich will dem Benutzer große Kontrolle über die Einzelheiten des Prozeßablaufes geben (via Skripting und über einen visuellen Editor), so daß die Schnittstelle notgedrungen etwas breiter werden wird.
Wenn ich einen Weg finde, die Bridge-Generation zu automatisieren, würde der Unterschied vernachlässigbar. Allerdings bin ich immer noch nicht überzeugt, daß WinForms ein gutes Ziel ist, denn dort herrscht genauso Stillstand wie bei der VCL.
-
audacia schrieb:
Allerdings bin ich immer noch nicht überzeugt, daß WinForms ein gutes Ziel ist, denn dort herrscht genauso Stillstand wie bei der VCL.
Ich denke auch, dass das in deiner Situation kein sinnvoller Schritt wäre.
Mit dem Schreiben von COM-Komponenten mit der ATL habe ich mich auch schon mal beschäftigt, damals gab es sogar brauchbare Bücher dazu (Inside ATL und etwas deutsches von Addison Wesley). Neuerungen auf diesem Gebiet sind aber sehr gut in der MSDN versteckt.
-
Fakt: Qt verwendet unter Windows sehr wohl native
Widgets/Controls[edit] Zeichenroutinen (uxtheme.dll) [Danke an audacia][/edit]. [1], [2]Warning: This style is only available on the Windows Vista platform because it makes use of Windows Vista's style engine.
Irgendwann
früher war es mal anders, aber schon lange ist es so.Imho ist Qt auch ziemlich angenehm zu benutzen, auf jeden Fall finde ich es viel besser als wxWidgets, und gegenüber WinForms glänzt es mit Layout-Klassen, die bei ersterem nur *sehr*, sagen wir..., rudimentär sind. MFC und WTL kenn ich nicht, bei VCL gibt es afaik auch keine ordentlichen Layouts (nur dieses Anchor und Dock Zeugs).
-
Oberon_0 schrieb:
Fakt: Qt verwendet unter Windows sehr wohl native Widgets/Controls.
Nein, tut es nicht. Qt benutzt die Theme-Engine des Betriebssystems (uxtheme.dll), um die Controls zu zeichnen, aber es benutzt nicht die zugehörigen Fensterklassen, sondern implementiert das Verhalten der Controls selbst, was wiederum zu Unstimmigkeiten führt.
-
Ah, ok. Das erklärt warum die Fensterklasse immer als QWidget angegeben ist.
Aber welchen relevanten Unterschied macht das schon? Gut, die Message-Boxen u.ä. sind Englisch, wenn man vergisst die Qt-eigene Übersetzung einzubinden. Aber die Widgets selbst verhalten sich, soweit ich das beobachten konnte ziemlich nativ, z.B. Highlighting des aktiven Buttons, des mit der Maus überfahrenen Buttons, ...
Mir wär noch kein unerwartetes Verhalten aufgefallen, im Gegensatz zu GTK+ (Gimp).Aber technisch hat du offenbar recht.
-
Oberon_0 schrieb:
Aber welchen relevanten Unterschied macht das schon? [...] Mir wär noch kein unerwartetes Verhalten aufgefallen, im Gegensatz zu GTK+ (Gimp).
Es macht durchaus einen Unterschied, und ich finde es sehr augenfällig bei den meisten Qt-Anwendungen, die ich benutze; aber das ist nicht Thema meines Threads.
-
Deine Probleme sind auch mir nicht unbekannt. In Windows Forms würde ich persönlich kein neues Projekt mehr beginnen, und auch WPF wird wohl keine großen Neuerungen mehr erfahren.
Hierzu möchte ich mal auf einen Artikel verweisen: Plaudereien über das Windows 8 geschuldete Ende von Silverlight und WPF (heise).
Meiner Meinung nach gibt es eigentlich nur folgende sinnvolle Wege:
- Verwenden eines möglichst Plattformübergreifenden Frameworks (wie QT) - trotz aller Mankos.
- Umschwenken auf WinRT (Ob mit C++ oder C#...).
- Umschwenken auf .Net mit SL/WPF/WinRT-Option, da spätestens mit VS2012 auch noch eine einigermaßen angenehme Möglichkeit der shared-dlls gegeben wurde, so das man den gemeinsamen Kram in eine DLL packen kann (Und gerade SL/WPF/WinRT mit MVVM einiges "teilen").
So richtig froh bin ich über keinen Weg, bei uns wird die letzte Option wohl der wesentliche Schritt sein. Vermutlich mit WinRT als erste (und vielleicht auch einzige - je nach Arbeitsaufwand) UI, aber der Option z.B. auch noch WPF für den klassischen Desktop auf weitgehend der gleichen Codebasis mit ins Boot zu holen. Logik wird hinter Services verborgen, so das irgendwann auch z.B. ASP.Net noch denkbar wäre.
Fakt ist: Egal was man derzeit tut, durch die massiven Umbrüche muss man mit den einen oder anderen Kompromiss leben. Da unsere (*hust*) Entwicklerkapazitäten (+Parallele Weiterentwicklung des Altcodes) aber eh dafür sorgen werden das wir wohl erst mit Windows 9 etwas brauchbares liefern können, wäre wohl WinRT nicht die schlechteste mögliche Wahl.
-
asc schrieb:
und auch WPF wird wohl keine großen Neuerungen mehr erfahren.
Naja:
http://msdn.microsoft.com/en-us/library/bb613588.aspxAber das ist off-topic. WPF ist ein anderes Thema.
asc schrieb:
Hierzu möchte ich mal auf einen Artikel verweisen: Plaudereien über das Windows 8 geschuldete Ende von Silverlight und WPF (heise).
Alles, was da in bezug auf Win8-Kompatibilität steht, bezieht sich aber auf die Metro-Oberfläche und betrifft den Desktop nicht. Und ich glaube nicht, daß der Desktop so schnell irrelevant wird.
WinRT-UI geht nicht, da nicht für XP/Win7 verfügbar und insbesondere nicht auf dem Desktop benutzbar.
asc schrieb:
Meiner Meinung nach gibt es eigentlich nur folgende sinnvolle Wege: [...]
Nett gemeint, aber off-topic. Es ist momentan völlig unabsehbar, wohin sich die Windows-Plattform entwickelt, welche Rolle Metro und Desktop spielen werden etc. Meine erklärte Absicht ist, mit den gegebenen Restriktionen eine Windows-Desktop-Anwendung zu schreiben.
-
Interessant zu hören, dass MFC immer noch sinnvoll eingesetzt werden kann. Das Grundprinzip ist ja auch nicht schlecht, nur bei komplexen Steuerelementen wird es leicht gruselig.
http://henkessoft.de/C++/MFC/MFC Tutorials.htm