Überlappende Gadgets
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
- ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
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.
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
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.
Ü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
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
@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.
- ThePuppetMaster
- Beiträge: 8
- Registriert: 05.06.2005 12:15
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
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
- ThePuppetMaster
- Beiträge: 8
- Registriert: 05.06.2005 12:15
< 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