I use NSTexturedBackgroundWindowMask and isMovableByWindowBackground to provide a “unified” window interface so the user can drag a window by it’s background (e.g. a large toolbar-like area at the top). Thats broken in 2019R1. I filed a feedback and was informed this was by design because Apple deprecated it in macOS 10.12 (it still works in 2018 R4 in my hands).
[quote=432262:@Jonathan Ashwell]I use NSTexturedBackgroundWindowMask and isMovableByWindowBackground to provide a “unified” window interface so the user can drag a window by it’s background (e.g. a large toolbar-like area at the top). Thats broken in 2019R1. I filed a feedback and was informed this was by design because Apple deprecated it in macOS 10.12 (it still works in 2018 R4 in my hands).
My question is, what is the modern API way to to allow this behavior? Unfortunately, the Apple docs don’t give a clue and by google searches aren’t helping.[/quote]
/* Calling -setMovable with a flag of NO will disable server-side dragging of the window via titlebar or background. -setMovableByWindowBackground:YES is ignored on a window that returns NO from -isMovable. When a window returns NO for -isMovable, it can be assigned to a different space with its relative screen position preserved. Note that a resizable window may still be resized, and the window frame may be changed programmatically. Applications may choose to enable application-controlled window dragging after disabling server-side dragging (perhaps to achieve snapping or pinnning) by handling the mouseDown/mouseDragged/mouseUp sequence in -sendEvent: in an NSWindow subclass. Note that a non movable window will also not be moved (or resized) by the system in response to a display reconfiguration. */ @property (getter=isMovable) BOOL movable NS_AVAILABLE_MAC(10_6);
Yes, I understand that. My current distribution is built with Xojo 2018R4 and it allows background dragging. Xojo2019R1 does not. I realize this version of Xojo was built against a later SDK. I missed the macOS requirements for apps deployed with Xojo 2019R1 – it was 10.10 for 2018R4. What is it now?
I guess what OP is trying to know is what changed between Xojo 2018r4 and 2019r1 that could make this not work anymore? From what I read both use SDK 10.14, so it should be other thing or a newer SDK 10.14.x perhaps?
deprecated does not mean it is gone. Am on 10.14, Xcode 10, create plugins with 10.14 for 64-bit and can use the “deprecated” mask. Since 2018r4 (was build with 10.13 and Xcode 9) and 2019r1 presumably as well, I would doubt what OP claims. The OP probably uses declares, which might introduce a different behavior
NSWindowStyleMaskTexturedBackground should be used instead.
I just don’t understand how Jonathan say that it works with the app build with 2018r4, when Greg said that Apple removed support with 10.12 SDK and Xojo moved from 10.9 to 10.14 in 2018r4. If I understand correctly it shouldn’t work with 2018r4 or 2019r1.
@Alberto De 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.
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…
But definitely somehow related… I’ve just tried your example project in 2018r4.
Listbox, Transparent=false -> drag stays in Listbox, does not drag the whole window
Listbox, Transparent=true -> drags the whole window
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).