Briefly, I've got a canvas that that fills the window. On top of the canvas, I am placing buttons (and later other controls, including canvas controls). I am drawing content on the canvas and the expectation is that the controls to remain visible and functioning.
If I create the background first then a button, I can see the button (looks perfect) but cannot get to respond to a click.
canvasGadget ( #g_background_logo, 0, 0, windowW, windowH )
drawLogo ( 0 )
then
buttonGadget ( #g_background_config, x1, y1, w1, h1, "Config", #PB_Button_MultiLine )
If I reverse the creation order
buttonGadget ( #g_background_config, x1, y1, w1, h1, "Config", #PB_Button_MultiLine )
then
canvasGadget ( #g_background_logo, 0, 0, windowW, windowH )
drawLogo ( 0 )
I cannot see the button but it responds to click events. Ah, but I can tab between them which changes the state invalidates and redraws.
(Of course, if I get rid of the background, the buttons work as expected.)
I just did another test. I removed the drawLogo from the OpenWindow and added a two second timer and THEN called drawLogo. The program created a white canvas with the buttons added after the canvasGadget then two seconds later, the canvas was updated and drew over the buttons that were previously visible. Tabbing through the controls restores the visibility regardless of whether they are above or under the canvas but only the ones on top of the canvas respond to clicks.
buttonGadget ( #g_background_config, x1, y1, w1, h1, "Config", #PB_Button_MultiLine )
canvasGadget ( #g_background_logo, 0, 0, windowW, windowH )
buttonGadget ( #g_background_showHDMI, x1, y1, w1, h1, "HDMI", #PB_Button_MultiLine )
Is there a trick that I'm missing to handling control z-order or perhaps using the wrong functions ?
And if I may ask another semi-related question... in the OpenWindow, I'm using #pb_window_invisible
if openWindow ( wind, windowx, windowy, windoww, windowh, "", #PB_Window_Borderless | #PB_Window_Invisible, parent )
and then
setWindowPos_ ( windowID ( wind ), #HWND_TopMost, 0, 0, 0, 0, #SWP_NoSize | #SWP_NoMove | #SWP_ShowWindow )
I'm doing this because the routine, I'm watching the canvas being created and updated, which is causing a bit of flashing.
Is this the correct procedure to ensure the screen just appears in an instant ?
Canvas with controls on top (z-order)
Canvas with controls on top (z-order)
I enter the PureBasic world, targeting both Mac and Windows, by way of PowerBasic, Win32API, EZGUI back to CP/M via various BASIC dialects, xBase and other languages as needed.
Side project: http://www.thecomputerarchive.com
Side project: http://www.thecomputerarchive.com
Re: Canvas with controls on top (z-order)
Hi @Thumper. Just use the container flag for the canvas gadget. As for the flashing issue, you could simply hide the window until all the drawing functions complete.
Here's an example:
Here's an example:
Code: Select all
win = OpenWindow(#PB_Any, 0, 0, 600, 150, "Canvas Gadget Container",
#PB_Window_SystemMenu | #PB_Window_ScreenCentered)
HideWindow(win, #True) ; to hide the window
CanvasGadget(0, 0, 0, 600, 150, #PB_Canvas_Container)
; drawing then gadget
StartDrawing(CanvasOutput(0))
Box(50, 50, 200, 50, #Red)
StopDrawing()
ButtonGadget (1, 60, 60, 180, 30, "Config 1", #PB_Button_MultiLine)
; gadget then drawing
ButtonGadget (2, 360, 60, 180, 30, "Config 2", #PB_Button_MultiLine)
StartDrawing(CanvasOutput(0))
Box(350, 50, 200, 50, #Red)
StopDrawing()
HideWindow(win, #False) ; to show the window again
While WaitWindowEvent() ! #PB_Event_CloseWindow : Wend
Texas Instruments TI-99/4A Home Computer: the first home computer with a 16bit processor, crammed into an 8bit architecture. Great hardware - Poor design - Wonderful BASIC engine. And it could talk too! Please visit my YouTube Channel 

Re: Canvas with controls on top (z-order)
Missing CloseGadgetList() for CanvasGadget as container. I also forget sometimes 

My Projects ThreadToGUI / OOP-BaseClass / EventDesigner V3
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
Re: Canvas with controls on top (z-order)
Hi @mk-soft. Thanks for pointing that out. But technically, it's not missing.mk-soft wrote: Sat Nov 30, 2024 10:24 am Missing CloseGadgetList() for CanvasGadget as container. I also forget sometimes![]()
The CloseGadgetList() function closes the current gadget list and reopens the gadget list of the last container; in this case the window. It would be required if more gadgets were to be added to the window after a container gadget was instantiated. But in this example, all gadget creation has been wrapped up, so it's not required.
Even in the case where gadgets might be added in other parts of the code, for multi-window, multi-container applications, it would be better and safer to use the UseGadgetList() or OpenGadgetList() functions.
Nonetheless, it's a good practice to follow.

Texas Instruments TI-99/4A Home Computer: the first home computer with a 16bit processor, crammed into an 8bit architecture. Great hardware - Poor design - Wonderful BASIC engine. And it could talk too! Please visit my YouTube Channel 

Re: Canvas with controls on top (z-order)
Last night, I was trying things like invalidating the controls and drawing on the window.
Now I'm so confused as to why putting the controls into a container changes its behavior so much. Now many questions.
I was planning on using the containers in a few other ways. It appears that I can have containers within containers, so that should be fine, but I'm wondering what else to expect. (First idea - using containers like tabs that aren't tabs.)
Do we know what containers are doing under the hood in Windows ?
Is there a case for putting everything in a container ?
(Future thinking, like maybe next month) What if I end up replacing the canvas with a "screen" with controls on top of it ? That seem the best way to achieve some animations and maybe 3D effects.
(Not critical at this junction) Is this behavior shared if compiled to Mac and Linux ?
On the hiding, using #PB_Window_Invisible and the (un)hideWindow wouldn't cover up the task bar on some monitors. setWindowPos call appears to work on all, at least on this computer.
Thanks for that direction. I saw the capability but never associated it with my problem.
(And just a heads-up.... I'm diving deep into my first "real" (major) PB application during the next few weeks. I apologize as I'll probably have a few more questions...)
Cheers!
Now I'm so confused as to why putting the controls into a container changes its behavior so much. Now many questions.
I was planning on using the containers in a few other ways. It appears that I can have containers within containers, so that should be fine, but I'm wondering what else to expect. (First idea - using containers like tabs that aren't tabs.)
Do we know what containers are doing under the hood in Windows ?
Is there a case for putting everything in a container ?
(Future thinking, like maybe next month) What if I end up replacing the canvas with a "screen" with controls on top of it ? That seem the best way to achieve some animations and maybe 3D effects.
(Not critical at this junction) Is this behavior shared if compiled to Mac and Linux ?
On the hiding, using #PB_Window_Invisible and the (un)hideWindow wouldn't cover up the task bar on some monitors. setWindowPos call appears to work on all, at least on this computer.
Thanks for that direction. I saw the capability but never associated it with my problem.
(And just a heads-up.... I'm diving deep into my first "real" (major) PB application during the next few weeks. I apologize as I'll probably have a few more questions...)
Cheers!
I enter the PureBasic world, targeting both Mac and Windows, by way of PowerBasic, Win32API, EZGUI back to CP/M via various BASIC dialects, xBase and other languages as needed.
Side project: http://www.thecomputerarchive.com
Side project: http://www.thecomputerarchive.com