DialogBox als Hauptfenster

Halihalo!
seit einem halben Jahr zirka benutze ich schon DialogBox um die Hauptfenster meiner Anwendungen zu erstellen, weil ich da nur DialogBox aufrufen muss und den rest mache ich im Ressource Editor, und nachrichtenschleife wird auch von alleine implementiert usw. und klappt ganz gut. Mein Kollege meinte aber heute dass sowas blödsinn ist weil es ein modaler Dialog ist und dass es oft zu Fehlern käme. Muss ich wirklich beim Hauptfenster CreateDialog oder CreateWindow aufrufen? Bei mir klappt DialogBox auch super

dein kollege isn trottel der keine ahnung hat. dialog ist geil.

Martin Richter

Kommt darauf an was man will. Wenn ein Dialog alles macht was Du willst.

Sobald aber menüs und und Toolbars ins Spiel kommen würde ich keine Dialoge als Basis nehmen.

Ich habe gar keine Applikationen mehr die Dialog basierend sind. Wenn sind die meisten davon mittlerweile Wizards geworden.

Martin Richter schrieb:

Kommt darauf an was man will. Wenn ein Dialog alles macht was Du willst.

Sobald aber menüs und und Toolbars ins Spiel kommen würde ich keine Dialoge als Basis nehmen.

Ich habe gar keine Applikationen mehr die Dialog basierend sind. Wenn sind die meisten davon mittlerweile Wizards geworden.

gar keine martin? aber wenn man ein kleines tool mache, wo man nur 2 buttons braucht, ist dialog doch das beste. machst du da ein eigenes kompliziertes fenster für?

*rT*f*Ct

wenn du dir deine eigenen klassen auf basis der WinApi erstellst, ist da gar nix mehr kompliziert...
dein handlungsspielraum ist nur größer fals aus dem kleinen prog, doch was größeres werden sollte.

@rT!f@Ct schrieb:

wenn du dir deine eigenen klassen auf basis der WinApi erstellst, ist da gar nix mehr kompliziert...
dein handlungsspielraum ist nur größer fals aus dem kleinen prog, doch was größeres werden sollte.

häh aber mein dialog braucht nur 2 knöppe artifakt. was soll ich dann da größeres draus mache?? häh..

Elektronix

Die Frage ist doch schon beantwortet: Solange Dein Dialog tut, was Du willst, und der Funktionsumfang Deinen Anforderungen genügt, spricht nichts gegen die Dialog-Methode.

Eigene Fensterklassen sind halt flexibler und bei größeren Projekten schneller erstellt. Mehr ist's nicht.

Tatache ist nur: Das Zusammenklicken im Resourcen-Editor und das Ausfüllen einer WNDCLASSEX-Struktur brauchen meiner Ansicht nach die gleiche Zeit. Und eine CALLBACK-Funktion brauchst Du auch in beiden Fällen. Ich sehe da also keinen großen Unterschied.

ok danke, und noch was anderes ich hab mit meinem Kollegen drüber geredet und er meint dass es zwar geht aber sinnlos wäre, da man WM_PAINT nicht in DialogBox benutzen darf. Wieder nur blödsinn?

rofl dein kollege ist ein b00n

in diesem Thread wird aber folgendes von Martin Richter geschrieben:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-244816-and-highlight-is-animatewindow.html

"Allerdings ist es absoluter Unfud in einer DialogProc WM_PAINT zu behandeln!
Technisch unmöglich. Eine DialogProc ist eben keine WndProc."

Aber mit CreateWindow() muss man dann doch auch alle Controls manuell im Code erstellen, da wird man doch dumm bei.

es kann uns wohl nur Martin Richter sagen, was er damit meinte.

*rT*f*Ct

lol0r@lol0r schrieb:

Aber mit CreateWindow() muss man dann doch auch alle Controls manuell im Code erstellen, da wird man doch dumm bei

wenn du jedesmal wieder von vorne anfängst, kann ich deine meinung durchaus verstehn.

aber aus diesem grund gibt es ja zum beispiel klassen und die vererbung.

wenn du es geschickt anstellst, erstellst du dir eine klasse die die allgemeinen fensterfunktionen verwaltet. unteranderem auch CreateWindow, CreateWindowEx...

diese klasse vererbst du dann an eine klasse die speziell auf das jeweilige kontrol zugeschnitten ist.
ab diesen zeitpunkt hast du dann mit einer einzigen funktion ein control erstellt

Ja, und das genaue arritieren der Controls, damit es nach was aussieht? Per Hand, genau, bei einer komplexen UI... have fun!

Ich meine: Entweder Dialog Editor oder besser: UI System selbst schreiben (Ownerdrawn, Editor, ..)

Martin Richter

Ich weiß nicht was Euch an meiner Äußerung bzgl. DalogProc und WndProc interessiert.
1. Kann man einen Dialog als Child Window in jedem Fenster hosten.
2. WM_PAINT kann nur einmal behandelt werden und dies geschieht in der WindowProc. Man kann WM_PAINT nicht einmal vernünftig subclassen durch die BeginPaint/EndPaint Problematik.

Martin es gibt aber keine WindowProc weil der Dialog das einzige Fenster in der Anwendung ist. Dann ist WM_PAINT zu bearbeiten ok oder?

Martin Richter

wiexec schrieb:

Martin es gibt aber keine WindowProc weil der Dialog das einzige Fenster in der Anwendung ist. Dann ist WM_PAINT zu bearbeiten ok oder?

Nein! Dann muss man den Dialog subclassen, WM_PAINT selber behandeln und die Standard WndProc nicht aufrufen.

verstehe ich nicht, es gibt keine standard Window Proc da der Dialog das einzige Fenster ist

winexec schrieb:

verstehe ich nicht, es gibt keine standard Window Proc da der Dialog das einzige Fenster ist

doch die standard wnd proc namens DefaultWindowProc meint Martin.

durch das return TRUE; am Ende von WM_PAINT wird die Def Wnd Proc sowieso nicht aufgerufen -.-

winexec schrieb:

durch das return TRUE; am Ende von WM_PAINT wird die Def Wnd Proc sowieso nicht aufgerufen -.-

omg