Replacement for NSTexturedBackgroundWindowMask

  1. ‹ Older
  2. 2 weeks ago

    Jonathan A

    Apr 11 Pre-Release Testers Maryland, USA

    @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).

  3. Jonathan A

    Apr 11 Pre-Release Testers Maryland, USA

    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.

  4. Sam R

    Apr 11 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    Do you want something like the screenshots on this page? https://ohanaware.com/retinakit/

  5. Jonathan A

    Apr 12 Pre-Release Testers Maryland, USA

    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.

  6. Jürg O

    Apr 12 Pre-Release Testers, Xojo Pro

    @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...

  7. Jonathan A

    Apr 12 Pre-Release Testers Maryland, USA

    Interesting thought. But it doesn't apply to all controls. Dragging on these controls drags the window:

    Listbox
    Placard
    Label

    Dragging on these does not:

    Pushbutton
    Popup menu
    TextArea
    HTMLViewer
    Disclosure triangle

    I don't know how to interpret this, though.

  8. Jürg O

    Apr 12 Pre-Release Testers, Xojo Pro

    @JonathanAshwell Interesting thought. But it doesn't apply to all controls.

    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).

  9. Jonathan A

    Apr 12 Pre-Release Testers Maryland, USA

    Thanks, I'll ask Xojo to reopen the Feedback and see what they say.

  10. Jürg O

    Apr 12 Pre-Release Testers, Xojo Pro
    Edited 2 weeks ago

    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).

  11. Jonathan A

    Apr 12 Pre-Release Testers Maryland, USA

    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.

  12. Jürg O

    Apr 12 Pre-Release Testers, Xojo Pro

    @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)?

  13. Jonathan A

    Apr 12 Pre-Release Testers Maryland, USA

    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...

  14. Jürg O

    Apr 12 Pre-Release Testers, Xojo Pro
    Edited 2 weeks ago

    @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.

  15. Jonathan A

    Apr 12 Pre-Release Testers Maryland, USA

    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?

  16. Norman P

    Apr 12 Pre-Release Testers, Xojo Pro Enjoying Whistler BC

    Not that common
    Safari doesnt do that here
    Nor do Numbers , Pages or Keynote

  17. Jonathan A

    Apr 12 Pre-Release Testers Maryland, USA
    Edited 2 weeks ago

    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.

  18. Norman P

    Apr 12 Pre-Release Testers, Xojo Pro Enjoying Whistler BC

    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

  19. Ulrich B

    Apr 13 Pre-Release Testers, Xojo Pro Europe (Germany, Berlin) · xo...
    Edited 2 weeks ago

    @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)

    EDIT:
    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.

  20. Jonathan A

    Apr 13 Pre-Release Testers Maryland, USA
    Edited 2 weeks ago

    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.

  21. Ulrich B

    Apr 13 Pre-Release Testers, Xojo Pro Europe (Germany, Berlin) · xo...
    Edited 2 weeks ago

    @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.

or Sign Up to reply!