Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

setting focus on EXE run

ravicoder

Programmer
Joined
Apr 29, 2006
Messages
50
Location
IN
Hi all

I have an application with a login screen as the 1st form which appears which has a txtUserid and a txtPassword as the 2 input fields on the form and I have compiled it into an EXE which runs fine.

A small issue is when the exe runs the focus does not come on the txtUserid even though I have explicitly mentioned in the init event as thisform.txtUserid.setfocus(). I have to click again on anywhere on the form then the txtUserid gets focus. This is happening only in the EXE and not when i run through the foxpro environment.
I have also put the thisform.txtUserid.setfocus() line in the activate event of the form but no go..

Any Ideas?

Thanks & Regards
Ravi
 
What is the TAB INDEX on the fields? They should be 1 and 2.

If there are only two fields you should not have to issue any code to make sure the first field is selected. My guess is the tab index is not right, or code is in the form that is issued after you setfocus()
 
Usually you only set the taboder of the element you want to have focus first to 1 and that's it.

Is the focus nowhere on the form? Then something is strange about the EXE as the primary form and it's primary control (with taborder 1) should be focused, also the main form of an EXE itself is activated when an EXE starts.

If you do anything unusual like starting further EXEs at init of your application you may cause your EXE to not become the currently activated Windows application and focus is not only not on the control you want to have focus, your main form isn't even active. And then only activating it, even just by clicking the titlebar, will get the focus where you want it.

Usually you don't have to do anyting to get there, Windows will activate the main window of a newly started EXE. If that isn't the case you can use code to setfocus to anything you want and make it as often as you want, as long as through any reason any other application/process becomes active your form won't have the focus.

See it this way: Not only your application, all applications running on Windows all together only share one mouse pointer and one text cursor blinking, and while the mouse cursor is not depending on an active window and can be dragged anywhere, the text cursor will only blink in the currently active window of Windows, in one application, not in all applications at once. Otherwise where should a keypress go to when you use the keyboard?

So mainly, you will need to take care of that, normally you shouldn't need to, as I think I already mentioned twice, so very very likely you or whatever application framework you use does start some other processes and some of them become the main active Windows process, not your EXE.
 
Thanks Chris

I set the txtUserid field to the first control order on the form and it is doing as desired

Now new problem is that I recompiled th exe and when I double click to run it, it starts and immediately minimizes to the taskbar instead of appearing on screen. Am at a loss for this behaviour as Nothing of this sort has happened in any of my previous EXEs. trying to compare with previous screens to find out if any property is incorrectly set
this current screen is set as top level form and modal

Regards
Ravi
 
Thanks Chris

I set the txtUserid field to the first control order on the form and it is doing as desired

Now new problem is that I recompiled th exe and when I double click to run it, it starts and immediately minimizes to the taskbar instead of appearing on screen. Am at a loss for this behaviour as Nothing of this sort has happened in any of my previous EXEs. trying to compare with previous screens to find out if any property is incorrectly set
this current screen is set as top level form and modal

Regards
Ravi

Sounds like missing Read Events after the Do Form command.

NB! Please ask new questions in a new thread.
 
You can't have controls without any taborder, I wonder how it was to not work, if taborder fixed it. Because even if the textbox has taborder 2 and a label before it has taborder 1 the focus will go to the textbox, as a label can't have focus.

Tore hit the reason for your second problem, you need a read events as a top level form won't behave modal, no matter if you set the WindowType property that way or not.

Help about the ShowWindow property (click expand to see the important point):
SettingDescription
0In Screen (Default). The form is a child form that is placed in the main Visual FoxPro window.
1In Top-Level Form. The form is a child form of the active top-level form, which can be the main Visual FoxPro window or another top-level form. Use this setting if you want the child form to be placed inside the active top-level form.
If nExpr is set to 1 when the top-level form is the main Visual FoxPro window, Visual FoxPro automatically resets nExpr to 0.
2As Top-Level Form. The form is a top-level form in which child forms can be placed. Note that a top-level form is always modeless, regardless of the WindowType property setting.
 
Last edited:
Hi

I did a simple expedient of issuing a wait window "loading ..." before the form loads and then wait clear after form loads. Everything is just fine and working well now

thanks for all the advice and suggestions

Regards
Ravi
 
I don't know what you're solving with the wait window, but if you got everything going now, that seems to be fine. If you don't have a main.prg now to do the READ EVENTS after stariting the main top level form, you should consider that, though. Because anything else should not work and if it does, that's not a clean solution.
 
Chris

I do have a startup.prg in all my applications in which I do all my required settings like >> set procedure to, needed global variables etc and others. I then call the login form which is a standard top level form with read events. the form comes up but focus is not on the first field I have to click anywhere on the form and then the field gets the focus
very strange but now that I have a workaround, It works as desired

Thanks
Ravi
 
@ravicoder I think people are misunderstanding what you're saying. As I understand it, your application starts, but then it minimizes to the taskbar. Is that right? I think others think you're saying that it starts and then immediately shuts down.

Assuming I'm right, first question is whether this happens when you run from the Command Window or only when you run the EXE.

Tamar
 
The focus of the first control was the problem, not the form minimizing. In post #4 it was solved by taborder, in post #8 it came back. No idea what he's doing. Without any code at hand hardly doable, isn't it?

What you want, ravicoder, only needs two lines of code in the main startup.prg, nothing more, just the DO FORM of a top level form with as many controls you need for the login with taborders set and a READ EVENTS line after that. Windows will make the top level form have focus and VFP will make the textbox with taborder 1 have focus. No code necessary other than that and then build on top for the login and data usage, obviously.

Well, and read about READ EVENTS in the help. The way to get out of it is a CLEAR EVENTS. Which could be in a menu item for exiting your application, could be done in unload of a main form, usually. As you untypically use a top level form just for a login, the unload of that should CLEAR EVENTS and then you would DO FORM mainform and have another READ EVENTS after that, for example. Many ways to do that, usually an application only needs one READ EVENTS, as you start with a main form that could start a modal child login form that prevents usage of the main form before the actual login, or let the main form remain hidden until the modal or secondary top level form login form returns with logged in state set.
 
Last edited:
Btw, what I suggest was also suggested by Mike Lewis here:

He's using a private variable to store the login status, your choice. But after Mike Lewis suggestion this prg should look like this:
Code:
Public loginsuccessful
loginsuccessful=.F.
DO FORM loginscr
READ EVENTS

IF loginsuccessful
   DO FORM form1
   READ EVENTS
ENDIF
The loginscr form will need to set loginsuccessful=.T., when the user logs in with correct user/password and then release and CLEAR EVENTS to go on after the first READ EVENTS. I think with a form, not a sceen, this private variable will only be in scope in loginscr.load and loginscr.init, then go out of scope for say a button.click event of the loginscr form, so you'll need something else, but you get the idea. The simplest fix would be making it a public variable, which I therefore did. Not the best solution, but will do.

This code is also a bit amended in one other aspect: It makes no sense to keep the EXE going with READ EVENTS when loginsuccessful didn't change to be .T., so I put the second READ EVENTS in the IF branch, which starts the main form1 after a successful login. After unsuccessful login the EXE quits, as there is no further code or READ EVENTS. As simple as that. Another option is not using a loginsuccessful variable but let the login form QUIT after unsuccessful login and release after successful login.

And what specifically you do in the IF branch is fully up to you, there could also be a menu you run first, the main form could have a menu or you only start a menu on an empty screen, display a toolbar, some main button group to start into several sections of your application or whatever you fancy.
 
Last edited:

Part and Inventory Search

Sponsor

Back
Top