Does invalidate cause activate?

I have code in activate that I thought would be fired on some occasions.
Does invalidate cause activate to fire?

any event that refers to a window, when that window is not currently active, will fire its ACTIVATE event

So the answer is “sometimes”…

usually ACTIVATE fires when you first open a Window, or when the window gets focus again after losing it

but if the window is already active, INVALIDATE will NOT fire its ACTIVATE event

This is not accurate. I’ve just tested on Mac OS 10.11.6 with a non-implicit instance, I can access methods on the window, and the Activate event does not occur. I’ve also tested and it seems Canvas.Invalidate on a non-implicit instance window will not cause the Activate event, nor does it drag the secondary window to the front - and the Canvas does re-paint.

Here’s a test project to play with: test.xojo_binary_project

I would recommend getting into the habit of turning Implicit Instance off, you’ll save headaches down the road.

[quote=348382:@Arthur Gabhart]Grumble. I have a window that goes from window.hide to window.show and it doesn’t go to activate.
Suggestions?[/quote]
What exactly are you trying to achieve?
More details means we can all offer better suggestions :slight_smile:

You are correct in that I “assumed” Implicit Instance, as that is the default… and I will go on record as to disagree about getting in the habit of “turning it off”… There are times that is appropriate, but not by default (my opinion)

Sorry. I deleted my response. I read refresh is expensive. I can’t remember if this closing of a window is which caused activate to not fire, but I’m trying to get some code to run when a secondary window closes. Just closing the 2nd window doesn’t seem to fire activate.

Using the non-implicit method of windowing, you could pass the parent window to the secondary window, and in the Close event of the secondary window it could execute a method on the parent window.

An example of how this could work: close_notify.xojo_binary_project

Thanks. I guess that is the best solution. I call methods in other windows often. That way I don’t have to depend on activate. I also have to spend less time in the activate method.
Also, your code is elegant and simple.

@Tim Parnell Actually I usually use the following snippet without creating the constructor in winSupplement:

dim w as new winSupplement
w.mwinParent = self
w.Show

I’d appreciate to know which of the two ways is the recommended one. Thanks.

Any time you can avoid accessing the properties of an object directly, that is preferred. Your code is less likely to break in the future when the details of the object change. (And yes, a window is an object.)

@Tim Hare Thank you (supposing you were answering my question).