Jetzt mal Klartext: Warum ist die Winapi tot und wo ist die Alternative?!
-
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
-
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.
-
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 1wie 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?
-
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 einMFC 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.
-
@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...
-
@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!
-
@wxwindows anscheinend gibt es keine möglichkeit einen dialog ohne einen frame anzuzeigen(siehe samples)... wenn mans trotzdem macht stürzt das programm beim beenden ab
wenn ein framework schon am anfang mit dermaßen seltsamen einschränkungen kommt... is für mich gestorben@gtkmm warum bemühen die sich nich mal um ne einfache einrichtung aller komponenten unter windows? die sagen nur dasses ned so einfach wär ... und fertig. unter linux isses wahrscheinlich mit n paar befehlen getan... aber des bringt mir nix.
mfc is bis jetzt wohl doch das einzig wahre für c++
-
@gtkmm warum bemühen die sich nich mal um ne einfache einrichtung aller komponenten unter windows? die sagen nur dasses ned so einfach wär ... und fertig. unter linux isses wahrscheinlich mit n paar befehlen getan... aber des bringt mir nix.
Welche Komponenten gehen den nicht?
mfc is bis jetzt wohl doch das einzig wahre für c++
nö, für "C mit Klassen" :p
-
ich bekomms ned mit vc6 zum laufen
kommen nur viele tolle fehler a lac:\programme\gtkmm\gtkmm\include\gtkmm-2.0\glibmm\refptr.h(77) : error C2535: '__thiscall Glib::RefPtr<T_CastFrom>::Glib::RefPtr<T_CastFrom>(const class Glib::RefPtr<T_CastFrom> &)' : member function already defined or declared
c:\programme\gtkmm\gtkmm\include\gtkmm-2.0\glibmm\refptr.h(70) : see declaration of 'RefPtr<T_CppObject>::RefPtr<T_CppObject>'
c:\programme\gtkmm\gtkmm\include\gtkmm-2.0\glibmm\refptr.h(152) : see reference to class template instantiation 'Glib::RefPtr<T_CppObject>' being compiledgibts ne anleitung die sich auf vc6 bezieht?
-
http://cvs.gnome.org/lxr/source/gtkmm-root/base/MSVC_Net2003/README
aber mit dem VC6 geht das AFAIK nicht, weil der den C++ Standard viel zu schlecht unterstützt.