Grafik-Bug und Logik-Problem beim Gadget-Aufbau

[PureLust]

Anbei mal ein kleiner Code, der einen Bug beim Redraw von Gadgets zeigt.

- Zum einen sieht man einen offensichtlichen Redraw-Fehler am unteren Teil des ersten TextGadgets und
- zum anderen ist keine wirklich erkennbare Logik hinter der Z-Position der Gadgets zu erkennen.

Was ich auch ausprobiert habe - ein wirklich ersichtliches und logisches Verhaltensmuster bei der Z-Positionierung der Gadgets konnte ich nicht finden.
Mal ist ein Gadget vor einem anderen - dann wieder dahinter, je nach zuvor getätigten Befehlen - aber scheinbar ohne logisches Muster.
Es sind extra ein paar auskommentierte Zeilen im Code mit dabei, damit man schnell mal ein paar Verhaltensweisen testen kann.
Gemeldet hatte ich diesen Bug bereits Anfang Mai per Mail an André - behoben wurde er jedoch bislang noch nicht.
Daher also hier mal die Bugmeldung als offiziellen Forumsbeitrag zur Erweiterung der ToDo-Liste.

Code: Alles auswählen

;
; Litte Example, to show some currious effects in Gadget-Redraw
; and Gadget Z-Position, if Gadget-Color or -Font is set.
;
; Play a little bit with the Commands in line 15-17 to see Redraw-Problems
; and play with commands in Line 21-23 to see, how Font Settings are changing
; the Z-Position of the Gadgets

