Jetzt mal Klartext: Warum ist die Winapi tot und wo ist die Alternative?!

[wxer]

Sovok schrieb:

ich hab mir die alternativen zwar angeschaut... aber besonders toll fand ich bisher keine... wxwindows hätte mir ganz gut gefallen wenn die sizer-boxen nich wären

Ich verwende schon länger wxWindows und mag diese dummen SizerBoxen - wie es sie auch in GTK+ gibt - ebenfalls nicht. Aber unter wxWindows hat man - im Gegensatz zu GTK+ - die Möglichkeit auch ohne diese dummen SizerBoxen zu arbeiten. Schau dir mal das Programm "VisualWx an". Damit ist es fast so einfach, wie mit dem Borland C++ Builder.

MFC ist tot.
WINAPI liegt im sterben.
.NET ist Müll.
GTK+ ist umständlich.
Qt ist zu teuer.
VCL ist genial, liegt aber auch im sterben.

[rüdiger]

meinst du das sog. Packaging?

Dann bist du schlecht informiert. Es gibt auch in GTK (und GTKmm) eine Möglichkeit Widgets absolut zu platzieren

Gtk::Fixed

(Aber Packaging ist doch eigentlich eher ein Vorteil :))

(btw. in der aktuellen Ausgabe der FreeX findet man eine kurze GTKmm Einführung)

[Sovok]

dieses packaging is zwar in der theorie n vorteil aber man brauch 5mal solang um nen dialog fertigzubekommen
besonders übel isses wenn man mehr als 30 controls in einem dialog hat...
vielleicht is es aber auch geschmacksache, für leute die auf tabellenlayouts in html stehn

ich hol mir jetzt mal das visualwx, aber ohne die ms klassen gehts bei mir eh ned weil wohl kein anderes framework CComPtr,COleVariant,CComBSTR und CString gekapselt hat oder?

[Marc++us]

Die COM-Sachen gehören zur ATL, nicht zur MFC. Insofern kannst Du diese auch ohne die MFC-Libs verwenden.

Nur mit CString wird's schwierig, das ist echt MFC. Aber wg. einer Stringklasse würde ich keine MFC verwenden (also will sagen: nur wg. CString wäre mir das zu aufgebläht).

[Sovok]

hab auch ms klassen gesagt nich mfc
das schöne an denen is halt, dass die konstruktoren und operatoren kompatibel sind
dadurch lässt sich richtig schön kompakter com/directx code schreiben

[nman]

kingruedi: Wobei die GNOME-Leute auch gerne mal ein paar Interfaces ändern etc; siehe bonobo & Co.
Sovok: Also wenn Du 30 Controls in einem Dialog hast machst Du sowieso was falsch.

[Sovok]

@nman nö ich mach nix falsch... is nur ein hilfstool für das eigentliche programm, nix für enduser
muss aber trotzdem schnell gehn

@wxer
visualwx build:
d:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe: cannot find -lwxmsw
mingw32-make.exe: *** [Project.exe] Error 1

wie mach ich mingw den lib pfad von wx bekannt?

[rüdiger]

nman schrieb:

kingruedi: Wobei die GNOME-Leute auch gerne mal ein paar Interfaces ändern etc; siehe bonobo & Co.

aber das macht unter Linux nichts, da ich da zu not die alten Librarys noch installieren kann. Es geht mir ja nicht um die Änderung an sich, ansonsten wär ich ja ein Fortschritts Feind und hätte wohl auch nichts gegen die MFC.

Sovok schrieb:

wie mach ich mingw den lib pfad von wx bekannt?

der GCC hat die Option -L um Library-Pfade anzugeben. Aber wahrscheinlich kannst du das auch in eine Umgebungsvariable packen oder irgend wie anders machen. Die Doku hilft

[Walli]

Marc++us schrieb:

Nur mit CString wird's schwierig, das ist echt MFC. Aber wg. einer Stringklasse würde ich keine MFC verwenden (also will sagen: nur wg. CString wäre mir das zu aufgebläht).

AFAIK haben die das CString-Interface in der neuen MFC behalten und dahinter einen ATL-String gepackt. Also müsste CString doch auch unabhängig von den MFC verwendbar sein.

[der_held]

der GCC hat die Option -L um Library-Pfade anzugeben. Aber wahrscheinlich kannst du das auch in eine Umgebungsvariable packen oder irgend wie anders machen. Die Doku hilft

Ja, aber guck mal, was gemeldet wurde:

d:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe: cannot find -lwxmsw

[rüdiger]

@der_held
und wo stimmt das nicht mit dem überein, was ich gesagt habe?

[der_held]

Bin ich Blöd? der sagt doch, das die mit -l angegebene wxmsw nicht gefunden wird.

[rüdiger]

trotzdem verstehe ich dein problem nicht. Ich hab ihm doch gesagt, wie er das lösen kann.

[nman]

kingruedi schrieb:

aber das macht unter Linux nichts, da ich da zu not die alten Librarys noch installieren kann. Es geht mir ja nicht um die Änderung an sich, ansonsten wär ich ja ein Fortschritts Feind und hätte wohl auch nichts gegen die MFC.

