Hallo allerseits! Mich beschäftigt gerade die Frage, wie Ihr Anwendungen mit C++ und der Win32 API schreibt. Klar, man kann einfach tausende globale Handles,structs etc nutzen, alle Funktionen global machen und im WndProc alle Ereignisse verarbeiten. Das Problem ist nur, dass ab einer bestimmten Programmgröße die Übersichtlichkeit verloren geht (von den anderen OO-Prinzipien mal ganz zu schweigen). Wie macht ihr das? Versucht ihr einen OO-Entwurf für euer Projekt zu erstellen, was sich mit C++ anbietet, oder programmiert ihr einfach C-like? Und wenn ihr oo-programmiert, wie weit geht ihr da? Also für jeden Button, jede Bitmap etc. eine eigene Klasse oder ist das zuviel Aufwand/Overhead? Man will (kann) ja nicht gleich ein eigenes Framework schreiben, aber einfach alles als globale Variablen o.ä zu deklarieren kanns ja auch nicht sein. Gruß Gast0815
Ich kenns nur von Linux, da wird es sicherlich ähnlich verlaufen: Die allermeisten Programmierer werden sich fertiger Bibliotheken bedienen... Bei deinem Beispiel: Was ist denn ein 'Bitmap'? Nur ein Vektor mit Rohdaten? Oder willst du dann (mal wieder...) das Rad und eine Bildbearbeitungsbibliothek neu erfinden?
wenn ich mich recht erinnere ksnnst du beim öffnen eines fenters extrabytes anfordern, die du dann mmit applikationsdaten - etwa zeiger auf objekt o.ä. - füllen kannst. aber die windows api arbeitet c-konform. deshalb gabs dann mal mfc und ähnliche wraper, die das ganze mehr oder weniger objektorientiert aubereitet haben.
Nein, ich will bestimmt keine Bildbearbeitungsbibliothek erstellen. Um bei dem Beispiel Bitmap zu bleiben: Es geht eher darum, dass wenn ich einfach nur eine Grafik darstellen will, ich ein Handle für die Bitmap und eine BITMAP-struct brauche. Um sie zu zeichnen, muss dann einmal ein LoadBitmap-Aufruf erfolgen, um sie mit Daten zu füllen und dann bei der Paint-Message ein BitBlt Aufruf. Das sieht für mich so aus, als würde sich das Erstellen einer Klasse lohnen, in deren Konstruktur dann automatisch eine entsprechende Resource/Datei geladen wird. Die Daten könnten als private-Member gespeichert sein und die Aufrufe in Methoden gepackt, so dass man sich eine Menge Tipp-Arbeit sparen könnte. Es gibt da bestimmt noch ein paar windows-spezifische Dinge zu beachten. Analog dann das Verfahren für Dialoge. Anstatt für jedes GUI-Element ein globales Handle, das Ganze in einer Klasse kapseln und die notwendigen Funktionen zur Verfügung stellen.
@zwieblum Klar, MFC ist mir ein Begriff, ich persönlich mags aber überhaupt nicht. Dann lieber Win32 API ;)
OK. Wenn du MFC nicht magst, ist das ein Argument. Obwohl die MFC, wenn auch nicht toll, immer noch um Längen besser ist als direkt an die C-API zu gehen. Aber es gibt ja auch noch andere Klassenbibliotheken. Solche Bibliotheken schreibt man nicht selbst sondern benutzt eine Fertige. Das hat dann auch den Vorteil, dass man das Rad nicht neu erfinden muss, dass die einzelnen Klassen der Bibliothek auch miteinander können, dass man von vorneherein schon mit einer (einigermassen) fehlerfreien Bibliothek arbeiten kann und sich auf seine Anwendung und nciht auf das Erstellen einer Bibliothek konzentrieren kann und zu guter letzt: es gibt Tutorien dafür wie man so eine Bibliothek einsetzen kann. Google mit "Windows GUI Library" sollte mit einigen brauchbaren Bibliotheken hochkommen. Hast du Qt schon ausprobiert? > Mich beschäftigt gerade die Frage, wie Ihr Anwendungen mit C++ und > der Win32 API schreibt. Klar, man kann einfach tausende globale > Handles,structs etc nutzen, alle Funktionen global machen und im > WndProc alle Ereignisse verarbeiten. Das macht heute kein Mensch mehr. Viel zu langsam in der Entwicklung, viel zu fehleranfällig. Been there, done that; Microsoft gepriesen als die MFC herauskam.
Karl heinz Buchegger (kbuchegg) (Moderator) wrote: >> Mich beschäftigt gerade die Frage, wie Ihr Anwendungen mit C++ und >> der Win32 API schreibt. > Das macht heute kein Mensch mehr. Viel zu langsam in der Entwicklung, > viel zu fehleranfällig. Been there, done that; Microsoft gepriesen als > die MFC herauskam. Die nativen Win32 Programme waren aber noch schön schlank, schnell in ihrer Ausführung und laufen auch heute noch unter einem alten Win9x. Während ein mit dot net kompiliertes "Zwischencode Programm" gar nicht mehr zur Ausführung kommt, weil sich die Laufzeitumgebung erst gar nicht mehr installieren lässt.
> Die nativen Win32 Programme waren aber noch schön schlank, schnell in > ihrer Ausführung und laufen auch heute noch unter einem alten Win9x. Und sind grauenhaft zu warten. Wie Karl Heinz schon sehr treffend sagte, been there, done that. Never again. Und die Kompatibilität zu einem lausigen instabilen 16/32-Bit-Frickelsystem hat mich noch nie interessiert. Das .net-Geraffel mag ich allerdings auch nicht.
> Und sind grauenhaft zu warten. Wie Karl Heinz schon sehr treffend sagte, > been there, done that. Never again. War dem Erfolg von Windows abträglich? Mitnichten! > Und die Kompatibilität zu einem lausigen instabilen > 16/32-Bit-Frickelsystem hat mich noch nie interessiert. na kommm, die Vokabel "Frickelsystem" ist doch bereits vergeben :) > Das .net-Geraffel mag ich allerdings auch nicht. jaja, ich weiß :)
@Gast0815: das nutzt nix. die win32api ist C und nicht C++. wennst da C++ drüberstülpen willst, viel spaß, aber der aufwand lohnt nicht.nimm dir lieber wx oder fltk.
Gast schrieb: >> Und sind grauenhaft zu warten. Wie Karl Heinz schon sehr treffend sagte, >> been there, done that. Never again. > > War dem Erfolg von Windows abträglich? Mitnichten! O doch. Erst mit der Einführung von C++-Compilern und mehr oder weniger brauchbaren Klassenbibliotheken bzw. von Alternativprodukten (Visual Basic, Delphi) wurde der Markt für Windows-Anwendungen wirklich attraktiv. Ich habe ausreichend viel Zeit mit dem Windows-SDK verbracht, auch schon zu Windows 3.0-Zeiten, und etwas später mit dem Umstieg auf 32-Bit mit NT 3.1 ... und ich habe mich mit diesem unübersichtlichen Gekröse nie anfreunden können. Reinen SDK-Anwendungen sieht man deren Herkunft auch oft deutlich an: An den GUI-Richtlinien vorbeiprogrammiert, hässliche Dialoge, merkwürdige Toolbars veraltete Standarddialoge etc. (Beispiele: TeraTerm oder GsView oder viel aus dem Unix/Linux-Lager her stammendes). > na kommm, die Vokabel "Frickelsystem" ist doch bereits vergeben :) Und passt hier auch wie der Arsch auf den Eimer. Windows 95 und der nachfolgende Rotz hätte nie sein müssen.
Ok, danke für die Beiträge. Ich hab gerade entdeckt, dass es Qt auch für Windows Mobile gibt. Von daher ist für mich klar, dass ich in die Richtung gehen werde. Mit Qt hab ich gute Erfahrungen gemacht, war aber bis eben der Meinung, dass Qt Mobility bis jetzt nur für Nokia-Systeme erhältlich ist. Wie gesagt, der Grund überhaupt nochmal die win32-api anzupacken war, dass ich momentan für windows mobile entwickle. Ich kann Rufus nur zustimmen, die Entwicklung mit dieser api ist sehr zeitintensiv und die Ergebnisse sind optisch nicht unbedingt ansprechend. Allerdings hat sie auch einen gewissen "Charme".
>> War dem Erfolg von Windows abträglich? Mitnichten! > O doch. Erst mit der Einführung von C++-Compilern und mehr oder weniger > brauchbaren Klassenbibliotheken bzw. von Alternativprodukten (Visual > Basic, Delphi) wurde der Markt für Windows-Anwendungen wirklich > attraktiv. Und deswegen existiert die Win32 API trotzdem (weiter). Tatsache ist, MS hat mit der Win32 API keine Bauchlandung gemacht, sonst gäbe es sie schon lange nicht mehr. Aber wie sieht das denn mit dem damals auch so gepriesenen (angeblich viel besseren) OS/2 aus? Wie erfolgreich waren die denn? Warum soll(te) es auch nicht ein Visual BASIC geben? Es bestand immer schon ein Bedarf nach einem leichten Einstieg in die Windows Programmierung, ohne sich mit der Kompliziertheit der Fenster-Erstellung mittels der API zu befassen. Und was Delphi betrifft, das war die logische Weiterentwicklung von Turbo Pascal für Windows. Das mag den Windows Markt beschleunigt haben (da dürfen wir aber auch die MFC nicht unerwähnt lassen), aber welchen Stellenwert das jeweils hat oder hatte, das müsste man erst mal genauer in Erfahrung bringen. > Ich habe ausreichend viel Zeit mit dem Windows-SDK verbracht, auch schon > zu Windows 3.0-Zeiten, und etwas später mit dem Umstieg auf 32-Bit mit > NT 3.1 ... und ich habe mich mit diesem unübersichtlichen Gekröse nie > anfreunden können. Mir war das was Petzold in seinem Standard Werk veröffentlicht hat viel eher eingängig als die ganze Kapselung durch die MFC. > Reinen SDK-Anwendungen sieht man deren Herkunft auch oft deutlich an: An > den GUI-Richtlinien vorbeiprogrammiert, hässliche Dialoge, merkwürdige > Toolbars veraltete Standarddialoge etc. (Beispiele: TeraTerm oder GsView > oder viel aus dem Unix/Linux-Lager her stammendes). Naja, schau dir mal die alten Dialoge an die von Turbo Pascal bzw. Delphi herrühren, da erkennst du auch immer schön Borland heraus. ;) (ein grünes Häkchen im OK und ein rotes Kreuzchen im Cancel oder so ähnlich) Ich hab übrigens gerade die original Borland Handbücher von TP für Windows vor mir liegen. Wollte sie schon wegschmeißen, bringe es aber nicht übers Herz. ;) >> na kommm, die Vokabel "Frickelsystem" ist doch bereits vergeben :) > Und passt hier auch wie der Arsch auf den Eimer. na wenn du halt diesen Begriff hier ins Spiel bringst :) > Windows 95 und der nachfolgende Rotz hätte nie sein müssen. Damit willst du doch hoffentlich nicht sagen, Windows 3.x war das beste Windows (das du kennst)? Qt wäre vielleicht noch eine Alternative für den Fragesteller.
Gast schrieb: > Die nativen Win32 Programme waren aber noch schön schlank, schnell in > ihrer Ausführung und laufen auch heute noch unter einem alten Win9x. MFC Programme sind auch nicht soooo wahnsinng groß und laufen auch auf Win9x immer noch sehr gut. > Während ein mit dot net kompiliertes "Zwischencode Programm" gar nicht > mehr zur Ausführung kommt, weil sich die Laufzeitumgebung erst gar nicht > mehr installieren lässt. Igiit. Sowas greif ich erst gar nicht an.
Gast0815 schrieb: > Wie gesagt, der Grund überhaupt nochmal die win32-api anzupacken war, > dass ich momentan für windows mobile entwickle. Ich hasse es das zu sagen. Aber für Windows Mobile würde ich dir tatsächlich C# mit .Net empfehlen. Hab das mal probiert. Das ging tatsächlich ziemlich problemlos. Ein paar Abstriche muss man im .Net machen, aber sonst ganz brauchbar.
Die Frage ist, wieviel Aufwand ist es, sich in C# einzuarbeiten. Es geht hier um ein einzelnes Projekt, und ich kenne C++ und Qt bereits.
Gast schrieb: > Und deswegen existiert die Win32 API trotzdem (weiter). Logo. MS kann die nicht einfach über Bord schmeissen. Da steht schon alleine das Kompatibilitätsargument dagegen. MS würde sich ins eigene Fleisch schneiden, wenn sie das Grundprinzip ändern würden. > Aber wie sieht das denn mit dem damals auch so > gepriesenen (angeblich viel besseren) OS/2 aus? Wie erfolgreich waren > die denn? Das hat keine technischen Gründe. Marketing rules. Die meisten Entwickler die ich kenne hätten viel lieber OS/2 gehabt. Aber was solls, keine Firma entwickelt OS/2 Programme für die sie langwierig Kunden suchen müssen, wenn ihnen die Leute die Telefone mit der Frage nach Windows Programmen heiß laufen lassen. Linux hat(te) dasselbe Problem. Wer entwickelt schon kommerziell Programme, wenn es keinen Kundenstock dafür gibt. > Warum soll(te) es auch nicht ein Visual BASIC geben? Ich behaupte, VB war ein extrem wichtiges Standbein um den Markt mit Windows Programmen regelrecht zu fluten. > Es > bestand immer schon ein Bedarf nach einem leichten Einstieg in die > Windows Programmierung, ohne sich mit der Kompliziertheit der > Fenster-Erstellung mittels der API zu befassen. Das ist auch mit einer Klassenbibliothek nicht allzu kompliziert. So schnell wie man mit MFC einen Dialog hoch hat ... kein Vergleich zur SDK Methode. Und in VB geht alles noch einen Tisck schneller. > Mir war das was Petzold in seinem Standard Werk veröffentlicht hat viel > eher eingängig als die ganze Kapselung durch die MFC. Ist Gewohnheitssache. Mann muss das ganze Konzept der Windows Procedure über Bord werfen und dem Wizard vertrauen, dass er den entsprechenden Handler schon richtig einbauen wird (zumindest am Anfang). Dann wird auch die MFC relativ komfortabel und das Event-Konzept greift ganz gut. (Der neue Class Wizard im VS ist für MFC Programmierer meiner Meinung nach eine Zumutung. Das war in VC++ 6.0 noch um 3 Klassen besser) > Naja, schau dir mal die alten Dialoge an die von Turbo Pascal bzw. > Delphi herrühren, da erkennst du auch immer schön Borland heraus. ;) > > (ein grünes Häkchen im OK und ein rotes Kreuzchen im Cancel oder so > ähnlich) Die konnte ich nie leiden. War mit ein Grund warum ich das nie benutzt habe. > An den GUI-Richtlinien vorbeiprogrammiert Und interessanterweise war Microsoft mit unter den ersten, die ihre eigenen Designrichtlinien aber sowas von ignoriert haben :-)
Karl heinz Buchegger (kbuchegg) (Moderator) wrote: > MFC Programme sind auch nicht soooo wahnsinng groß und laufen auch auf > Win9x immer noch sehr gut. Stimme ich zu. > Igiit. Sowas greif ich erst gar nicht an. :)) na so schlecht kanns doch auch wieder nicht sein > Aber für Windows Mobile würde ich dir tatsächlich C# mit .Net empfehlen. > Hab das mal probiert. Das ging tatsächlich ziemlich problemlos. Ein paar > Abstriche muss man im .Net machen, aber sonst ganz brauchbar. na siehste, Karl-Heinz, geht doch (hehe)
Gast0815 schrieb: > Die Frage ist, wieviel Aufwand ist es, sich in C# einzuarbeiten. Es geht > hier um ein einzelnes Projekt, und ich kenne C++ und Qt bereits. Auch das hasse ich zuzugeben: Hab mir in der Buchhandlung ein Werk zu C# geholt. Nach einem Nachmittag hatte ich das erste Programm lauffähig. OK, das war noch sehr primitiv, aber immerhin. Die Portierung auf die Mobile-version war (fast) ein Kinderspiel. Denn eines muss man zugeben: das .Net Framework ist schon sehr gut aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut und Rüben.
Karl heinz Buchegger (kbuchegg) (Moderator) wrote: > Gast schrieb: >> Und deswegen existiert die Win32 API trotzdem (weiter). > Logo. MS kann die nicht einfach über Bord schmeissen. Da steht schon > alleine das Kompatibilitätsargument dagegen. MS würde sich ins eigene > Fleisch schneiden, wenn sie das Grundprinzip ändern würden. Und eben gerade die Kompatibilität wurde MS auch immer wieder indirekt vorgeworfen (Stichwort: alten 16-bit Code weiterhin unterstützen; die API hatte dann zwei Versionen bei ihren Funktionsaufrufen, sieht man schön im alten Win32api Help File). >> Aber wie sieht das denn mit dem damals auch so >> gepriesenen (angeblich viel besseren) OS/2 aus? Wie erfolgreich waren >> die denn? > Das hat keine technischen Gründe. Marketing rules. Die meisten > Entwickler die ich kenne hätten viel lieber OS/2 gehabt. Ja wie so oft. Das vermeintlich (oder wegen mir auch wirklich) bessere muss noch lange nicht als "Sieger" hervorgehen. > Aber was solls, > keine Firma entwickelt OS/2 Programme für die sie langwierig Kunden > suchen müssen, wenn ihnen die Leute die Telefone mit der Frage nach > Windows Programmen heiß laufen lassen. Linus hat(te) dasselbe Problem. > Wer entwickelt schon kommerziell Programme, wenn es keinen Kundenstock > dafür gibt. Also bei Linux frage ich mich in der Tat wie sich manche da über überhaupt Wasser halten können. Aber ich frage mich ehrlich gesagt auch schon lange, wer überhaupt die vielen Linux-Zeitschriften noch kauft, angesichts der vielen freien Informationen im Netz. Früher als man noch auf Heftbeilagen der Distris angewiesen war hab ich mir die auch immer gerne gekauft. Seit DSL ist's obsolet. >> Warum soll(te) es auch nicht ein Visual BASIC geben? > Ich behaupte, VB war ein extrem wichtiges Standbein um den Markt mit > Windows Programmen regelrecht zu fluten. Ja um VB gab es einen richtigen Hype. Mir war da mein altes Turbo Pascal eingängiger (allerdings noch DOS). Habe dann die geschwätzige Sprache Pascal zu gunsten TC 3.x (auch noch DOS) links liegen gelassen. :) (dann MS Produkte ..). >> Es >> bestand immer schon ein Bedarf nach einem leichten Einstieg in die >> Windows Programmierung, ohne sich mit der Kompliziertheit der >> Fenster-Erstellung mittels der API zu befassen. > Das ist auch mit einer Klassenbibliothek nicht allzu kompliziert. So > schnell wie man mit MFC einen Dialog hoch hat ... kein Vergleich zur SDK > Methode. Das war ja immer der Punkt. Natürlich geht das alles schnell, besonders mit Klick auf den Assistenten. Dann fing das aber an kompliziert zu werden. Die Nachrichtenschleife war zerhackt und es hagelte lauter " TODO: Add your command handler code hear" Fragmente. Das war im Petzold alles übersichtlicher (wie ich finde). Die MFC macht sich erst "bezahlt" wenn die Programme länger werden. Zum kennen lernen und Programmiereinstieg fand ich das Klassenkonzept eher verwirrend (aus der Sicht des Programmier-Einsteigers in Windows Applikationen; später sieht man das anders). > Und in VB geht alles noch einen Tisck schneller. ei jo >> Mir war das was Petzold in seinem Standard Werk veröffentlicht hat viel >> eher eingängig als die ganze Kapselung durch die MFC. > Ist Gewohnheitssache. Mann muss das ganze Konzept der Windows Procedure > über Bord werfen und dem Wizard vertrauen, dass er den entsprechenden > Handler schon richtig einbauen wird (zumindest am Anfang). Dann wird > relativ komfortabel und das Event-Konzept greift ganz gut. Der Punkt war, man musste gleichzeitig OOP-Code (Klassen-Konzept) UND Win32-API Funktionen lernen. C konnte man bereits, da war der Petzold einem halt näher. >> Naja, schau dir mal die alten Dialoge an die von Turbo Pascal bzw. >> Delphi herrühren, da erkennst du auch immer schön Borland heraus. ;) >> >> (ein grünes Häkchen im OK und ein rotes Kreuzchen im Cancel oder so >> ähnlich) > Die konnte ich nie leiden. War mit ein Grund warum ich das nie benutzt > habe. Da gab es ein schönes Layout Programm namens Protelm dem man seine Herkunft ansah. Das hat eigentlich schön funktioniert. ;) >> An den GUI-Richtlinien vorbeiprogrammiert > Und interessanterweise war Microsoft mit unter den ersten, die ihre > eigenen Designrichtlinien aber sowas von ignoriert haben :-) ei jo
Karl heinz Buchegger (kbuchegg) (Moderator) wrote: > Denn eines muss man zugeben: das .Net Framework ist schon sehr gut > aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst > einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut > und Rüben. bring das mal deinem Mod Kollegen Rufus' bei :-)
Also das Win32 API ist für C. Für C++ hat Microsoft den MFC Wrapper geschrieben, der genau das tut, was du sagst: Er baut "für jeden Button, jede Bitmap etc. eine eigene Klasse". Damit kannst du dein Programm schon mal vergessen, nur Idioten programmieren so. Wer vernünftig programmiert, macht es generisch, d.h. es ist egal wie viele Elemente im Dialog sind, die Dialogfunktion bleibt möglichst gleich. Es spricht alles dafür, MFC nicht zu verwenden, denn Win32 Funktionen kann man auch direkt von C++ aufrufen. Einzige Ausnahme: Wenn man OLE realisieren muß. Da helfen die MFC-Klassen. Rufus schreibt: "Reinen SDK-Anwendungen sieht man deren Herkunft auch oft deutlich an: An den GUI-Richtlinien vorbeiprogrammiert, hässliche Dialoge, merkwürdige Toolbars veraltete Standarddialoge etc. (Beispiele: TeraTerm oder GsView oder viel aus dem Unix/Linux-Lager her stammendes)." und merkt gar nicht, wie falsch er hier liegt. Gerade SDK Anwendungen sehen nicht aus wie irgendwoher, und gerade SDK Anwendungen sind sehr GUI konform. Rufus schreibt auch sonst viel Unsinn, Karl heinz weist schon auf seine Unkenntnis von DotNET hin, welches wirklich sehr geradlinig und gut designt ist, leider politisch als "Microsoft's Antwort auf Java" verschissen und hat das gleiche-DDLs-in-verschiedenen-Versionen echt krank gelöst. Wenn du unter Mobile entwickeln sollst, achte darauf, daß das Win32 API dort anders ist als unter Win32 :-( man kann Programme nicht einfach von XP nach Mobile nehmen und gleichen Code verwenden. Da man aber Programme sowieso in einen Teil der die Oberfläche definiert und einen Teil der die Daten verarbeitet (und auch ohne Oberfläche z.B. fernsteuerbar ist) aufteilt, ist es nicht so schwer, die Unterschiede in der GUI-Schicht so zu programmieren, daß es unter beiden läuft. Ob ich zu Qt für Mobile raten würde? Ein klares nein. Die Anwendung sieht scheisse aus, schleppt Zeugs mit sich rum welches der Anwender nicht haben will, und ist inkompatibel. Zudem musst du Qt für Nokia debuggen.
Karl heinz Buchegger schrieb: > Denn eines muss man zugeben: das .Net Framework ist schon sehr gut > aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst > einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut > und Rüben. Klar, MS hat ja auch den besten und fähigsten Software-Architekten Borlands für teuer Geld abgeworben. Schon traurig, wenn man anscheinend im eigenen Haus niemanden hat, der sowas kann - aber die mussten wahrscheinlich jahrelang mit der Win32 API und MFC arbeiten und waren dementsprechend verdorben. ;-)
Mark Brandis schrieb: > Klar, MS hat ja auch den besten und fähigsten Software-Architekten > Borlands für teuer Geld abgeworben. Wenns nur der wäre :-) MS hat sich auf vielen Gebieten vor einigen Jahren die besten Köpfe eingekauft. Computer Graphik: Jim Blinn, Jim Kajia C++: Herb Suttner (vor Jahren) BS: Dave Cutler und seine Mannschaft ... und noch viele mehr > wahrscheinlich jahrelang mit der Win32 API und MFC arbeiten und waren > dementsprechend verdorben. ;-) LOL
> > Windows 95 und der nachfolgende Rotz hätte nie sein müssen. > > Damit willst du doch hoffentlich nicht sagen, Windows 3.x war das beste > Windows (das du kennst)? Um Gottes Willen, nein. Windows 95 hatte nur zwei(einhalb) Nachfolger, 98 (98SE) und Me. Windows NT gibt es schon bedeutend länger, nur wird es von den Marketingdrohnen von Microsoft alle paar Jahre mal wieder anders genannt. Windows 7 ist Windows NT 7.0. > Dagegen ist MFc wirklich Kraut und Rüben. Das bestreite ich erst recht nicht. MFC ist furchtbar. Ich kenne sie, ich lebe damit. Und ich würde ums Verrecken niemandem dazu raten, sich das anzutun. Da gibt es wirklich bessere Alternativen, gerade auch in Hinblick Plattformunabhängigkeit. Die halte ich für wichtig. > Rufus schreibt: "Reinen SDK-Anwendungen sieht man deren Herkunft > auch oft deutlich an: An den GUI-Richtlinien vorbeiprogrammiert, > hässliche Dialoge, merkwürdige Toolbars veraltete Standarddialoge > etc. (Beispiele: TeraTerm oder GsView oder viel aus dem Unix/Linux- > Lager her stammendes)." > und merkt gar nicht, wie falsch er hier liegt. > > Gerade SDK Anwendungen sehen nicht aus wie irgendwoher, und > gerade SDK Anwendungen sind sehr GUI konform. Die von mir genannten Anwendungen kennst Du? Sicher, Anwendungen, die sich überhaupt nicht um GUI-Richtlinien kümmern, lassen sich auch ganz wunderbar mit VB oder Delphi oder irgendeinem C++-Compiler und dessen Klassenbibliothek zusammenklicken, aber das hat andere Gründe. Sieh Dir genau die beiden von mir erwähnten Anwendungen (TeraTerm und GsView) mal an, und überlege dann, inwiefern die den GUI-Richtlinien entsprechen. > Rufus schreibt auch sonst viel Unsinn, Das kannst Du gerne so sehen, bitte. Ich möchte nur darauf hinweisen, daß ich seit ziemlich langer Zeit mein Geld damit verdiene, Software für Windows zu entwickeln. Und das auch schon zu Zeiten von Windows 3.0 getan habe. > Karl heinz weist schon auf seine Unkenntnis von DotNET hin, > welches wirklich sehr geradlinig und gut designt ist, Daß das Zeug sauber designt sein mag, bestreite ich nicht. Ich mag es einfach nicht. Ich mag keine "garbage collection", ich mag nicht die C++-Sprachvergewaltigung namens "Managed C++" - ja, ich bin halt konservativ.
Rufus t. Firefly schrieb: >> etc. (Beispiele: TeraTerm oder GsView oder viel aus dem Unix/Linux- >> Lager her stammendes)." >> und merkt gar nicht, wie falsch er hier liegt. >> >> Gerade SDK Anwendungen sehen nicht aus wie irgendwoher, und >> gerade SDK Anwendungen sind sehr GUI konform. > > Die von mir genannten Anwendungen kennst Du? Ich hab eigentlich auch diese Erfahrung gemacht. Die schlimmsten Programme waren fast ausschliesslich über die Win32 API geschrieben. Und da nehme ich mich sicherlich nicht aus. Verwundert auch nicht weiter, wenn man weiß, welchen Aufwand man da treiben muss für Dinge, die ein Framework einfach so mitbringt. Allerdings wirst du mir sicherlich zustimmen: Es hilft auch in der MFC Programmierung ungemein, wenn man die zugrundeliegende native API kennt. Soviel zum Thema: Ein Framework abstrahiert die Details weg :-) >> Karl heinz weist schon auf seine Unkenntnis von DotNET hin, >> welches wirklich sehr geradlinig und gut designt ist, Wenn er das so gesehen hat, kann ichs nicht ändern. Es war allerdings keineswegs meine Absicht auf irgendwelche Unkentnis von Seiten Rufus hinzuweisen. Ich kenne Rufus zu lange und weiß, das er mit MFC arbeitet (so wie ich auch). Und höchst wahrscheinlich hat er genauso wie ich auch, in .Net hineingeschnuppert. > Ich mag es > einfach nicht. Ich mag keine "garbage collection", ich mag nicht die > C++-Sprachvergewaltigung namens "Managed C++" - ja, ich bin halt > konservativ. Ein Gesinnungsbruder! Darf ich dich virtuell drücken? PS: Ich mag auch den neuen Ribbon-Style nicht. Das erste was ich bei meinen Vistas mache: GUI zurückschalten auf Classic Style. Die */%"$% bescheuerte automatische Menüpunkte-wandern-ständig-hin-und-her-so-sie-überhaupt-sichtbar-sind-Au tomatik abschalten. Gleich danach kriegt der Explorer den Auftrag, Dateiendungen anzuzeigen (da bin ich dann schon knapp am Blutrausch) und dass er sich seinen linken platzverbrauchenden Teil in die Haare schmieren soll. Wenn er sich dann noch erdreistet (das war aber glaub ich XP und nicht Vista) mich bei einem Wechsel ins Program-Verzeichnis darauf aufmerksam zu machen, dass ich da nicht rein sollte, bin ich soweit, dass ich meinen Chef um ein Flugticket nach Seattle und etwas Geld für eine Pumpgun anflehe.
> Allerdings wirst du mir sicherlich zustimmen: Es hilft auch in > der MFC Programmierung ungemein, wenn man die zugrundeliegende > native API kennt. Das hilft nicht nur, das ist praktisch überlebenswichtig. Ohne die Win32-API zu kennen, kann man nicht verstehen, wie und warum die MFC funktioniert. Und viele MFC-"Programmierer" basteln sich dann entsprechende merkwürdige Programme zusammen. Wenn denn man meint, MFC nutzen zu müssen, dann aber erst nach ausreichenden(!) Arbeiten mit der Win32-API. Den Petzoldt sollte man ein paar Jahre lang als alleinige Lektüre nutzen ... > Ich mag auch den neuen Ribbon-Style nicht. > Das erste was ich bei meinen Vistas mache: GUI zurückschalten auf > Classic Style. Gottlob bin ich "auffe arbeit" noch um Vista & Co. umhingekommen, das aber wird sich in nächster Zeit ändern. "Ribbons" inklusive. Buärks. Mein privates Antidot war die Anschaffung eines Macs.
Karl heinz Buchegger schrieb: >> Während ein mit dot net kompiliertes "Zwischencode Programm" gar nicht >> mehr zur Ausführung kommt, weil sich die Laufzeitumgebung erst gar nicht >> mehr installieren lässt. > > Igiit. Sowas greif ich erst gar nicht an. Eure Konkurrenz schon... http://through-the-interface.typepad.com/through_the_interface/2009/06/creating-fibonacci-spirals-in-autocad-using-f.html (hier allerdings in der dafür besser geeigneten Sprache F#) > Linux hat(te) dasselbe Problem. > Wer entwickelt schon kommerziell Programme, wenn es keinen Kundenstock > dafür gibt. Mittlerweile gibt's Kunden, die meinen, dass auch die Entwicklungskosten sinken, wenn sie *nix vorgeben. Frei nach dem Motto: Ist ja alles Open Source und muss nur noch "zusammengestöpselt" werden... > Denn eines muss man zugeben: das .Net Framework ist schon sehr gut > aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst > einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut > und Rüben. Man sieht dem .NET Framework, zumindest in Teilen und insb. C# an, wer da für die Architektur verantwortlich war: Anders Hejlsberg (Turbo Pascal, Delphi, VCL) Gast schrieb: > Ja wie so oft. Das vermeintlich (oder wegen mir auch wirklich) bessere > muss noch lange nicht als "Sieger" hervorgehen. So wie IBM daran gearbeitet hat, dass es ein Markterfolg wird... > Das war ja immer der Punkt. Natürlich geht das alles schnell, besonders > mit Klick auf den Assistenten. Dann fing das aber an kompliziert zu > werden. Die Nachrichtenschleife war zerhackt und es hagelte lauter " > TODO: Add your command handler code hear" Fragmente. Das war im Petzold > alles übersichtlicher (wie ich finde). Die MFC macht sich erst "bezahlt" > wenn die Programme länger werden. Sagen wir's mal so: Das letzte Stück Software was hier als reine Win32-App entwickelt wurde, wurde das letzte mal 1998 gefixt, ab 1997 d.h. mit dem ersten C++Builder, hatte sich das Thema MFC/Win32 erstmal (zu 99.9%) erledigt. Das fing auch mit einer übersichlichen Nachrichtenschleife an, nachher konnte man es allerdings nicht mehr so bezeichnen... MaWin schrieb: > und hat das gleiche-DDLs-in-verschiedenen-Versionen echt krank gelöst. Besser als im .NET-Framework kann man es fast nicht mehr lösen. Man kann bei jeder DLL/EXE festlegen, welche Versionen es unterstützt bzw. welche Version genau vorausgesetzt wird (Stichworte: requiredRuntime, supportedRuntime, app.config) Karl heinz Buchegger schrieb: > Wenns nur der wäre :-) > MS hat sich auf vielen Gebieten vor einigen Jahren die besten Köpfe > eingekauft. Sun hat sich bspw. sehr viel Know-How für Java "besorgt" (Stichwort: StrongTalk, SavaJe etc.), Apple hat sich so gut wie jedes Know-How eingekauft (NeXt, Emagic, PASemi, MultiTouch mit/von FingerWorks gekauft, Cover Flow (Bspw. Navigation durch die Musik beim iPhone)), IBM hat Lotus, Tivoli, Informix, Rational etc. pp. gekauft. Die Frage ist aber, warum die Leute zu Microsoft gegangen sind. Weil Sun/IBM oder wer auch immer (die fähigsten Apple-Leute sind z.Z. bei Palm inkl Jon Rubinstein) nicht bereit waren genug zu bezahlen, oder gab's bei Microsoft vllt bessere Arbeitsbedingungen... http://channel8.msdn.com/Posts/Du-willst-Karriere-bei-Microsoft-machen/ (ab 2:35 und 6:39 bzw. 8:51 bis zum Ende) > Windows 7 ist Windows NT 7.0. 6.1 :-> Karl heinz Buchegger schrieb: > Ich mag auch den neuen Ribbon-Style nicht. > Das erste was ich bei meinen Vistas mache: GUI zurückschalten auf > Classic Style. Die */%"$% bescheuerte automatische > Menüpunkte-wandern-ständig-hin-und-her-so-sie-überhaupt-sichtbar-sind- > Automatik abschalten. Ich weiß schon gar nicht mehr wie das Classic Style Menü aussieht bzw. wie "Alle Programme" aussieht, Win+"ZIP"+Enter eintippen geht halt schneller, als im Menü das Programm zu suchen. Gleiches gilt für richtige Suchen nach Dokumenten und deren Inhalten.
Also, ich hab mir jetzt Qt für Windows Ce installiert und sogar schon zum Laufen gekriegt. Aber wie implementiere ich mobile-spezifische Sachen, wie GPS-Anbindung und gprs-Verbindung ins Internet? Hat Qt spezielle Klassen dafür(konnte ich bis jetzt noch nicht finden) oder kommt da wieder die Microsoft-API ins Spiel(womit wir ja wieder bei C und den handles wären)? Arbeitet Qt überhaupt mit der API zusammen?
Nein, Qt ist mehr als GUI. Es enthält u.a. Container-Klassen, Algorithmen, Klassen für OpenGl, Kommunikation(z.B Sockets). Ich finde, das macht Qt so interessant - man hat alle Hilfsmittel, die man braucht um Anwendungen entwicklen zu können.
> Ich finde, das macht Qt so interessant - man hat alle Hilfsmittel, die > man braucht um Anwendungen entwicklen zu können. oder es verhindert das man sauber zwischen GUI und Programm logig unterscheidet. Sobald jemand von einem Programm nur noch ein Kommandozeilen programm braucht muss man immer nocht Qt einbinden.
Man kann auch Console-Anwendungen erstellen. Allerdings vermute ich, dass die dann trotzdem relativ groß sind. Wenn das aber irrelevant ist- warum nicht?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.