I have a simple form that has properties:
- AlwayOnBottom = .F. (default)
- AlwayOnTop = .F. (default)
- AutoCenter = .F. (default)
- Closable = .T. (default)
- ControlBox = .T. (default)
- DeskTop = .F. (default)
- Enabled = .T. (default)
- Height = 452
- MDIForm = .F. (default)
- MaxButton = .F. (default)
- Moveable = .T. (default)
- ShowInTaskBar = .T. (default)
- ShowWindow = 2 -As Top-Level Form
- SizeBox = .F. (default)
- Visible = .T. (default)
- WindowState = 0 (normal)
- WindowType = 0 (modeless)

I also have code in the Moved() event to note where the form has been relocated to and code in the Init() to put the form back to where it was located last on the last time it was used. The information comes from a memo field in a user security table entry.

The damned thing was always starting at 0,0 regardless of how it had been moved prior to closing.
I verified that the memo field contained the new location Top/Left values.

I ran the coverage profiler (first time ever) setting it ON to a file at the start of the Init() and OFF just before the return of the Init().
Reviewing the log, I saw NO evidence of the Moved() event executing during that time.

So I finally put a WAIT window in the Moved() event. Sure enough, when the form was first displayed the WAIT window appeared.

I put a test for 0,0 into the Moved() event code, doing nothing in that case, else invoking the original code. The form now acts as desired!@#!#@$!#@

Is it normal for the Moved() event to execute before or after the Init() at form startup, or is one of the property values causing this?

I consider the check for 0,0 as a workaround and would like to learn the correct way to handle this.

Thanks in advance
Jim Nelson