Don’t draw the buttons using controls. Instead draw them with graphic commands as you can then draw all of the buttons into the same canvas. This does means that you have to handle hit testing yourself though.
Here the test project from Julian - extended with a drawable rounded rectangle. Simply click and drag the pink box above some other stuff. Works perfect on the Mac - and double fails with Windows. Double means neither the container nor the included canvas shows a result which would be expected - with the “transparent” toggle always set to “on”.
Test project with draggable container control
This is what I mean with “strange behaviour”. What would a new Xojo user think about that?
So again I invite you to use this nice demo from Julian to check and hack it so that it will work with the marvellous Windows! After all that I am very curious … 
1 Like
Really? This would actually be the last choice I would take. We will see if I will end up there … 
Thanks for the hint.
Get rid of the pink RoundRectangle. If you want such a rectangle on your button, draw it in the Paint Event, as we’ve said before.
The buttons in the screen shot I showed above had ALL their content drawn that way.
Further, to move a button around I’m using drag/drop, which is NOT the same as the live dragging in the example project.
Yes, that is what Keving also suggested. This would be my final solution only. Your interface looks nice, anyhow.
The “live dragging” is good UI style - and I need to have that for my purpose. I am not sure if your way will handle that? I believe the canvas is also not transparent.
btw: I justr replaced the pink bubble with
g.DrawingColor = &cFF00FF00
g.FillRectangle(0, 0, g.Width, g.Height)
inside the canvas. Same result - canvas has a green border.
I saw some comments with .NET calling some Windows DLL stuff … is there an easy way to put this into the sample somehow?
Without hooks into they way windows draws things, not really, and the order that xojo draws controls right now, possibly never.
Here’s a really, and I mean REALLY crude example of getting it to work with two canvases over the top of each other that I just whipped up. There’s a lot of work in there to make it more generic (e.g. a generic checker for controls currently under it instead of hard coding one control in the open) but as a proof of concept its doable, but alas, not with controls that don’t have a paint event.
Honestly though, you’d be better off doing as suggested above and writing your own button code for a canvas, you won’t be able to venture outside the canvas’s constraints while dragging but it will be the most crossplatform.
Another method might be to use local drag and drop where you can set the drag image to the “button” so it looks like you’re dragging the button around, but I’ve not really had a play around with that so it might not be doable.
1 Like
I use the MouseDrag and DropObject events to effect a button drag, as shown here where I’m starting to move the Help button to a new location:
You see my button has rounded, transparent, corners.
2 Likes
This is absolutely doable, and I in fact, do it.
1 Like
Nice, does it work exactly the same in windows too, with the image showing on the drag?
Yes, works very nicely. I have the image showing slightly translucent so you can see better where you’re dragging it. This was in Win7 in a VM using remote debugging so I can do it all on my Mini. I have to rebuild my Win10 VM so haven’t tried it there yet.
Win7 puts a nice little No Entry sign next to the image being dragged so you get told where you can’t drop it.
EDIT: Actually I suspect the translucency of the dragged image is down to Xojo/theOS rather than me.
i have a idea.
i guess after reorder the buttons are not overlapped.
how about switch to a canvas only for a order mode and paint only the shapes of buttons and after reposition hide this canvas.
Yes, there is a way to get a transparent containerControl under the rounded rectangle, so you don’t have the “green horns”.
A container control is technically an embedded window, so you can use the same technique to render part of a window transparent, as demonstrated in Example Projects\Platform-Specific\Windows\CustomWindowShape.
But you would probably be better off learning how to use a canvas to draw your buttons. Sometimes learning will spare you excess complexity.
Julian, thank you very much for this example - though it would not help getting my rounded buttons corners transparent, because it will work with rectangles only?
I already have my Z-axis correct. This means the container control I am moving is the LAST one in the order of all controls and this way the topmost always. Was a bit of work but it’s running. Everything is OK except transparency.
A container control is technically an embedded window, so you can use the same technique to render part of a window transparent, as demonstrated in Example Projects\Platform-Specific\Windows\CustomWindowShape.
Michel, thank you for naming the example project - I had a look into that and found it has a pragma with
#If TargetWin32
so I decided not to go this way. Though it runs on Win64 … it uses 32 bit Libs. Is there a more future-safe example which does the same?
This is absolutely doable, and I in fact, do it.
Tim, may be I still did not understand. I exactly did what you suggested in my test project above with the pink bubble, but did not get the transparency. Did you take an image with transparency for that? Strange is also that you can set transparency on the Mac, but not in the color selector used by the windows IDE … ?
It would be very nice and helpful if you could share a piece of code … 
TargetWin32, while deprecated, is technically the same as TargetWindows. Win32 is the Windows API subsystem name, and does not have any effect on what libraries are loaded or utilized. It simply says “This application is running on Windows”.
Hmm. What about this?
Declare Function CreateRectRgn Lib “GDI32” (Left As Integer, top As Integer, Right As Integer, bottom As Integer) As Integer
Declare Function CombineRgn Lib “GDI32” (rgnDest As Integer, rgnSrc1 As Integer, rgnSrc2 As Integer, combineMode As Integer) As Integer
Declare Function DeleteObject Lib “GDI32” (hObject As Integer) As Integer
Declare Function SetWindowRgn Lib “User32” (hWnd As Integer, hRgn As Integer, bRedraw As Boolean) As Integer
Says to me: I.e. User32.dll is used. How long will this stay on earth? 
The names Win32 and User32 have nothing to do with 32 or 64 bit. They are, as Anthony explained, the subsystems that make Windows work. There is no reason for them to go away, unless Microsoft released a brand new UI.
Contrary to Apple, though, Microsoft has always made sure to maintain backward compatibility. So chances are they will stay forever, or close to it.
1 Like
It was just poor planning on Microsoft’s part when they moved from 16-bit to 32-bit. User.dll became User32.dll. They’ve realized that mistake since and not done the same for the 32-bit to 64-bit switch. I highly doubt Microsoft will deprecate and remove the Win32 API anytime soon (if ever).
Michel,
I think this is may be a complete new discussion. It uses in fact the user32.dll - which is on my PC in 5 differnt versions at 10 locations. Probably you are right - may be it will stay.
Contrary to Apple, though, Microsoft has always made sure to maintain backward compatibility. So chances are they will stay forever, or close to it.
This may not be true. I lost one of my largest customers because Microsoft kicked Windows Mobile. A lot of old stuff does not run correctly any more on Windows 10. And for me it is clear that Microsoft will follow the Apple way into ARM. So we will see in five years? This is my scope (at least).
Anyhow - I will try that now - even if it will cost me a small piece of my life again 
Thanks again for your suggestion!