Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Moved event before Init()?
Message
From
11/02/2002 09:13:18
 
 
To
11/02/2002 02:09:17
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00617898
Message ID:
00618278
Views:
11
Hi Walter,

As Gerald pointed out to me, code in the Moved() event was really overkill, and moving the code to form close time eliminates the problem.

But I have other forms where the same code is used and they work fine to date (not yet revised under VFP7, mind you), so it is mysterious.

These are all "vanilla" forms, not from a class and with no execution of Show() to that point in the code.

In any case the particular problem is solved for the form in question, and not really in 'workaround' fashion, so I am happy again.

Thanks Walter,
Jim


>Hi Jim,
>
>I don't know if this applies to your problem, but this is how I solve the problem.
>
>I've got a custom class which among other functions relocates the form before showing. The code is in the init of this class. This INIT is fired before the INIT of the form (because the inits of contained objects are fired before the container itself).
>
>I drop this container on any form I make. It seems to work fine.
>
>However some things to note.
>If your form is based on a class and you've set the WIDTH or HEIGHT properties on the form, the resize event is fired before showing up. The same could be true for TOP and LEFT with regards for the moved events.
>
>Once I encountered a real odd situation where I did not seem to be able to locate the form based on the location where it was closed the last time. As I recall correctly I had to do something with calling the SHOW method. Fact was, that I could not find any rational explanation why it did act that way. I solved the problem by stripping all the method code one by one, to identify the problem then.
>
>Walter,
>
>
>>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
Previous
Reply
Map
View

Click here to load this message in the networking platform