PureBasic Forums - English

It is possible to use a CanvasGadget() as a Window Background (In Windows, API, it can become a container). However, if you draw a Canvas the same size as the Window, Form Designer does not allow you to add other gadgets on top of it........

IdeasVacuum wrote:It is possible to use a CanvasGadget() as a Window Background (In Windows, API, it can become a container). However, if you draw a Canvas the same size as the Window, Form Designer does not allow you to add other gadgets on top of it........

It is not a container, so it shouldnt be used as such. Gadgets should not overlap unless Purebasic specifically allows it (ie Frame)

PB does allow it! It might not be recommended on Linux/OSX, but it works in Windows as a background if disabled. If desired it can be a container in Windows.

It "works" that's true, however it should not be done, unless it has changed since last time I read on it. That's the only reason why you cannot do it on the designer.
If the canvas is made to be a container in a future version, it will work then

Well Polo, PB supports the use of OS API, and OS API supports Canvas as a Container.........

..... but the designer doesn't have to support either

freak wrote:..... but the designer doesn't have to support either

Exactly!
As far as I'm concerned I built the designer on OSX, it turns out it's now included in the IDE and works cross platform, and that's what it's supposed to do, produce cross platform code.
That's why I want to stick to what Purebasic can do - although using Windows API you can get the canvas to work as a container, it doesn't mean you can do that cross platform and that's the main aim.

I've used the designer myself to build small apps on OS X with the aim of using it on Windows at work, and it's really nice seeing there's little or nothing to change so that it works

....and is the same true if using a disabled Canvas Gadget as the Window background? That does not require OS API, works perfectly on Windows - is it the case then that it does not work on OSX or Linux?

That is not officially supported behavior either. It may stop working in a future version. PB does not support layering gadgets on top of each other. Therefore the Designer does not (and should not) allow it, just as it should not allow the gadget to be used as a container when the Gadget library does not support for the gadget.

...Thanks for the clarification Freak

freak wrote:That is not officially supported behavior either. It may stop working in a future version. PB does not support layering gadgets on top of each other. Therefore the Designer does not (and should not) allow it, just as it should not allow the gadget to be used as a container when the Gadget library does not support for the gadget.

However I would strongly urge you to consider having some type of z level in all gadgets should you disable this behavior on windows. There are many applications that make drawn images used as backgrounds with controls on top and direct window draw is buggy at best with purebasic so we are forced to used this method.

1. Fix the issues with direct draw to background window and it not erasing when another window is overlapping or outside the monitor bounds having to do some major windows api calls to even get this to not do this but still causes exe to crash when ever i do anything drawing to a window or canvas.

2. You should have a z level to gadgets to set priority you talked about custom gadgets that's crossed platformed so do it.

Forcing us to use gadgets that have very little appealing gui design without the ability to changes theme aspects of the gadgets is very unappealing gui design. For example having a string gadget with different border color or the ability to change that border color or perhaps having different styles of buttons say rounded not square. Panel gadgets needs more ability to changes tabs styles border colors backgrounds on tabs just a few examples.


I'll even give a example from a designers point of view I wanted to have a string gadget that has the normal style of such gadget but on focus or clicked upon change the border to be a semi bright green as i had a drawn background with rounded white box style with a dark border of green. Now to do this the string gadget does not SUPPORT THAT!!! so i had to draw the background disable that background to keep in in the background and put gadget over it. when a user click the string gadget i just re enable the backgound and draw a border for it since the sting gadget does not support border color change!!!!!!!!

You need more ability to change these drawn gadgets colors styles even plain and simple.

ehowington wrote:I'll even give a example from a designers point of view I wanted to have a string gadget that has the normal style of such gadget but on focus or clicked upon change the border to be a semi bright green as i had a drawn background with rounded white box style with a dark border of green. Now to do this the string gadget does not SUPPORT THAT!!! so i had to draw the background disable that background to keep in in the background and put gadget over it. when a user click the string gadget i just re enable the backgound and draw a border for it since the sting gadget does not support border color change!!!!!!!!

A custom String gadget, based on the Canvas gadget, can be made to do all kinds of wonderful things, and without the need of OS API services. And it's not necessary to play games with the Z-order or with existing gadget features.

A custom String gadget, based on the Canvas gadget, can be made to do all kinds of wonderful things, and without the need of OS API services. And it's not necessary to play games with the Z-order or with existing gadget features.

...and indeed, in this case, it's probably a good solution. I use tiny Canvas Gadgets for CheckBoxes/OptionBoxes so that I can control their appearance. Or you could even draw everything on one canvas.

An alternative would be to have a canvas as the Window background and use borderless StringGadgets. This way it is very simple to draw a border around the gadget in the colour and line thickness you require. Granted, doing this is not officially supported so a future change to PB could break your code, as Freak warns. At the moment though, it works very well and given that some apps absolutely need an attractive, easy-to-understand GUI, you might consider the risk is worth taking - worst case scenario is that your app could only be maintained with the version of PB before the change that broke your code.

I'm hoping we will see a change that respects gadget z-order in a future release, it is such a common requirement these days.

IdeasVacuum wrote:

A custom String gadget, based on the Canvas gadget, can be made to do all kinds of wonderful things, and without the need of OS API services. And it's not necessary to play games with the Z-order or with existing gadget features.

...and indeed, in this case, it's probably a good solution. I use tiny Canvas Gadgets for CheckBoxes/OptionBoxes so that I can control their appearance. Or you could even draw everything on one canvas.

An alternative would be to have a canvas as the Window background and use borderless StringGadgets. This way it is very simple to draw a border around the gadget in the colour and line thickness you require. Granted, doing this is not officially supported so a future change to PB could break your code, as Freak warns. At the moment though, it works very well and given that some apps absolutely need an attractive, easy-to-understand GUI, you might consider the risk is worth taking - worst case scenario is that your app could only be maintained with the version of PB before the change that broke your code.

I'm hoping we will see a change that respects gadget z-order in a future release, it is such a common requirement these days.

Indeed to many application to count have more control over controls aka gadgets than we are presented with purebasic a z order should be a requirement although I have read arguments from other developers that this is lazy coding why make our programs take tons of time to develop if freak does disable that.

...well of course it's not about lazy coding. I think PB's challenge is staying cross-platform. Windows supports the use of a Canvas Gadget as a container for example, but maybe that isn't the case on Linux/Mac.