Meinte ich ja auch nicht, aber wenn Du Dir zB ansiehst wieviel Zeit das Galeon-Team mit der - zweifelsohne längst überfälligen - Umstellung auf libegg versch... hat ist das schon beachtlich.

[Sovok]

ach ich benutz lieber gleich vc++ zum kompilieren... visualwx is in dem punkt zu unausgereift

komisch is, dass sich wxwindows beim schließen eines nichtmodalen dialogs der in wxapp::oninit mit new erstellt wurde(ganz nach der doku) in der windows user dll aufhängt (aufhägt im sinne von ohne meldung stehenbleiben)

wenn man exakt den selben code auf ein wxframe anwendet funktioniert es

ne andere sache is... wen man in dem ersten dialog nen zweiten nichtmodalen erstellt, is der zweite mit der maus nicht ansprechbar... hmmm

das einzige was bisher gut funktioniert hat, is die erstellung eines modalen dialogs in oninit im mfc stil mit false als rückgabe

[Marc++us]

MaSTaH schrieb:

Marc++us schrieb:

Nur mit CString wird's schwierig, das ist echt MFC. Aber wg. einer Stringklasse würde ich keine MFC verwenden (also will sagen: nur wg. CString wäre mir das zu aufgebläht).

AFAIK haben die das CString-Interface in der neuen MFC behalten und dahinter einen ATL-String gepackt. Also müsste CString doch auch unabhängig von den MFC verwendbar sein.

Meines Wissens ist es sogar noch komplizierter - wenn Du MFC im Projekt verwendest, kommt CString aus der MFC, wenn Du nur ATL verwendest aus der ATL. Die schalten das irgendwie über #define um... das Interface ist immer gleich.

[wxer]

Sovok schrieb:

@wxer
visualwx build:
d:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe: cannot find -lwxmsw
mingw32-make.exe: *** [Project.exe] Error 1

wie mach ich mingw den lib pfad von wx bekannt?

Die Lib-Pfade sind bei einer normalen Installation eigendlich alle korrakkt.
Hast du im Dev-Cpp/lib-Ordner eine Datzei namens libwxmsw.a?

[Prof84]

Konkreter schrieb:

Hi,

ich weiß so langsam nicht mehr wie es weitergehen soll ! Andauernd lese ich hier das mfc tot ist, winapi, borland. Was wird denn als Ersatz kommen?

Well, let me finish you up in this way:

http://www.gulp.de/robot/seek.html
Gib mal mit oder-Verknüpfung ein

MFC ATL win32% windows2000 windowsNT windows 9%

Und ich wette, dass in 5 Jahren immer noch 30% aller Unternehmensnetzwerke
NT-basiert sein werden. Wahrscheinlich wird es MFC, win32, VCL oder ATL genau so gehen wie COBOL, zwar total veraltet, aber man kommt wegen der Quantität nie richtig davon weg.

[rüdiger]

@Prof
Natürlich wird die Technology, die über Jahre benutzt wurde, von heute auf morgen verschwinden. Das sieht man ja nicht nur an COBOL, sondern auch daran, dass MS seine Pläne Win98-Support einzustellen aufgeben musste, nach Kunden Protesten. Aber trotzdem lohnt es sich IMHO nicht mehr in den Bereich einzusteigen, da in Zukunft andere Wege gegangen werden. Wenn Longhorn kommt, werden die meisten WinAPI und MFC Projekte nur Erweiterung und Wartung bestehender Software sein. Also wird das Auftrags-Potential nach und nach zurückgehen und das bei dem Vorhanden Wissen/Können in dem Bereich.

COBOL Programme sind ja auch noch überall vorhanden und trotzdem denke ich nicht, dass es einen hohen Bedarf an COBOL Leuten gibt, da der Martk in dem Bereich wahrscheinlich fest ist.

Wobei COBOL Gegenüber der WinAPI/MFC den Vorteil hat, dass es auch Compiler für neuere Systeme gibt. Wenn es das nicht gäbe, hätten wahrscheinlich viele Firmen in den sauren Apfel beissen müssen und das System komplett neu schreiben müssen. Nun tut sich die Frage auf, ob es Anpassungen der MFC/WinAPI auch für neuere Systeme geben wird...

[Prof84]

@king:
Die Frage ist IMHO nicht, ob sich bestimmte Frameworks oder Libaries von modernen Systemen assimilieren lassen werden. Denn das ist eine Sichtweise, die man nur in der reinen Applikationsentwicklung teilen kann. Die meisten Unternehmenslösungen sind hetrogene Systementwicklungen, die sich in Regelfall selten gleichzeitig upgraden werden lassen - auch mit J2EE nicht :D. Das hat zur Folge, dass Bedienungskomfort und Entwicklungserleichterungen eingetauscht werden gegen steigende Komplexität und (mitarbeiter)technische Ansprüche.

Aber warum nörgel?!
Auf das es für immer so bleibe!