To all,

Maybe I'm having a bad day or night, but I think I'm going bonkers.

1) I put a debug statement to trace some processing occuring while in GotFocus and Lostfocus for a particular control. When I run the darn form, it seems that, for example, the "Gotfocus" in that particular control gets fired more than one time when I would think that a controls only gets focus one time. Therefore, I shouldn't see me keep coming back to my debug statement over and over again. Unless of course I'm leaving the control and coming back which I am not.

FYI, I know that the gotfocus is getting hit more than once because when I hit F8 it moves on and subsequently comes back to the debug. After about 10 times, I then hit the F5 to expedite things and then it's okay .

Is this normal? Is something off in my app? Is this the way it's suppose to be because 'man' I can't figure this out.

2) Also, I like to see things progress in a linear fashion. For example, when I call for another form from the LostFocus of a control I don't expect to see the code after that call to be executed until I return from the form that I'm calling.

For example, I call another form:

ParentID=Get_Property(@Window, 'MDIFRAME')

MDIChildID=Start_MDIChild(WinName, ParentID, Data,,)

Code Stuff * e.g.,

If xyx eq abc then

blah, blah, blah

End else

yada, yada, yada

End

code below the call for the new form * is executed before the form is even displayed onto the screen and before the code in the new form Create event is fired * Because of this, it's thowing off the validity of what I'm checking for.

Is this the ways of Windows? I have also tried calling this form using Dialog_Box, Create_Dialog. Same result.

Can someone shed some light on this situation.

Baffled. I'm sure there's some logical reason for the above behavior (other than ….)

Thank you very much,

Ray

P.S. I also posted this on the otherside as well since response is sometimes better there.

[email protected] onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Ray,

(1)

Do the following experiment and see if it explains your problem: Create a new (unbound) form with two edit lines. (One might be enough.) Put a debug statement (and nothing else) in the user event of the first field's GOTFOCUS. Test run. The first field immediately gets focus and the Debugger appears. Then press F10 to step to the next statement. Since the handler hasn't got any more statements (except RETURN 0), the Debugger is finished with its job, and the field gets the focus again, again triggering the Debugger. (It happens so fast you might not see your form at all, just the Debugger that seems to stay there all the time.) When you're tired of pressing F10 try F5 (Go). The field gets the focus again but this time the Debugger isn't triggered again.

(I don't know exactly what it is that determines if the Debugger gets triggered. There are other cases than this simple one.)

(2)

I haven't tried to find out what goes wrong in this case, but why do you want to start a new window in the middle of a LOSTFOCUS event? My gut feeling is that a LOSTFOCUS should be allowed to run to its end.

Also I might disagree with your distribution of responsibility. You seem to have a child starting another child. I think in general the frame should be the boss. The first child could send a message to the frame (an OMNIEVENT message, or perhaps MENU), but the frame should do the job of starting the new child.

(Says a father of three…

What is it you want to check after the new window has been launched?

I realize what I've written here might not have been much help.

- Oystein -

Oystein,

I haven't tried to find out what goes wrong in this case, but why do you want to start a new window in the middle of a LOSTFOCUS event? My gut feeling is that a LOSTFOCUS should be allowed to run to its end.

Why do I want to do this? Because it's possible ;) Is there something improper or technically wrong with this approach. At LostFocus, I am ascertaining whether the Id Number entered is an existing or new record. If it's new, I then bring up another form to allow the entry of a new record based on the number entered.

Also I might disagree with your distribution of responsibility. You seem to have a child starting another child. I think in general the frame should be the boss. The first child could send a message to the frame (an OMNIEVENT message, or perhaps MENU), but the frame should do the job of starting the new child.

Is this typically how things are done? I'm seeing that there can be advantages to having the frame as the boss. For example, when I use the Dialog_Box function to bring up a form, it doesn't appear that the form can access the functions which resides on the frame, e.g, Save, (unless I doing something wrong.)

What is it you want to check after the new window has been launched?

Well the idea is that after I return from calling the new window, I need to edit that the number was in fact used. For example, it's possible for the user to just escape from the new window. I cannot have an invalid number since I use that number in other processes to access the record to bring up other data elements within that record.

If the number was not used, I need to blank out the control since I don't want to save the record with that number in it.

I realize what I've written here might not have been much help.

Oh boy. On the contrary, I'm always afraid that what I'm asking is really unrealistic or laughable .

With much fewer hair. Thanks again for your help.

Ray

[email protected] onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

View this thread on the Works forum...