setting focus on EXE run

[ravicoder]

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

 

[arrayname]

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()

 

[Chriss Miller]

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.

 

[ravicoder]

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

 

[Tore Bleken]

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.

 

[Chriss Miller]

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):

Setting	Description
0	In Screen (Default). The form is a child form that is placed in the main Visual FoxPro window.
1	In 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.
2	As 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.

 

[ravicoder]

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

 

[Chriss Miller]

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.

 

[ravicoder]

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

 

[Chriss Miller]

a standard top level form with read events

The read event hopefully is not in the form init or load, is it? You have to have the read events after the DO FORM call in the startup.prg

 

[TamarGranor]

@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

 

[Chriss Miller]

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.

 

[Chriss Miller]

Btw, what I suggest was also suggested by Mike Lewis here:

Thread 'Login screen question'

Nov 9, 2009

Hi all,

I have a app that has only one "2- Top level form" (form1) with a menu inside the form. Now, I like to call a login screen before the "form1" is called. I try to use the following code but is not working because the program execute till the READ EVENTS. Should I call the "DO FORM form1" inside the "loginscr" screen after the user successfully login? Again, I try to make the login as generic as possible so that I can use the same login scrren in every where. My VFP skills is quite rusty now...Please help.

****************************
loginsuccessful=.F.
DO FORM loginscr
IF...

• fredgmain
• Replies: 2
• Forum: Microsoft: FoxPro

He's using a private variable to store the login status, your choice. But after Mike Lewis suggestion this prg should look like this:

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.

 

[ravicoder]

Hi all

sorry for delay in replying

I do have a startup.prg which says

do form login_form (a standard top level form)
read events

in the form I have a thisform.txtUserid.setfocus() in the init event

i have a clear events in the unload method of the form when the user clicks on the cancel button (release thisform) which I have given

Everything works as it should but the issue I was facing was not getting focus on the first field in the form even though it was the 1st in tab order. i rearranged the tabs and then new issue was that the form used to start and immediately minimize to taskbar. Very Strange.

I then inserted a line before the do form in startup "wait wind nowait loading..." then wait clear in the init event of the form and now everything is working as it should. form pops up with the focus on first textbox and waits for input. strange behaviour. I tried to deep dive in what was going wrong but was unable to do so. hopefully I will get a clue and will be able to share it here

thanks for all the responses. really grateful

Regards
Ravi

 

[Tore Bleken]

Init may actually be to early for the setfocus, it belongs later in the event chain. Try to put it in Activate instead.

 

[Chriss Miller]

Well, you don't need it at all. Are you using native base controls or some framework? You might have inherited framework code that lets things work off normal behavior, i.e. you would need to dig into framework documentation on how to use framework forms and controls the right way.

Also, from what you describe a user could click cancel or the top right X button on the login form and be done with the login. In short, you don't describe how you handle the login status. It's not important to address the focus and minimizing problem, but I hope you're aware you could have given users a potential simple way to bypass the login and get in. Another usually overlooked way is using CTRL+0 to enter a NULL value into a textbox that overthrows logic with simple = or also == comparisons. But that's just another topic.

I redid what you describe and there's no problem like not getting focus on taborder 1 control and no problem of the form minimizing. So I can't reproduce your problem. No form just minimizes unless you set WindowState to 1 (Minimized). Default is 0 (=Normal). The only other idea about such things I have is tools/utilities for systems with multi display setups that automate centering a started application on a(nother) display, but I don't know any tool that would minimize a window, they all just aim at helping a user find an application on screen, not hide it.

Default Windows behavior is also storing the position of an application window, but even trying to minimize the login form and end the application with task manager, next time starting it does not make it start with minimized login form.

So I really can't reproduce your problem. You're either skipping an important part or it would need to have to do with OS version, some OS setting, some multi display setting or third party utility interacting with application windows. This is not coming from FoxPro unless you act on the WindowState. Adding in a wait window wouldn't explain why anything acting on the WindowState would then not minimize the form anyway, though.

I can only encourage to set up a minimum project with just a login form (doesn't even need to have the actual login check in it, nor any data) and the startup.prg, zip it all up and attach that zip here. If using a framework, pay attention to not breaking your license by adding framework libraries etc, that you're not allowed to distribute.