Verfasst: 02.02.2007 20:58
du glaubst also, die PB-Gadgets seien selbst gebaut?
Sicher.
Aber ich muss jetzt Schluß machen, meine Frau steßt.
also Tschüß
georg
Seite 3 von 4
Verfasst: 02.02.2007 21:03
Verfasst: 02.02.2007 21:17
So gut wie alle Gadgets sind native Win-Controlls, bzw. GTK-Controlls
Ausnahme wäre z.B. SplitterGadget (das gibts IMHO nicht nativ),
aber Button ist ein natives Win-Control.
Ausnahme wäre z.B. SplitterGadget (das gibts IMHO nicht nativ),
aber Button ist ein natives Win-Control.
Verfasst: 03.02.2007 00:01
Code: Alles auswählen
OpenWindow(0, 0, 0, 640, 480, "", #WS_OVERLAPPEDWINDOW)
CreateGadgetList(WindowID(0))
ButtonGadget(0, 10, 10, 200, 80, "1")
ButtonGadget(1, 100, 10, 200, 80, "2")
Repeat
nr = WaitWindowEvent()
If nr = #PB_Event_Gadget
eg = EventGadget()
If eg = 0
MoveWindow_(GadgetID(1), 100, 100, 100, 100, #True) ;Funktioniert nur bei Fenstern
ElseIf eg = 1
SetWindowPos_(GadgetID(1), #HWND_TOP, 0, 0, 0, 0, #SWP_NOSIZE | #SWP_NOMOVE)
EndIf
EndIf
Until nr = #PB_Event_CloseWindow
Probier mal obigen Code aus.
An der Zeile MoveWindow_,,, siehst du, das die Gadgets nicht Marke Eigenbau sind. Außerdem aus der PB Hilfe::
An der Zeile SetWindowPos_... wie du dein Problem evtl lösen kannst.Diese Library ist OS-unabhängig und verwendet die tatsächlich vorhandenen OS Graphical User Interface (GUI) Komponenten.
Verfasst: 03.02.2007 12:50
Überlappende Gadget sind nicht vorgesehen. der Z-Ordner ist nur ein verweis das noch weiter Gadget zu bearbeiten sind.
Lösung:
Alle Gadget löschen und in der gewünschten Reihenfolge wieder erstellen.
FF
Lösung:
Alle Gadget löschen und in der gewünschten Reihenfolge wieder erstellen.
FF
Verfasst: 03.02.2007 12:51
müsste nicht auch ein Redraw-senden in der dementsprechenden reihenfolge die z-order bearbeiten?
ich schätze mal, dass die VisualStudio apps das so machen....
ich schätze mal, dass die VisualStudio apps das so machen....
Verfasst: 03.02.2007 23:09
@Kaeru
Ich schätze mal eher, das Visual Studio & Co mit BeginDeferWindowPos, DeferWindowPos und EndDeferWindowPos arbeiten da dies wohl die schnellsre Möglichkeit ist, mehrere Gadgets auf einmal zu ändern. Zeichnet Redraw das Gadget nicht nur neu und verändert ansonsten nichts?
@mk-soft
Das die Z-Order mehr ist kannst du ausprobieren, indem du den Code oben einfach mal laufen lässt und einmal im Überlappungsbereich der beiden Gadgets drückst, dan wird Gadget 1 betätigt (und Gadget 2 verändert die Position). Startest du das Programm neu und drückst dann auf den nicht überlappenden Bereich von Gadget 2 (verändert eben die Z-Order) und dann nochmal auf den überlappenden Bereich ist das Verhalten wei von Georg gewünscht und Gadget 2 wird statt Gadget 1 betätigt.
Alle Gadgets löschen und in gewünschter Reihenfolge wieder erstellen löst das Problem nicht, wenn man das so mchen will muß man in Purebasic die umgekehrte Reihenfolge wählen.
Ich schätze mal eher, das Visual Studio & Co mit BeginDeferWindowPos, DeferWindowPos und EndDeferWindowPos arbeiten da dies wohl die schnellsre Möglichkeit ist, mehrere Gadgets auf einmal zu ändern. Zeichnet Redraw das Gadget nicht nur neu und verändert ansonsten nichts?
@mk-soft
Das die Z-Order mehr ist kannst du ausprobieren, indem du den Code oben einfach mal laufen lässt und einmal im Überlappungsbereich der beiden Gadgets drückst, dan wird Gadget 1 betätigt (und Gadget 2 verändert die Position). Startest du das Programm neu und drückst dann auf den nicht überlappenden Bereich von Gadget 2 (verändert eben die Z-Order) und dann nochmal auf den überlappenden Bereich ist das Verhalten wei von Georg gewünscht und Gadget 2 wird statt Gadget 1 betätigt.
Alle Gadgets löschen und in gewünschter Reihenfolge wieder erstellen löst das Problem nicht, wenn man das so mchen will muß man in Purebasic die umgekehrte Reihenfolge wählen.
Verfasst: 14.04.2007 17:26
Wenn PB keine eigens gecodeten Controls nutzt, und statdessen die API für dieerstellugn von Control her nimmt, dann sollte dieses Problem nicht auftreten!
Zumal Windows selbst ein internes Z-Order system für den Fenster-Handel implementiert hat. Da Buttons, Checkboxes, Labels, usw. nur Fenster mit anderen Styles sind, und diese auf ein Z-Order-System zugreifen, mus folglich auch die Controls ein funktionierendes verfahren besitzen, das dieses problem umgeht.
Z-Order ist ja wohl kaum so schwer hin zu bekommen. Das hab ich schon in einigen anderen Anwendungen selbst erstellt.
In meiner GFX-Treiber-Klasse hab ich das simpel mit 2 Array gelöst. Das erstere nimmt die Form und Control-Klassen auf, das zweite die Z-Order-reihenfolge.
Bei änderung der Z-Order (win: SetWindowPos) ändert sich auch der Grafische aufbau. sowie die Abfrage der Maus-RECT. Foglich KANN ein darunterliegendes Control NICHT durch eine Maus geraist werden! ... Wenn dem doch so ist, dann liegt ein BUG vor.
... Bei mir gehts ja auch problemlos. warum also bei PB nicht?!?!?
MfG
TPM
Zumal Windows selbst ein internes Z-Order system für den Fenster-Handel implementiert hat. Da Buttons, Checkboxes, Labels, usw. nur Fenster mit anderen Styles sind, und diese auf ein Z-Order-System zugreifen, mus folglich auch die Controls ein funktionierendes verfahren besitzen, das dieses problem umgeht.
Z-Order ist ja wohl kaum so schwer hin zu bekommen. Das hab ich schon in einigen anderen Anwendungen selbst erstellt.
In meiner GFX-Treiber-Klasse hab ich das simpel mit 2 Array gelöst. Das erstere nimmt die Form und Control-Klassen auf, das zweite die Z-Order-reihenfolge.
Bei änderung der Z-Order (win: SetWindowPos) ändert sich auch der Grafische aufbau. sowie die Abfrage der Maus-RECT. Foglich KANN ein darunterliegendes Control NICHT durch eine Maus geraist werden! ... Wenn dem doch so ist, dann liegt ein BUG vor.
... Bei mir gehts ja auch problemlos. warum also bei PB nicht?!?!?
MfG
TPM
Verfasst: 14.04.2007 17:35
lies doch mal den ganzen thread.
fensterelemente haben nativ keine z-order.
> Bei mir gehts ja auch problemlos.
was is "bei dir"?
fensterelemente haben nativ keine z-order.
> Bei mir gehts ja auch problemlos.
was is "bei dir"?
Verfasst: 15.04.2007 07:50
< hat den ganzen Thread gelesen!
Und, zu der aussage, das Fenster Nativ keine Z-Oder haben:
Das müssen sie ja auch nicht. Win übernimmt die Z-Oder strukturierung selbstständig. (Sieht man ja an den Fenstern) Dort funktioniert es bei PB ja auch. Wenn ich auf das obere Fensterklicke, dann wird auch das Obere Fenster geraist. Wenn ich das utnere Klicke, wird das untere erkannt. Da die standard-Controls auch nur Fenster sind, die als Child fungiert auf dem Fenster liegen, sollte auch hier ein Z-Order vorhanden sein.
MfG
TPM
Und, zu der aussage, das Fenster Nativ keine Z-Oder haben:
Das müssen sie ja auch nicht. Win übernimmt die Z-Oder strukturierung selbstständig. (Sieht man ja an den Fenstern) Dort funktioniert es bei PB ja auch. Wenn ich auf das obere Fensterklicke, dann wird auch das Obere Fenster geraist. Wenn ich das utnere Klicke, wird das untere erkannt. Da die standard-Controls auch nur Fenster sind, die als Child fungiert auf dem Fenster liegen, sollte auch hier ein Z-Order vorhanden sein.
MfG
TPM