Strukturbaum/Tree View/Explorer
-
Danke für eure Antworten,
also mit WM_SIZE:
Movewindow....
klappt das! das ist super!kann ich jetzt eigentlich auch ein Fenster im Fenster machen. Wenn ich in der TreeProc() (ist ein childwindow), wieder ein CreateWindowEx in WM_CREATE aufrufe klappt das wieder nicht ganz. wahrscheinlich muss ich wieder WM_SIZE überarbeiten.
Wenn ich allerdings im ChildWindow TreeProc() bei WM_PAINT ein createWindowEx () aufrufe, dann zeigt mir das Fenster die Baumstruktur an, nur ich glaube nicht dass WM_PAINT dafür gedacht ist :), wiederum befindet sich im ersten moment die Baumansicht im hintergrund, erst bei klick auf die Fenstergegend tritt es zum vorschein.
-
Also ich persönlich finde das immer unschön, viele Elemente per CreateWindow zu erzeugen und sich auf dem Papier die Positionen aufzumalen.
Man kann auch gleich alles im Dialogeditor von MSVS erstellen. Du könntest also auf deine linke Seite einen Dialog, der die Treeview, Buttons, etc. enthält, schieben, auf die rechte Seite kommt dann das Textfeld.
Falls die Standardhintergrundfarbe ein Hindernis darstellen sollte, kannst du dir mal die Nachricht WM_CTLCOLORDLG anschauen.
Ich sehe gerade, du hast gar nicht geschrieben, was das für Fenster sein sollen.
-
oh man ich wusste gar nicht das es diese option auch gibt, ich dachte die resource-datei ist auch code, also kann sie zumindest sein.
Jedenfalls hab ich jetzt beispielsweise meinen treeview so erstellt wie du gemeint hast die resource heißt IDD_DIALOGBAR, soweit ok!
wie kann ich diesen treeview jetzt in meinem fenster positionieren und im c-code aufrufen, ich bin noch ziemlich grün hinter den ohren was winapi angeht
verzeiht mir 
ich hab mir gedacht ich rufe im childwindow bei WM_CREATE:
DialogBox(hInst, MAKEINTRESOURCE(IDD_DIALOGBAR), hWnd, Tree);
auf!
nur dann kommen linker fehler
-
Das Problem ist, dass DialogBox einen modalen Dialog erstellt, also einen, mit dem die eigene Anwendung blockiert ist (genau, wie bei Aufruf von MessageBox).
Die Lösung ist CreateDialoghwndDlg = CreateDialog(hInst, MAKEINTRESOURCE(IDD_DIALOGBAR), hWnd, DlgProc);Die Hauptnachrichtenschleife sollte auch noch angepasst werden.
Die angegebene DlgProc verwaltet ihre Elemente selbständig. WM_SIZE kann hier benutzt werden, die Treeview passend innerhalb des Dialogs zu positionieren; wenn sich die Größe des Dialogs aber nie ändert, ist es nicht nötig, sondern kann direkt im Resourceneditor bestimmt werden.
Um das nutzen zu können, muss user32.lib gelinkt werden, was aber standardmäßig der Fall ist.
Edit : Falls der Dialog nicht sichtabr sein sollte, entweder ShowWindow(hwndDlg,SW_SHOW) aufrufen oder gleich im Editor das Flag WS_VISIBLE setzen.
-
der linker fehler bleibt allerdings weiterhin, alle lib´s sind eingebunden
-
wie auch immer so gings nicht, ich habe jetzt in meinem childwindow TreeProc
bei WM_PAINT:
nochmal ein fenster generiert mit createwindowex() man bekommt es auch zu sehen, wenn ich mein strukturbaum in diesm fenster öffne, und dann das fenster größer oder kleiner ziehe, schließen sich die elemente oder des fenster gerät gar in den hintergrund und ist nicht mehr sichtbar, ich hab das mal mit showwindow und updatewindow in der main funktion probiert nur das hilft nicht weiter.
kennt jemnd rat?
-
ich habe das gleiche problem,
hab jetzt ein childwindow in meinem hauptfenster positioniert, in dem wieder ein childfenster mit textinhalt steht und scrollleiste, sobald ich nach unten scrolle verschwinden die textzeichen oder wenn ich die gesamtgröße ändere passiert das gleiche.
weiß jemand woran das liegt oder wie man dagegen vorgehen kann. kann man die größe evtl mit WM_SIZE anpassen....danke für eure hilfe
-
Falscher Parent angegeben?
Parent des Childfenster ist das Hauptfenster.
Parent des Controls ist das Childfenster, nicht das Hauptfenster.
-
wie du das sagst hab ich das auch gemacht. ich habe es auch probiert das controlfenster in WM_CREATE des childwindows zu erstellen, das ging aber auch nicht, deshalb hab ich es nachdem ich das hier gelesen hab auch in WM_PAINT created und das ging, nur der fehler mit der größeneinstellung besteht halt

-
Warum immer bei
WM_PAINT

Ich kennekaum einekeine Nachricht, die ungeeigneter ist, irgendwelche Fenster zu erstellen.
Wird der Code bei der Erstellung des Fensters bei WM_CREATE durchlaufen (MessageBoxes ausgeben)? Überprüfst du die Returnwerte? Hast du mal GetLastError() aufgerufen?
Einem Fenster ein Child-Fenster zuzuweisen und jenem ein weiteres Child hinzufügen sollte schon funktionieren.Edith meint, WM_MOUSEMOVE wäre noch ungeeigneter...
-
jo also ich hatte das selbe problem...du musst auf deine return werte aufpassen.
ich hatte mein hauptfenster in dem zwei weitere kinderfenster
und in dem quasi ein kinder-kinderfenster.wenn du jetzt z.b. im kinderfenster noch ein fenster erstellen willst, mach das am besten mit WM_CREATE:
mit CreateWindowEx(.........,HANDLE auf HAUPTFENSTER...) wichtig ist hier dass du das handle auf das hauptfenster, in meinem Fall hwnd beziehst und nicht auf das eine kinderfenster.
sprich: ich hatte statt hwnd, hkind dort stehen....
da die größenveränderung ja mit dem hauptfenster zu tun hat
z.b. beim maximieren
-
Bei Dialogen muss man auf WM_INITDIALOG und nicht auf WM_CREATE reagieren.
-
ist ein konstant bestehendes fenster dass den kompletten programmablauf existiert ein dialog oder ein fenster. Worin unterscheidet sich das? Ich dachte dialoge werden seperat aufgerufen z.b. Durch ein menueitem und sind nicht im fenster implementiert.