@Alberto D;Poo That confused me, too. I uploaded a trivial project in the Feedback case in my original post. It's open to all if anyone else once to see the behavior in Xojo 2018R4 (works) and Xojo 2019R1 (fails).
BTW, by "broken" what I meant (and said in the Feedback, but not the OP) is that the the window background drag should only work when clicking on the window itself or a canvas -- clicking and dragging in a control like a listbox should *not* move the window. It behaves that way in Xojo 2018R4 but not in Xojo 2019R1, where a drag in a listbox *does* drag the entire window. I apologize for not making that clear up front.
Yes. And I have that, and have had that for many years. In Xojo 2019R1 isMovableByWindowBackground no longer respects controls like the listbox. I can work around that by setting isMovableByWindowBackground = false when the mouse enters the listbox (and back to true with it leaves). I reported this change in behavior to Xojo, but they argue that it's normal (and we shouldn't be using isMovableByWindowBackground any more). If there is another API call I should be using I'd love to hear it. I can't believe I'm the only one.
@JonathanAshwell It behaves that way in Xojo 2018R4 but not in Xojo 2019R1
What comes to mind is this fundamental change for TargetMacOS in 2019r1: Feedback Case #54430
RectControl.Transparent: this property is now ignored on macOS, i.e. all Controls are Transparent by default and will remain as such even if Transparent is False.
Maybe... this is related? Since the Controls now are "Transparent" (and they maybe have not been transparent in your Window before), they are treated kind of: "Transparent -> belongs to the Background -> you're dragging not the Control, but the underlying Window"?
While this sounds like a possible explanation, I don't have any idea if that is correct, and if that change is related and has an impact on what you're seeing as a difference in 2018r4<->2019r1...
Interesting thought. But it doesn't apply to all controls. Dragging on these controls drags the window:
Dragging on these does not:
I don't know how to interpret this, though.
@JonathanAshwell Interesting thought. But it doesn't apply to all controls.
But definitely somehow related... I've just tried your example project in 2018r4.
Since in 2019r1 the Listbox will always be 'Transparent=true' (no matter what you've set in the IDE), it gets that behavior change (compared to 2018r4 with Transparent=false).
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.
@JonathanAshwell 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...
@JonathanAshwell 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
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...
@JonathanAshwell All one can do is ask...
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).
@JonathanAshwell I'll ask Xojo to reopen the Feedback and see what they say.
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.
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.
@Jürg O ...having said that: Maybe there is some "Anti Declare" (to re-enable Listbox.Transparent=false in the Listbox.Open Event)?
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)
Have a look at this: mouseDownCanMoveWindow
This property lets you determine the region by which a window can be moved. The default value of this property is NO if the view is opaque; otherwise, it is set to YES. Subclasses can override this property to return different values based on the event.
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.
@JonathanAshwell 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.