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

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Having a DEBUG with GOTFOCUS can be confusing.

When you run after the DEBUG, the control gets FOCUS, causing a DEBUG… loop.

Also happens on POSCHANGED on a table, or ACTIVATED on a form.

Start the form, eg Create Dialog as MODAL.

This will wait until the processing on that for is complete, eg a selection dialog, before continuing.

Hope this answers your problem, if not please advise.

Colin

Colin,

Start the form, eg Create Dialog as MODAL. This will wait until the processing on that for is complete, eg a selection dialog, before continuing. Hope this answers your problem, if not please advise.

Thanks for your reply. After some effort in testing, breaking thing unintentionally, losing more hair and etc, I have come to the conclusion that calling Dialog_Box gave me the control that I wanted. However, it seems that because I am calling this form (Dialog_Box) from an MDIChild that I can't save the data in the Dialog_Box (also Create_Dialog) using the normal save (via F9 or clicking on the MDI Frame). Of course, one can always 'exit' out and then tell it to save, but isn't that klutzy.

I prefer not to put a Save button on this form if I don't have to (save and then close the window) as this form is sometimes called directly from the MDI frame and I preferred all forms called the MDI look alike. At present, forms don't have a save button since we're using the MDI frame stuff. Does this mean then that I will need to put a Save Button, etc on all forms to keep them looking all the same. And I prefer not to create a duplicate form - one with buttons (when called as DialogBox) and one without (called as MDIChild).

I guess what I'm really interested in doing is can I hook the save function within the MDI Frame into the Dialog_Box so I can F9 and work as other forms within the MDI Frame.

Am I expecting too much? Thanks,

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Hi Ray,

Yes, you are asking for too much.

It's really a matter of understanding what is going on "behind the scenes". A dialog box, which is just a modal window, by design and definition prevents all other windows in the application from getting focus. The very purpose of modal/dialog windows is to force the end user to deal with an issue before allowing the rest of the application from working. This obviously affects the ability to have toolbar buttons on your MDIFrame from being accessed and working with your dialog/modal window.

Dialog boxes can and should have buttons, even in MDI applications. For instance, look at your About box or your Update Application window that we added for you. Both of those are dialog boxes with buttons. Hence, it is not bad form to include these kind of windows.

I realize that this window may be called in different contexts (i.e. from another MDI child for from the MDI Frame itself) but if the desired functionality is the same, that is, focus on this window until it is completed, then one dialog box format should be sufficient.

Now having said all of that…it is possible to programmatically create an MDI child that will behave like a modal window but will allow selective functionality. Essentially you have to write your own looping logic that won't abort until the MDI child is closed. Within this loop you use Yield() statements to allow additional OI processing to occur.

Hope that helps,

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

Thanks for your response. I appreciate the confirmation. Should have talked to you sooner rather than waste hours of experimenting and pulling my hair. Of course, I do know more now (just a little.)

I shall research this Yield function. Does anyone know if Yield is used much and if I adopt this approach that it will be reliable.

Tally ho and thanks,

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

View this thread on the forum...