Thanks Tracy. Appreciated.

I suspect it has something to do with a setting on the main desktop form.

Mike

Tracy Pearson wrote:

Mike Copeland wrote on 2016-04-21:

...

All,

I have that "seen it before" nagging feeling about this problem...that I've seen the problem discussed here but I haven't located any answers.

I have a form set as "As Top-Level Form" I have a second, modal form, set as "In Top-Level Form"

After closing the second, modal form with close button on the second form, the close button on the Top-Level Form is not clickable (dimmed out) so you can't click it and shut the program down.

But if you click "somewhere else" on the desktop, anywhere other than the Top-Level Form of the Foxpro VFP9 SP2 application, then you CAN click back on the Top-Level form and the close button is bright red and can now be clicked and the program closes.

What in the heck is causing that and more important what is the

workaround?

...

Thanks for any advice!

Mike Copeland

Mike,

I'm unable to reproduce the behavior you speak of. I know I've heard it. I don't work with that many top-level projects that have modal dialogs. I have 1, and customers have not complained about it. VFP 9 SP 1 - multiple OS's Just tested a small project VFP 9 SP 2 patched to 7423 on Windows 8. I'm not seeing the behavior.

Tracy Pearson PowerChurch Software

[excessive quoting removed by server]

Thanks Stephen!

Unfortunately, I get the error "Cannot find entry point SetForegroundWindow in the DLL"

Maybe because this is Windows 7 Pro?

I also tried the API call for SetActiveWindow....no effect.

I think it's likely due to my having disabled something on the modal form. What DOES seem to be helping (still testing) is to simply add ACTIVATE WINDOW Formname (where formname is the name of the main form). If further testing proves this to be a solution I'll update this thread.

Thanks for the input though!

Mike Copeland

Stephen Weeks wrote:

Put this code block after the form call in the top level form :-

DO FORM MYFORM

declare integer FindWindow in USER32.dll integer, string declare integer SetForegroundWindow in User32.dll Integer WindowTitle=chr(34)+alltrim(thisform.caption)+chr(34) winHandle = FindWindow(0,&WindowTitle) if winHandle > 0 SetForegroundWindow(winHandle) endif

I use this across all my applications and it worlks a treat !

On Fri, 22 Apr 2016, at 10:39 PM, Tracy Pearson wrote:

...

Mike Copeland wrote on 2016-04-21:

...

All,

I have that "seen it before" nagging feeling about this problem...that I've seen the problem discussed here but I haven't located any answers.

I have a form set as "As Top-Level Form" I have a second, modal form, set as "In Top-Level Form"

After closing the second, modal form with close button on the second form, the close button on the Top-Level Form is not clickable (dimmed out) so you can't click it and shut the program down.

But if you click "somewhere else" on the desktop, anywhere other than the Top-Level Form of the Foxpro VFP9 SP2 application, then you CAN click back on the Top-Level form and the close button is bright red and can now be clicked and the program closes.

What in the heck is causing that and more important what is the

workaround?

...

Thanks for any advice!

Mike Copeland

Mike,

I'm unable to reproduce the behavior you speak of. I know I've heard it. I don't work with that many top-level projects that have modal dialogs. I have 1, and customers have not complained about it. VFP 9 SP 1 - multiple OS's Just tested a small project VFP 9 SP 2 patched to 7423 on Windows 8. I'm not seeing the behavior.

Tracy Pearson PowerChurch Software

[excessive quoting removed by server]