Why doesn't my form get focus? 3

[dsandlin]

I've got a simple little login form that opens without having the focus (i.e., it is not selected). I don't remember having this trouble with other forms....

Here are some properties that I have set on the form:

AutoCenter = .T.
ShowWindow = 2 - As Top Level
WindowState = 0 - Normal
WindowType = 0 - Modeless (This gets forced anyway, due to
the ShowWindow setting.)

I'm executing:

DO FORM frmLogin
READ EVENTS

Any ideas? Thanks! - Dick [Spin]

 

[BPeisch]

What version of VFP? Which SP? There were some problems along these lines in the original VFP 7.

Try adding this right before your Read Events:

_VFP.AlwaysOnTop = .T.
_VFP.AlwaysOnTop = .F.

-BP (Barbara Peisch)

http://www.peisch.com

 

[darrellblackhawk]

Set ShowWindow to 1 (in top level) and WindowType to 1 (modal)

If there is a top level form, you'd want the login form to
reside inside of it, and you'd definitely want it to be modal.

Darrell

 

[dsandlin]

Thanks for your posts!

1. I'm using VFP 8.0 SP1. I tried the _VFP.AlwaysOnTop toggle and I got an error:
OLE error code 0x80020006: Unknown name.
When I looked up the properties for _VFP, AlwaysOnTop isn't listed. Could it have been dropped?

2. I'm using Top Level, modeless because I want the user to be able to switch away, if desired. My second form (that follows successful login) has focus fine and it has the same properties.

3. I have an idea that I'm looking into now. The login form adds properties to _Screen and sets them. That might be a conflict with the top level form(?). ALSO: When I run the main pgm from the IDE, the form has the focus when it comes up, it's when I run it from .exe that it has the problem.


Thanks again for posting. I'll be back soon with results.

 

[dsandlin]

Here I am again with more details about my problem....

I commented out all of the references to _Screen within the login form. It didn't change anything.

I noticed that the behavior is predictable. Whatever app was current before the .exe is started retains the focus. If I have Explorer running and double click on myapp.exe, the form opens, but Explorer retains the focus. If I press down arrow, the selection moves to the file below myapp.exe in the explorer window.

If I click on the login form, it gets the focus and works fine, but it just doesn't have it at startup. ???

 

[dcollins451]

I'm having the same problem as you, dsandlin, although I'm using VFP 6.0 instead.

I'm modifying some legacy code because I was tired of the program starting out maximized. I changed the WindowState property of the top-level form from "2 - Maximized" to "0 - Normal" (my settings are now exactly like those in your first post). After doing that, the top-level form would no longer get the focus when run.

If I change it back to Maximized it gets the focus properly.

I can force the focus by having the form set to Maximized and then change it to Normal from within the form itself, after it is activated, but this is inelegant and ugly.

BPeisch, I tried your suggestion, but that property doesn't exist for my _VFP either.

I tried your sugestion too, Darrell, but it doesn't work for me. My program immediately exits when I run it with your change.

Thanks,

David

 

[craigsboyd]

Try using my FAQ to solve this problem:

Force Window to Front (not blink in taskbar)
faq184-4262

Slighthaze = NULL
_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[dsandlin]

Blimy!

It looks like the very dickens, but it works great!

I believe that you have gotten on to something there!

I wish I knew why my form is consigned to the background and has to pull itself up by attaching to another thread, but I am happy to accept a working solution, even if it seems like going around the world to get next door.

Your code worked as written. I copied it to a file, added it to my project, and called it from the Load() method of my form. It does the trick!

Thanks a million! -- Dick

 

[craigsboyd]

dsandlin,

Gald to hear that it worked for you. When Microsoft makes changes to the way basic tenants work in their OS it is not always a good thing. There may have been a simpler solution to your problem, but I sometimes feel like if you have tried to reason with the problem nicely and politely and it has refused to cooperate then it's time to hit it with a sledgehammer.


Slighthaze = NULL
_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[BPeisch]

You already have your answer but...

I usually consider _VFP and _SCREEN to be interchangeable, but it looks like that's not the case with the AlwaysOnTop property. And your app will always have a _SCREEN object, even when it's a top-level form with the screen invisible.


