www.mikrocontroller.net

Forum: PC-Programmierung Win32 Api und OOP


Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@zwieblum
Klar, MFC ist mir ein Begriff, ich persönlich mags aber überhaupt nicht. 
Dann lieber Win32 API ;)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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ß :)

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> > 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_t...
(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-...
(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.

Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
QT = GUI

wozu sollen da die anderen dinger drinnen sein?

Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Gast0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann auch Console-Anwendungen erstellen. Allerdings vermute ich, 
dass die dann trotzdem relativ groß sind. Wenn das aber irrelevant ist- 
warum nicht?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.