Usually this happens if something the the CancelClose or Close event refereneces something on the Window which forces it to open again…
However both those events were empty… now they contain only a logging command to help determine whats what.
The window contains two canvas (one embeded in the other)
When I say “quit” (via menu) the CANCELCLOSE event is called, then something calls Canvas1 (inner) Paint, then Canvas2 (outter).
I thought it may have been an INVALIDATE call … its not
and I have put logging on about everything that I can possibly think of… . and only those 3 events seem to occur
The window Activate event is not called again for example, nor is Window Open.
STRANGE… if I click the “red ball” on the window, everything DOES close, and closes properly
So why doens’t MENU quit work?
If not, the appearance of the menu over the window, then disappearance might be causing the Paint event to trigger.
The question is why would the paint event stop the window closing?
So is there a (small) chance that the window which is closing is ‘an instance of Window1’, while closing the window calls window1.something and reveals another copy?
Dave, can you host a little project that shows the problem? I’ve replicated what you explained and its working as expected for me in Sierra on 2016r4.1 and 2017r2.1.
In any “small project” it works properly[quote=362242:@Jeff Tullin]So is there a (small) chance that the window which is closing is ‘an instance of Window1’, while closing the window calls window1.something and reveals another copy?[/quote]
My confusion is that “the red ball” works, but the menu doesn’t… both show CancelClose being called
but the menu method doesn’t call CLOSE… it seems to do something that repaints the window
When you start holding your app together with duct tape and bubble gum you will create headaches for yourself. It’d be better to figure out what is causing the unexpected behavior, rather than use timers to work around it.
Ok… I managed to finagle a break in PAINT only if CancelClose had been called… but not sure what I would/should be looking for that would be “out of the ordinary”…
There is only one Window active… the one in question
Zero threads, Zero Sockets, Zero Serials
The Stack shows
winMAIN.CanvasMain.Paint // this is where I put the break
winOpen.btn.Action // this was a previous window that opened winMain to start with
myBevelButton.Event.MouseDown // this is a button on winOpen that is the above Action event
If I but a BP in CancelClose the stack is
winMAIN.event.CancelClose
winOpen.btn.Action // this was a previous window that opened winMain to start with
myBevelButton.Event.MouseDown // this is a button on winOpen that is the above Action event
The BP in CancelClose shows the same stack values regardless of the method I use to quit,
Dave, maybe the File menu itself closing after you select Quit is causing the canvas(es) to repaint as the window itself refreshes the area that the menu covered while open. Could that be what is causing the problem? I have no idea what to do about it but it might lead somewhere to investigate.
If so, then why? as any other project doesn’t exhibit this behaviour
It seems that for “some reason”, it thinks it needs to refresh that one canvas, which aborts the close sequence
So far I can find no other method or event that is being called other than canvas.paint, including any/all code that issues a specific invalidate for that canvas. It seems to go directly from CancelClose to Canvas.Paint with nothing detectable in between
Well it calls the winMain.PAINT (which is why is then calls the paint for all canvas)… but the question is still “why”
menu quit
winmain cancel close
winMain Paint [empty]
cm paint
cb paint
cc paint
window close method
winmain cancel close
winmain close
I have nothing else to track… i have put a tracking message next to every reference to winMAIN to see if there was anything else called during either shutdown method…
Because closing starts after CancelClose has executed. So while the menu handler and then the CancelClose event are executing, the window is re-painted by the operating system as it sees fit. In addition I do not think that this re-drawing is preventing the closing. I would say that there must be something else going on.
In your initial post you write several time “… menu quit …” and you have a window which does not close. Do you mean by that that you’re quitting the application or are you closing the window only?
Menu Quit = Close the application via the Quit menu item
Window Close = via the red ball
App.AutoQuit is set to true … and the app does quit if I just “close the window”
As to “something else going on”… that is obviously a true statement…
but since I have logging message in every method I wrote, and every possible event (even if the event has no actions)
I cannot find “where it is going” the is aborting the close…
The only difference is that “Menu Quit” also calls winMain.Deactivate, which Window Close does not
Bob’s suggestion to turn off implicit instance and create one explicitly is probably the quickest route to figuring this out.
You’d more than likely get an exception where the problem lies.
