Canvas transparency broken

I just found in 2018r1 Canvas is not transparent anymore on Windows. This even turning on the Transparent property.
Just made a feedback case for this: <https://xojo.com/issue/52178> with included example.

Can someone confirm this and possibly provide workarounds if any?

[quote=387209:@Massimo Valle]I just found in 2018r1 Canvas is not transparent anymore on Windows. This even turning on the Transparent property.
Just made a feedback case for this: Feedback Case #52178 with included example.[/quote]
@Massimo Valle have you also tested on 2018R1.1 FC ?

Yes :frowning:

This is regression which will also bother me with the transition of my project. Don’t know when that will be since there are more issues to bridge. Thanks for reporting.

Please add your thought to the feedback case above. This is s show stopper for me

I’ve had very limited success on setting the transparency via declare. But still doesn’t work as required.
I guess it should not be that hard to fix this.

Normally, the larger control goes behind. What are you trying to accomplish by putting a control in front of other controls? Maybe there is another way to implement what you are trying to do.

This is exactly what I want to accomplish. Keep in mind the example I provided with the feedback case is a stripped down version just to show the problem.

Also, the Canvas is created on the fly from a control set, therefore it’s always in front. I’d like to be able to control the z-order…

And btw, this used to work till 2017r3

There are a number of things that have changed with the new windows updates as things have now moved back to the “correct” way of doing things in Windows. This means that some things that people have “gotten away with” now have to be corrected going forward.

Does it help you if you can move the control to the back of the stack at runtime?

If so you can place this at the end of your window.open (or even in the canvas.open) to put the canvas to the back of the “stack”.

Declare Function SetWindowPos Lib "User32.dll" (hWnd As Integer, hWndInsertAfter As Integer, X as Int32, Y as Int32, cx As Int32, cy As Int32, uFlags As UInt32) As Integer Call SetWindowPos(myCanvas.Handle, 1, 0, 0, 0, 0, 3)

[quote=387234:@]
Does it help you if you can move the control to the back of the stack at runtime?

If so you can place this at the end of your window.open to put the canvas to the back of the “stack”.

Declare Function SetWindowPos Lib "User32.dll" (hWnd As Integer, hWndInsertAfter As Integer, X as Int32, Y as Int32, cx As Int32, cy As Int32, uFlags As UInt32) As Integer Call SetWindowPos(myCanvas.Handle, 1, 0, 0, 0, 0, 3)[/quote]

I can TRY to workaround the problem in this way, but still I feel the Canvas is not working correctly. It simply cover EVERYTHING behind it despite it’s declared as transparent.

The way William has implemented transparency in windows means that we’re operating with “pseudo” transparency. Some things seem transparent but they aren’t, all the controls are doing it intelligently picking up background colour and background images and using them for their own colour/background.

Here’s a demo of your project with the “put to back” code in:

https://www.dropbox.com/s/s6gkfrqb9ddtx9m/canvasTransparencyForMassimo.xojo_binary_project?dl=1

I followed the William presentation at XDC and he basically shown the big no-no was PARTIALLY overlapping controls.

Would it be possible with the declare above to control the z-level where to bring the control.
While this only solve part of my problem, I’d need not to put it back to everything, but only to some controls. So I’d probably need to get the z order of controls and set the canvas z order lower of them.

What would have been nicer would have been for the control to copy the contents of the area behind the control then use that as the controls background when it was rendered. This would have implemented the transparency that you desired. I don’t know why this wasn’t done or if it was even considered, maybe it was and there was a problem doing it, I don’t know as I’ve not had chance to talk to William about it at length :slight_smile:

[quote=387238:@Massimo Valle]Would it be possible with the declare above to control the z-level where to bring the control.
While this only solve part of my problem, I’d need not to put it back to everything, but only to some controls. So I’d probably need to get the z order of controls and set the canvas z order lower of them.[/quote]

I don’t think so. As we aren’t given access to the ZOrder in the Xojo framework I don’t think there’s a way just to move a control a few positions back/forward on the ZOrder. As you mentioned, the only way would be to keep a list somewhere and put them all back (or front/top) in the right order so they land the way you want them. It might be easier to bring the few forward you want in front of the canvas, in that case you can change the 1 to a 0 in the above call.

:frowning:

This won’t really allow me to solve the problem. Anyway thanks Julian!

I guess I’ll pile on here. I have a transparent Canvas placed in front of another control. The Canvas intercepts the ConstructContextualMenu and ContextualMenuAction events, because the other control’s implementation of it (ListBox) either wasn’t implemented or did not really work as expected, I forgot which (was some time ago).

This setup was the recommended way to work around at the time and it worked well up to and including 2017r3. Everything still functions, but the fact that the Canvas is no longer transparent means that the underlying control isn’t visible anymore, kind of important :slight_smile:

I guess I’ll revisit the ListBox implementation of the ContextualMenu stuff and see where things are now. Maybe it works and I don’t need the transparent Canvas anymore. But now that I think about it, I’ve used that same technique in many places, so I hope there can be some way to reinstate the functionality of pre 2018r1.

So it looks like the ContextualMenu stuff works for ListBox under Windows, but I now remember why I used the transparent Canvas technique originally: it doesn’t work under Mac and I did not want to have to write and maintain platform-conditional code for this functionality.

… What’s different? Listbox is basically a canvas that’s managed for you.

I’d like to know this, also. I suspect some minor-but-important difference in event order (Mac vs Windows) for Listbox is the likely culprit. Looking into that now…

I’d certainly believe that they are related under the hood, but I would guess more as cousins, rather than one (Canvas) being the parent of the other (Listbox).