I created a steady case to understand what is going on but I feel like I’m missing something big here.
Just to easily reproduce this, I’m simplifying the issue at hand:
Let’s say I have a window and it has a timer that gets activated from the window.activate even, and when the window fires up the window.deactivate event I stop the timer (this part is irrelevant for my case but is there to better see the action or lake of action).
I run the binary and click a Windows Explorer window or Finder on macOS just to make sure it is not registered as “the active window” in the OS.
On Windows it fires up window.activate even as soon as I drag a file over but on macOS it never happens unless the user proactively clicks on the window.
Xojo docs describe exactly what I experience on Windows and still, it behaves differently when ran under macOS.
Of course, in real-life my usage is far more complex, and just to remove any unwanted replies, no, I can’t put the code on the DragEnter/DragExit event, it must be the activate event.
I add here a small video showing how it looks on both systems.
I wish you’d do the drag a little slower so I could see what’s actually happening 
Something in windows is bringing your window to the front, causing the activate to trigger and a repaint (as I see it redrawing), I just tried it with a simple me.AcceptFileDrop(“Untitled”) (where Untitled is just *) in window1.open and it didn’t trigger Window1.Activate.
- I assume the problem is that this alteration isn’t working on mac?
- “Xojo docs describe exactly what I experience on Windows” what experience, the window coming to the front? the drop working? what docs? do you have a link and quote?
- Could you provide a simple demo project of this happening so we can have a play?
- What version of xojo?
- What version of macos?
Julian is right, something in your code is bringing the Window to the front and activate the process, here is a frame captured from your video (I don’t get that with your Mac video):
As you can see the window where you are dropping the file is the top most window (activate).
Edit: sorry I read your post again and it is not clear to me, do you want Windows to behave like Mac or Mac to behave like Windows?
Hi @anon20074439, very good points!
I wish you’d do the drag a little slower so I could see what’s actually happening
Well, that’s the whole point, I do it fast because on macOS if you do it slowly it actually activates the window (making it the active window) and here I’m trying to cover cases when users do it fast and on macOS this is not working while on Windows it is.
Quote from Xojo docs:
In an app with multiple windows, the Activate event fires each time the window becomes the frontmost. This includes when it opens. When the window first opens, the Open event fires prior to the Activate event. Subsequent activations fire the Activate event but not the Open event.
I many cases users have another application window as ‘the active desktop window’ usually Finder window/Windows File Explorer, they look for a file in that window and drag&drop fast enough before the OS shifts the focus to my app.
I do a ‘trick’ by pulling out a duplicate window when the user drags a file (DragEnter event) so the object handling is done on a duplicate window and when the new object processing is done I pull the ‘real’ window back to front, that’s what fires up the Activate event on Windows as quoted above but not happening on macOS.
I hope this sheds some light on the issue and helps to reproduce it easily, but just to make sure, I attach here a sample project (ActivateEventTest) based on one of the Xojo Example projects with a little bit of extra code just to make it happen.
I still work on Xojo 2020r1.2, I didn’t have time to check that r2.1 is functioning correctly but I’d be surprised if it’s a bug that was fixed in r2.1.
All my tests were done on MacOS Catalina and Win10 Pro 20H2 but again, I’d be surprised if it’s any different on other Windows/macOS versions.
When you play with the sample project, make sure you make the app show the text: “DeActivate event fired up” by selecting a third-party window/ Finder window/ Windows File Explorer or clicking the desktop. when you DragEnter the app you must release it fast before it “takes focus”.
Sorry for the delay, I got side tracked by something. After a bit of testing, it looks like you have found a bug there in the Macos framework (someone might want to add that).
If you run the following simple example:
and bring another app to the front before the window opens then on Windows the activate event fires but on Macos it doesn’t, this difference clearly shouldn’t be happening.
As a work around you can subclass window, add a method called TriggerEvent, inside that in a #if TargetMacOS, call RaiseEvent Activate, Add Activate as an Event and EventHandler. This will allow you to call MainWindow1.TriggerEvent after the show which will in turn trigger your Activate event as required just for macos.
Thank you so much Julian, I very much appreciate your effort!
Actually, Yesterday I already did that and move on.
I just think everyone should be aware of this glitch. Even though we can work around it, it still is a very inconvenient workaround that I would love to avoid as soon as possible.