Framework, die qual der wahl

Flow_cplus

Hi

Ich bin gerade auf der suche, nach irgendeiner Möglichkeit, meine Benutzeroberflächen für Programme einfach zu erstellen.
Bis jetzt hab ich immer hauptsächlich, nur funktional-programmiert und 'mit hand', also pure winapi, nur ein paar steuerelemente angelegt.
So mit qt hab ich mal ein bißchen was gemacht, gtk und wx mal angeschaut. Passt aber alles nicht so ganz, weil ich erstens nicht plattformunabhänig sein will (naja würde normal auch nicht stören aber) zweitens möchte ich weiterhin ein paar Fenster mit der Winapi erstellen, also möchte ich nach wie vor in der winmain und der msgloop rumschreiben und eigene winprocs erzeugen können, ohne das ich auf die Framework angewiesen bin. Auf der anden Seite will ganz einfach Graphisch ein Fenster mit Steuerelementen erzeugen können, und dann nur an den entsprechenden stellen der Code einfügen.

Kann mir jemand ein paar tipps geben, was ich da am besten verwende, oder ist so wie ich mir das vorstell nicht so ganz möglich?
(Achso Sprache ist C/C++)

Mfg
Flow

Headhunter

Zusammenfassend:
Du möchtest ein Framework verwenden das am Besten nicht plattformunabhängig ist, trotzdem möchtest du weiter mit den Winapi Funktionenen arbeiten.

Was soll das?
Plattformunabhängig ist fast jedes Window Toolkit, das merkst du aber nicht
wenn du nur auf Windows arbeitest.
Hey, du willst dieses Feature nicht? Ignoriere es!

Und Winapi + Toolkit mischen klingt doch schon nach böse und vielen Fehlernmöglichkeiten.
Tus nicht! (Wenns überhaupt geht)

Bis jetzt hab ich immer hauptsächlich, nur funktional-programmiert und 'mit hand', also pure winapi, nur ein paar steuerelemente angelegt.

Kann es sein das du nicht weißt was "funktional programmieren" heißt?

@Flow_cplus: Nimm ATL/WTL.

cu

Sgt. Nukem

schrieb:

Bis jetzt hab ich immer hauptsächlich, nur funktional-programmiert und 'mit hand', also pure winapi, nur ein paar steuerelemente angelegt.

Kann es sein das du nicht weißt was "funktional programmieren" heißt?

Kam mir auch als erstes in den Sinn... :p

Flow_cplus

Headhunter schrieb:

Was soll das?
Plattformunabhängig ist fast jedes Window Toolkit, das merkst du aber nicht
wenn du nur auf Windows arbeitest.
Hey, du willst dieses Feature nicht? Ignoriere es!

Aber soweit wie es bis jetzt gesehen habe, ist bei Plattform-unabhänigen Toolkits nicht wirklich möglich noch in der winmain rumzumachen. Ansonsten sagte ich ja schon, es wäre egal.

Fehleranfällig, mmh, kann schon sein, muss aber nicht. Ich möchte das ja schön getrennt halten, nur möchte ich weiter in in Winmain ein paar ganznormale Fenster erstellen können, nicht mit der basis eines Toolkits oder so.
So viel kann da eingentlich nicht so viel schief gehen, die einen haben mit den anderen ja nicht viel zu tun.

achso funktional Programmieren ... ich denke es hat schon jeder verstanden was ich so oben gemeint habe. sloppy :-), ich weiß.

ChockoCookie

Du kannst schon WinAPI Funktionen in einem Programm benutzen, in dem du ein ein anderes GUI Toolkit verwendest. Nur nicht solche, die selber etwas mit GUI zu tun haben, spich einen HWND oder HDC brauchen. Wenn du ein Toolkit mit WinAPI GUI Funktionen (was für ein Graus) mischen willst, müsstest du die Quelltexte des Toolkits so Patchen, das du Zugriff auf den HWND eines Fenster erhalten kannst und damit arbeiten. Sowas könntest du am ehesten mit wxWidgets machen, da das nur ein dünner Layer um native Widgets des jeweiligen OS ist, dh. jeder Button ua. wird von Windows verwaltet. Bei allen anderen Toolkits dürfte das eher nicht gehn, da diese ein eigenes Widgetset haben. Dh. alles unterhalb des Hauptfensters wird von dem Toolkit selbst erzeugt und hat mit WinAPI nix mehr zu tun. Aber auch vom Patchen der wxMSW.dll (der Layer zwischen deinem wxWidgets Programm und der WinAPI) würde ich dir abraten. Wenn du ein Fenster mit nem Toolkit und ein anderes mit der WinAPI erstellen willst, bräuchtest du AFAIR nur den jeweiligen HINST deines Programmes. KA ob du den mit einer Funktion der WinAPI, oder auch nur durch Patchen des Toolkits herausfinden kannst (Programmiere seit längerem nur mehr wxWidgets, sehr zu empfehlen). Ich weis ja nicht, was du für ein Problem mit der WinAPI hast. Wenn es der Stil ist (wie bei mir, abgesehen von der unportabilität), dann kannst du ja MFC antesten, die haben so einen ähnlichen Stil wie wxWidgets (eigentlich hat wx ihn von MFC). Aber generell sind sowohl die MFC als auch WinAPI zum sterben verurteilt, Microsoft setzt jetzt nur mehr auf .NET und die alten APIs werden nur noch zwecks Kompatibilität mitgeschleppt, aber nicht mehr entwickelt. Wenn du jetzt was neu lernst, solltest du .NET lernen. Das gibt es auch (noch eingeschränkt) unter Linux (Mono). Ich bleib lieber bei meinem Hersteller - und Plattformunabhängigen wxWidgets.

Flow_cplus

mmh, also dass ich winapi funk nutzen kann in einer Framework, mit den gennanten einschränkungen is klar. sowas wx etc zu patchen, werde ich lieber lassen.
Wahrscheinlich löse ich es einfach so, das ich einfach zwei Programme erstell eins mittels Framework und eins mittels winapi, und dann lass ich das Framework Progamm einfach per post/sendmessage, alles(button klick, hacken hier etc..) ans andere schicken.

rüdiger

Es gibt doch von Microsoft so einen Thin-Layer über die WinAPI, der neulich sogar als OpenSource veröffentlicht wurde.

Kenn mich damit zwar nicht aus, aber WTL hiess der und Thin-Layer sollte ja heissen, dass du da auch ohne probleme an der WinAPI rumwurschteln kannst.

fallen

aber warum willst du eigentlich ein plattformunabhängiges toolkit nutzen UND im selben programm mit der winapi kuscheln? find ich an sich leicht abwegig.... und wenn ich mir so mal wx anschau (mit den andern hatte ich noch nie was zu tun) dann frag ich mich warum das denn nötig ist, die frameworks bringen doch eigentlich alles nötige mit...

fallen schrieb:

aber warum willst du eigentlich ein plattformunabhängiges toolkit nutzen UND im selben programm mit der winapi kuscheln?

mmh, also ich sagte schon ich will kein plattformunabhängiges toolkit nutzten, nur Plattfomunaghänigkeit stört nunmal überhaupt nicht.

Das Problem ist, ich hab einige Programme soweit fast fertig, benutzteroberfläche fehlt noch. Wenn ich jetzt auf ein Toolkit umsteige müsste fast alles von Grund auf neu schreiben, .. keine Lust :-).

Ich werde mir jetzt mal die wtl anschauen, mit der docu schauts da bloß net so toll aus