Timer Initial Parent

Targets macOS
1

I can’t see any documentation on the Timer Initial Parent behaviour?
I have a window(plain box) with a timer set to close it after 1 second which works fine on Mac but on Windows it remains open.

I have the following code in the Open event but can’t see why that would make a difference but that is all that is going on…suggestions?

Dim newFrame as new Rect( 0, 0,self.width, self.height+20)
newFrame.left = ( ( MainWindow1.Width - newFrame.width ) * 0.5 ) + MainWindow1.Left
newFrame.top = MainWindow1.top +50   
me.bounds = newFrame
2

I see no code how the timer handle’s its action event?

3

Sorry the code in the timer is Self.close

4

I added a mouse down event to click and close the window and it doesn’t react to that either??
I was calling the window from a Save method, so tried calllater to initiate the window… no difference.

5

Is this window implicitinstance?
Is this a DesktopWindow or Window?

6

Implicit Instance and Window

7

Watch out for ImplicitInstance …make sure it is off.

If any code executes after that .close commend, you may end up with another window becoming visible.
A timer ‘control’ isnt a rect object and doesnt really have a ‘parent’ as such at runtime.
Nonetheless, self.close would be correct.

Does the cancelclose event have anything in it?

8

Nothing in cancelclose.
Will try ImplicitInstance Off

9

Ok that explains alot.
Stop the timer in the action event

Me.enabled=false
Me.RunMode=Timer.Runmodes.Off

Self.close // this hides since its implict
10

Hmmm no difference, pretty sure this was working in the previous version of my app. What is the difference from Mac to Windows for this simple action?

11

Try

in the window open event (replaces the timer)
Timer.CallLater 1000, AddressOf Close // or replace close with another sub

12

I seem to have a deeper issue.
If I launch the save progress window from a button it will behave properly and close itself off the timer on both Mac and Windows but if I launch the progress window from my save method after I close the file being saved it only behave as expected on Mac.
When I try and do a Save As and try an overwrite another file of the same name it works as expected on Mac but on Windows the Save dialog locks up and you can’t see the “Are you sure you want to overwrite” message?

13

Why would there be such a different behaviour for the same code from Mac to Windows?

14

Ok time to give-up on Windows Timer closing it’s own window. Added a keydown event so the user can just press a key to close the Window.
The second part of my Window’s issues above which is not related to the first and should perhaps in in another thread is more troublesome. On Mac the overwrite warning comes down as a sheet but on Windows it is appearing somewhere in the background behind the main window and the SaveDialog so the user can’t respond. If I ctl alt Del to End Task the overwrite Message window then appears??

Why would it not appear as the front most Window (Maybe it is related to the other problem)?

15

I think it has something to do with the reason you feel you need to ‘set bounds’ in the prog window.

The file save dialog is ‘attached’ to the wrong window somehow

Do you need a progress window at all?
Can the save code be an app level method?

16

I was setting the bounds to centre the other windows over my main window since it was scalable and moveable it seemed weird if the other windows appeared off centre?

The progress window really only appears when you save a file that has already been saved especially when you clicked save from the toolbar there was no visible way to know for certain the save took place so I thought it was necessary feedback… maybe I’m wrong.

17

If you are able to reproduce this in a small simple test project please upload it and we can help.

1 Like
18

From a LOT of experience in attempting this kind of thing in a briefly appearing window which wouldn’t update during a long process, I would suggest:

Add a progress bar to your main window
Add an integer property to the window ‘SaveProgressPercent’
Add a timer to the main window
Put your saving code in a thread (making sure that no message box or screen control is affected during the save routine)
When the thread starts, start the timer.
The save code affects the SaveProgressPercent variable
The timer checks that, and if SaveProgressPercent is non-zero, makes the progress bar visible
The timer sets the progress bar to the value of SaveProgressPercent
When the thread state goes to notrunning, the timer sets the progress bar to be invisible, and sets its own mode to 0 (stopped)

Done this way, the progress bar will update smoothly while the save is happening.
And it is part of the window that is doing the save.

For a funky effect, you might update the save button on the toolbar which you clicked (instead of a progressbar), as that would have an even more direct cause-and-effect visual.

1 Like
19

Thanks Jeff, great suggestion. I think I need to take the update initially to see if I can get the Windows version to stop locking up. It’s a shame the Mac and Windows version don’t behave the same as I was pretty happy with the behaviour and appearance on the Mac.

20

Still no luck on what is causing the dialog to attach to the wrong window. If I press the Alt key the Dialog overwrite message appears if that is a clue.
I haven’t been able to create a example project as it works as expected when I create simple elements.
It doesn’t seem to revolve around my code in the save method as it does the same when I take my code out.
So what could cause it to attach to the wrong window

Dim tout as textoutputstream
Var dlg1 As New SaveFileDialog
                      
dlg1.initialDirectory =  SpecialFolder.Documents               
dlg1.promptText= App.kFileSaveMsg 
dlg1.SuggestedFileName=App.kUntitled+".cwwtext"       
dlg1.Title = App.kFileSaveAs   
dlg1.Filter=filetypes.Crosswords 
savevolfile=dlg1.ShowModal
if savevolfile <> Nil then