Regarding ‘Label’: Here I get the same behavior in both 2018r4 and 2019r1.
Why? Because no matter if Label.Transparent=true/false - it will always drag the window. (This makes sense - you can’t do anything with a Label. So it can be considered “background”).
However… it you set Label.Selectable=true - then you get the ‘Select behavior’ (and no dragging of the entire window).
So at least for Listbox, the Transparent-Property has an effect. And it’s a fact that this has changed in 2019r1 (since we can no longer have/set Transparent=false on macOS Controls).
You’re right. If I run in Xojo 2018R4 with the listbox Transparent = On then the whole window is dragged. I hope that Xojo will recognize that forcing transparent to true in macOS for all controls is not a neutral change and revert to the previous behavior.
They might say that what you’re doing isn’t a supported feature/usage of their Framework…
…having said that: Maybe there is some “Anti Declare” (to re-enable Listbox.Transparent=false in the Listbox.Open Event)?
I guess that whatever .Transparent=False has done internally before (which it is no longer doing in 2019r1) could be “manually done” (using Declares)?
Maybe. But there have been cases before where they’ve backed off from making changes to longstanding features because they might break existing code (which this does). They didn’t explain why removing transparent = false is helpful in any way. If it doesn’t add anything positive and the change was just housecleaning, maybe they’ll restore it. All one can do is ask…
Well, for one it’s the issue mentioned in that Feedback case. And it also fixes quite some other “why do I get a black background here?” issues…
Sure - I’m curious, too 
But my best guess is that if you want that “Listbox doesn’t drag the whole window behavior” again in 2019r1 (and newer), figuring out how to “re-declare” Listbox.Transparent=False might be a solution/workaround (depending on the point of view).
You should explain and write there why (not just an empty “please reopen”)… to get a better chance to be understood why you want that reopened.
You have a point. I’d still like to know about how others deal with this? This background dragging behavior is common in macOS for windows. How do/will others handle it in Xojo if setting transparency is removed?
Not that common
Safari doesnt do that here
Nor do Numbers , Pages or Keynote
I mean it’s a common type of window. Mail is just one an example with a large draggable area on top. Ironically, Xojo itself is one as well! How can we now achieve this in Xojo now? Given that the Xojo IDE is written in Xojo, how did you achieve this? That’s my question.
To be honest there isnt anything specific I can think of
But since I dont work there any more I cant look at sources to see if there’s something I dont recall
Did you try to set opaque to True via declare in the open event of the affected controls? Should be something like
Declare Sub setOpaque lib "AppKit" Selector "setOpaque:" (id as integer, value as Boolean)and in the controls open event
setOpaque (me.handle, True)EDIT:
Have a look at this: mouseDownCanMoveWindow
So yes, disabling the transparent property in macOS is definitely the reason for the changed behavior.
Thanks for the suggestion, but that didn’t work. The only workaround I’ve found is to set isMovableByWindowBackground = false on MouseEnter and isMovableByWindowBackground = true on MouseExit. Of course this has to be done for every affected control.
It would be easier to subclass the controls, but glad you found a workaround!
P.S.: Could it be that setOpaque is overridden by the inspector property run? If so, setting it shortly delayed after the open event could also fix it. But I have not tried.