-BP (Barbara Peisch)

http://www.peisch.com

 

[dcollins451]

Hello all,

Slighthaze, your solution was very close to what worked for me. I tried your fix, but it always ended up making the screen visible again when I wanted to keep it hidden. Maybe it's because I'm using version 6.0 (or maybe I'm just doing it wrong).

I did find a solution that worked for me at

http://www.foxite.com/archives/0000018976.htm

and added it to the Init event for my form. Here it is:

_Screen.visible = .f.
Declare integer SetForegroundWindow in Win32Api integer
Declare integer FindWindow in Win32Api string, string
Local wHandle
With this
wHandle = FindWindow(0,.caption)
SetForeGroundWindow(wHandle)
Endwith

Thanks, everyone, for the suggestions, and thank you dsandlin for your original question.

David

 

[craigsboyd]

David,

I would be very careful using that code if you are going to run this on Win2k or above...the reason my FAQ is the way it is is because that code you just posted doesn't work the way it used to...it may bring the top level form to the top, but on the newer OS's it may just make the taskbar button blink instead. I mean if it works for you great, but the code in my FAQ is specifically designed to get around this limitation (or feature as MS would call it). The reason your _screen always came up is you were sending in the _screen's window handle (HWND) instead of sending in your top level form's HWND...whatever window's (form's) HWND you send in to that function, that is the window it is going to bring to the front.

Slighthaze = NULL
_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[dsandlin]

Well, this is a strange one, all right.

I would swear that the solution worked as I reported it on 1/22/4, but when I sent it to be tested and now when I run it, the VFP _Screen appears behind the login form maximized and empty. I tried many things to get rid of it, but it remained. Based on your last post, slighthaze, I put the functions in my proc lib and called ForceForegroundWindow(nHWND) from the Init() method of frmLogin, after getting nHWND from FindWindow(Null,THISFORM.Caption).

What results is a tiny window title bar in the upper-left corner that is my Login form. It still does not have the focus, but it is on top of all other windows.

I'm running VFP 8.0 SP1 on Windows2000 SP4.

Any thoughts? -- Dick

 

[craigsboyd]

Try moving the call to ForceForeGroundWindow(nHWND) around...say like try it in the SHOW or ACTIVATE events instead of the init. Also maybe you need to make sure that the form's windowstate = 0 and alwaysontop = .t. and autocenter = .T. before you make the call.

Slighthaze = NULL
_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[AirCon]

dcollins451 (dsandlin)

I suspect that is the problem if you use:
_Screen.visible = .f.

Use CONFIG.FPW instead and put:
SCREEN=OFF

Take a look at this: thread184-583761


-- AirCon --

 

[dsandlin]

AirCon, Thanks for your post. I tried turning off all my other corrections (back to where I was at the beginning of this thread) and putting out the Config.fpw with "SCREEN=OFF" and it worked! My login form came up as I wanted it to and it had the focus!

I think I was getting confused between being on top and having the focus. The ideas mentioned earlier were successful in getting my form to be on top, but it either did not have the focus or it had the _Screen behind it, when I wanted it to be off.

Do you think that this is a bug in VFP? Shouldn't you be able to declare "_Screen.visible=.F." from within the form and not have to burden your user with yet another file to install?

Thanks again for your help. Thanks also to all who posted to this thread. I have hopes that this will be a good solution. -- Dick

 

[AirCon]

Well, I don't know for sure it is a bug or not.
You don't have to distribute config.fpw as a separate file if you don't want to. Just include it to the project (Other->Text Files) and compile it to EXE.

Regards and thanks for the star

-- AirCon --

 

[dsandlin]

AirCon,

That sounds like a great idea. I tried putting my control file into the project and compiling it, as you said, but it didn't work.

Do you have to do something to make the program see the control file? The old way, I used a "-c" on the command line (in the shortcut) to make the control file seen.

I even tried renaming it from "myapp.fpw" to "control.fpw" and recompiling, but it still doesn't see it when I run the exe.

Please advise. -- Dick

 

[craigsboyd]

dsandlin,

Does an .exe access the contents of config.fpw
thread184-737706

Slighthaze = NULL
_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​