If OpenWindow(0,1,1,500,260,"Gadget Z-Buffer Bug")
	If CreateGadgetList(WindowID(0))
		LoadFont(0,"Arial",20)
		TextGadget(1,30,40,WindowWidth(0)-70, WindowHeight(0)-82," First TextGadget",#PB_Text_Border)
		TextGadget(2,60,2,WindowWidth(0)-65, WindowHeight(0)-5," Second TextGadget",#PB_Text_Border)
		TextGadget(3,0,200,120,40," Third TextGadget",#PB_Text_Border)
		SetGadgetColor(3,#PB_Gadget_BackColor,$8888aa)
; 		SetGadgetColor(2,#PB_Gadget_BackColor,$998888)
		SetGadgetColor(1,#PB_Gadget_BackColor,$99aa88)
		; Es scheint etwas mit dem zugewiesenen Font zu tun haben.
		; Scheinbar verändert das Zuweisen eines Fonts die Z-Order eines Gadgets.
		; Denn wenn nachfolgende Zeile aukommentiert wird, stimmt die Reihenfolge wieder.
;		SetGadgetFont(1,FontID(0))
;		SetGadgetFont(2,FontID(0))
		SetGadgetFont(3,FontID(0))  ; eine weitere Variante zum Ausprobieren.
		Repeat
			Event = WaitWindowEvent()
		Until Event = #PB_Event_CloseWindow
	EndIf
EndIf
End

Grüße, PureLust.

[real]

Und welches Sinn hat das?

[PureLust]

Und welches Sinn hat das?

Hast Du noch nie 'sich überlappende' Gadgets gemacht?

[mk-soft]

Überlappende Gadget sind in der GDI von Windows nie vorgesehen gewesen.
Habe noch nie ein Programm mit überlappende Gadget gesehen, außer es war müllig geschrieben.

FF

[PureLust]

Überlappende Gadget sind in der GDI von Windows nie vorgesehen gewesen.
Habe noch nie ein Programm mit überlappende Gadget gesehen, außer es war müllig geschrieben.

FF

Was ist denn dann in Deinen Augen z.B. ein als Hintergrundbild verwendetes ImageGadget mit darübergelagerten ButtonGadgets?

Ach ja ... da steht's ja: Müllig !!!

Alles klar ...

[real]

Man legt keine Gadgets übereinander! ... und wundert sich dann über die verwirrende Z-Order! Ein Image kannst Du auch anders unter Buttons bekommen und das solltest Du anders machen.

Ich gebe mk-soft Recht und bezeichne Programme mit überlappenden Elementen auch gern als müllig programmiert.

Hab bei Deinem Source nicht mal erkennen können, was Du damit bezweckst und wie es Deiner Meinung nach richtig aussehen sollte. Deshalb meine Frage oben. Kann aber morgen gern nochmal im Petzold nachlesen, wie die Z-Order (bei Win32) festgelegt sein sollte.

[mk-soft]

Hintergrundbild? Hier eine ganz frischer Link dazu:
http://www.purebasic.fr/german/viewtopic.php?t=8763

FF

[Zaphod]

@PureLust:

dafür gibt es die Patterns eigenschaft von Fenstern. Ein ImageGadget als Hintergrund ist mindestens sehr schlechter Programmierstil.

[PureLust]

Hallo zusammen, ...

Hab bei Deinem Source nicht mal erkennen können, was Du damit bezweckst und wie es Deiner Meinung nach richtig aussehen sollte. Deshalb meine Frage oben. Kann aber morgen gern nochmal im Petzold nachlesen, wie die Z-Order (bei Win32) festgelegt sein sollte.

Da mein oben geschriebener Source ja nur als Bug-Demo gedacht war, macht er in dieser Form natürlich nicht wirklich Sinn.

Ich habe es extra in dieser Form gepostet um möglichst konsistent den Fehler reproduzieren zu können.
Denn sowohl das Refresh-Problem als auch das Z-Order Problem scheint eine spezielle PureBasic Eigenart zu sein.

Ich hatte das Programm zur Kontrolle bereits zuvor mit zwei anderen Sprachen unter Windows nachgebildet und dort entstanden solche Refresh-Probleme nicht.
Denn Windows kann sehr wohl überlappende Elemente sauber darstellen (was auch jede halbwegs brauchbare GDI können sollte - vom Sinn und Unsinn solcher Aktionen mal ganz abgesehen).
Auch die konfuse Z-Order kenne ich so in diese Form nicht.
Normalerweise ist die Z-Order in der Reihenfolge der Erstellung der Objekte - es sei denn man ändert sie explizit.
Aber dass die Z-Order durch einfaches setzen von Eigenschaften wie Font oder Farbe so durcheinander geraten ist mir bisher halt nicht unter gekommen.

Wären mir diese Dinge also nicht als spezielle PureBasic Eigenarten aufgefallen, so hätte ich es nicht als Bug gepostet.

Denn dieses Verhalten und auch die Refresh-Probleme sind nicht wirklich Windows-konform und auch irgendwie nicht logisch nachvollziehbar - daher meine Meldung als Bug.

Grüße, PL.

[Kleiner Nachtrag:]
Durch bobobos Tip in einem anderen Thread, in dem er u.A. auch Probleme mit dem TextGadget ansprach, ist sowohl das Redraw-Problem behoben als auch die Z-Position nun so wie sie sein sollte (zuletzt erstellte Gadgets liegen oben auf).
Also zumindest mal ein funktionierender Workaround.

Für die, die's interessiert - so sollte es aussehen:

Code: Alles auswählen

#WindowFlags = #PB_Window_Invisible | #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_TitleBar 
If OpenWindow(0,1,1,500,260,"Gadget Z-Buffer Bug", #WindowFlags) 
   If CreateGadgetList(WindowID(0)) 
      LoadFont(0,"Arial",20) 
      TextGadget(1,30,40,WindowWidth(0)-70, WindowHeight(0)-82," First TextGadget",#PB_Text_Border) 
      TextGadget(2,60,2,WindowWidth(0)-65, WindowHeight(0)-5," Second TextGadget",#PB_Text_Border) 
      TextGadget(3,0,200,120,40," Third TextGadget",#PB_Text_Border) 
      SetGadgetColor(3,#PB_Gadget_BackColor,$8888aa) 
;       SetGadgetColor(2,#PB_Gadget_BackColor,$998888) 
      SetGadgetColor(1,#PB_Gadget_BackColor,$99aa88) 
      ; Es scheint etwas mit dem zugewiesenen Font zu tun haben. 
      ; Scheinbar verändert das Zuweisen eines Fonts die Z-Order eines Gadgets. 
      ; Denn wenn nachfolgende Zeile aukommentiert wird, stimmt die Reihenfolge wieder. 
;      SetGadgetFont(1,FontID(0)) 
;      SetGadgetFont(2,FontID(0)) 
      SetGadgetFont(3,FontID(0))  ; eine weitere Variante zum Ausprobieren. 
		HideWindow(0,0)
      Repeat 
         Event = WaitWindowEvent() 
      Until Event = #PB_Event_CloseWindow 
   EndIf 
EndIf 
End

[real]

Wenn Du drei Controls (vielleicht besser EditGadgets als Textgadgets) in der Reihenfolge 1 2 3 erzeugst und dann z.B. EditGadget 2 anklickst um etwas reinzuschreiben, erhält das - mit jeder Programmiersprache - den Fokus. Ggf. musst Du dann InvalidateRect() nutzen, um Deine Gadgets sauber neuzeichnen zu lassen.

Mit welchen anderen Programmiersprachen hast Du's denn versucht und wie sieht da Dein Source aus?