How to activate window? 4

[Mandy_crw]

Hi everyone... my project is finish and already done two executable files... these two executable file were put in the shell:startup so that both application would automatically open everytime computer starts... both files open perfectly... my problem is, the second application is active instead of the other one which has a textbox that waits for an input... My question is, how can i make that window that has a text box to be active and not the other window? Thanks in advance Everyone...

 

[Mandy_crw]

Yes Chriss… im following your suggestions… im rethinking how to achieve what i wanted through your suggestions… thank you so much for being so kind always Chriss… godbless you…

 

[Mandy_crw]

Hi Chriss... the application is sending an sms message using usb modem, so eveytime it sends, it would take some time, so my application hangs when a consecutive and fast entry (scanner) is inputted so i decided to redesign it, so i decided to separate an application that would handle all pending messages (I got the idea from searching to the internet...) so that the first application would que all inputs

But i have noticed, i tried running the data entry app in other cmputers, there are computers that sets the application to foreground and waits for entry and some computers needs to be click for the data entry...

sorry for my explanation... i hope i have explained it well so that you can help me... Thanks and God bless you always Chriss....

 

[Chris Miller]

Your description is better.

the application is sending an sms message using usb modem, so eveytime it sends, it would take some time, so my application hangs when a consecutive and fast entry (scanner) is inputted

So you have a perfect idea what code you want the second EXE to do, then why did you say this?

separated it because when it was only one exe, it has to wait for a second or two seconds of a time (maybe because it processes data first) before the first exe can continue to accept another data for process...

This was not sounding like you know what to use a second EXE for, but thinking along the lines - "If I give VFPs runtime two processes, it can do whatever it has to do faster." - no, that's not how that works.

As you know you want the second EXE send SMS, then I suggest you do the following in your second exe main.prg:

LPARAMETERS tcPhonenumber

*...code for sending one SMS

Build it as SendSMS.exe, for example

And now, in your first EXE just whenever you want to send an SMS you can do

Local lcPhonenumber
lcPhonenumber = Thisform.Text1.value && adapt to your needs
RUN /N SendSMS &lcPhonenumber

No second EXE that has to be in autostart, so only one EXE in the autostart, which - as you will see - will have the foreground state.

This foreground state, Mandy, as you likely have not realized and not read this thread, is something that CAN'T be fixed and guarantueed. The only EXE in an Autostart folder is likely to be the one that will run last and thus has the foreground state. But at the start of a computer, many things start, and some ask users for attention, for example antivirus is telling you to update or extend a subscription.

There is absolutely nothing that can guarantee your autostart EXE to be the one that has focus. There is a method that has a higher probability than Autostart, that is using a scheduled task, which can have starting conditions to start after a Windows user session started AND the system became idle. And starting THEN means very likely being the EXE that will get the focus.

Or - which is the simplest of all methods, you don't autostart anything at all, just put a desktop shortcut or add a taskbar icon so your EXE can be started when needed. And when a user starts an application, that also becomes the foreground process automatically.


Chriss

 

[Mandy_crw]

Hi Chriss!! I’ve used what you have suggested, i started the second app (and set it to minimised) from the first app using run /n (filename.exe) and it worked. But i got another question, i need to change the filename to one word only, because if i use two word filename, it always say that file not found though the is there… is there a way to run exe with two word filename? Thanks in advance Chriss…

 

[Mike Lewis]

Many,

In general, a filename can have as many words as you like. The problem is that VFP sometimes chokes on that, because it thinks the end of the first word is also the end of the entire name, which it isn't.

It's usually possible to work around that by putting the variable containing the filename in parentheses. But it's better to avoid the situation completely, for example by using underscores instead of spaces.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

Hi Mike… thank you so much… ill just put underscore… thanks again… God bless…

 

[Chris Miller]

Well,

either use underscores, as you do, or use double quotes around the file name, like Run /N "second process.exe". Just like you need to do in the shell or in DOS.

What Mike suggested was using lcFilename = "second process.exe" and then use (lcFilename) as a so-called name expression. Well, that works almost anywhere, but not in the RUN command. VFP is kind of not executing the part after RUN, that is only provided to cmd.exe (or command.com in earlier versions of VFP/Windows). So it's good and good luck you chose the underscore option.

I proposed another solution with COM Server, I will be posting about that in a separate thread, when it's more ripe to be presented. It's even easier to get it working, but it can lead to many processes kept running after the COM objects are released. I solved that already, but it's not as convenient as I'd like it to be.

Chriss

 

[Mandy_crw]

Ok Chriss.... Thank you so much... my app is completely working... but as i use it, and my co worker i tend to see more needed feature for refinement... so most of the time i run to you Chriss and Mike and everybody here in the forum to help me... Thank you big time everyone... God bless....

 

[Chris Miller]

but as i use it, and my co worker i tend to see more needed feature for refinement.

That's the normal state of an application, there's nothing special about this. There are very few things I did that some day were finished and never enhanced or extended. Progress is the normal state of any application.

Chriss

 

[Steve Meyerson]

That's the normal state of an application

I can attest to that!

For example I don't require a prospective client to a written set of requirements. It can be a waste of time. Instead I take notes from an interview knowing additional requirements & ideas will occur to them once they run my first go. They are (normally) human. I expect that & build it into my estimate. The result is they get exactly what the want, they're pleased and I make money (usually).

Just sharing.

Steve

 

[Mandy_crw]

True enough Steve... I want to thank you also for you help... God bless

 

[Mandy_crw]

HI everyone.... its been month that i have been observing my application...

 DECLARE INTEGER SetForegroundWindow IN WIN32API INTEGER
SetForegroundWindow(thisform.HWnd)
CLEAR DLLS "SetForegroundWindow"

this code is already present in my int (). In a debug mode when run, it focuses in the page i have set and focused on the textbox that i set focus on... but when i install the application, and try to open it using shell:startup it does not activate the window, its open but it not active... i still need to click the window (application) so that it can accept input from the keyboard. but... there is one computer in my workplace that when run (shell:startup) its ok, the window is active... it can accept input from the keyboard immediately without clicking the window (my application)... i want to ask to please help me answer why in other computer the app is not active, although i have installed the same application? ( my application) thanks and God bless

 

[Chris Miller]

If you look back, the answer is already there, Mandy.

You can always only insure that right after SetForegroundWindow that window is forground. But if you start two processes, then some of the times the other still takes that foreground state from you, other times not. You can't force a window to stay foreground forever. There is no "Alwaysinforeground" state. The user is always capable to activate another window of the same or another application.

And what starts up and becomes visible last also is activated.

So what you can only do is activate a window "for the time being". It's difficult though, that doesn't even guarantee "the next few seconds. You start two executbles and you dont control which one starts last. That's the one that will get the foreground state.

A better control about this is gained, if one starts the other. Because then ou have a guaranteed starting sequence.

But, again another reason of sabotage: Any third process starting can take the foreground state. And espececially in the start of a system there are many processes starting. Not only your application. You really have bad chances, so in short it's better you live with the necessary single click.

Chriss

 

[strongm]

>There is no "Alwaysinforeground" state

For historical accuracy ... there used to be, back in ancient times. A monstrosity called system modal. Fortunately Microsoft got rid of it

 

[Chris Miller]

There's a way you can prove to yourself the SetForegroundWindow call did work, and you can't do better. Check what hwnd GetForegroundWindow returns.

So do this:

DECLARE INTEGER SetForegroundWindow IN WIN32API INTEGER
DECLARE INTEGER GetForegroundWindow IN WIN32API
SetForegroundWindow(thisform.HWnd)
lnHWnd = GetForegroundWindow()
CLEAR DLLS SetForegroundWindow
CLEAR DLLS GetForegroundWindow
If Inlist(lnHWnd,thisform.HWnd,_screen.HWnd,_vfp.HWnd)
   Messagebox("You set the foreground window.")
Endif

But, what happens even just a millisecond later is not in your control. And so finally, something else can have the foreground state anyway. It's not your programming fault, but you expect too much of setting the foreground window. It's not set forever. It's not even set until the user changes it. Any process can change it. So it's not in control of the user, or your code. At the start of Windows a lot of processes get started and one of them, by chance, not always the same, will be the last process and get the foreground state.

And the timespan for which Windows is chaotic about the state of all starting processes of the system can take quite a while, even a few minutes. The start of Windows was optimized since Windows 95 or XP to show the desktop earlier, even before many important system and systray processes still are starting up. Windows seems to already be there for you, the user, but if you start anything, even just notepad, it takes "forever" until it actually starts. Because there is still a lot of activity.

So, you have no control over it, you can't program something better, too.

But notice, this shows you a general idea if you doubt your code works, think there's something incomplete about it, you usually write code that verifies it, in this case using GetForegroundWindow to verify SetForegroundWindow. So also take that idea with you. You can answer your own question with this, often. Did my code do what I expect it to do. Well, verify it. By code.

And, by the way, I don't just check whether the foreground window handle returned by GetForegroundWindow is thisform.Hwnd, which you set. Because I know more about how Windows works internally, it may redirect the state of the foreground window to the main process window. So it may look for parent windows of the hwnd you specify. So in the end, not "thisform", but _screen becomes the foreground window. Or, as I also showed above in one post, _vfp becomes that, and you get _vfp.Hwnd returned. The foreground state is a state of a process more than of a window, indeed.

Chriss

 

[Mandy_crw]

Thank you Chriss.. Is it alright to remove all processes that are not needed in maconfig?

 

[Chris Miller]

Mandy,

no matter what you optimize about the Windows start process, you don't get enough control so you can guarantee that your foreground process gets the foreground state in the end. Forget any efforts about that.

You already got your two EXEs aligned so they always start in the same order, as one starts the other. As you said earlier in this thread:

I started the second app (and set it to minimized) from the first app using run /n (filename.exe) and it worked.

But that's how far you get it. You can't decide when in all the starting up of system and third party processes your two processes get started. You never have full control over that. I don't know whether you can tell the OS to postpone your EXEs as the last thing the OS startup executes. And even if you could, you never can control any third-party executables not in control of the OS to start further EXEs, just like your EXE does, and in the end, take away the foreground state.

I don't know if I mentioned the idea of a kiosk system here or in any of your other threads, but this seems to me what you would need technically, a system that is specifically designed to only run one application, a kiosk application. There is specific hardware about that and specific OS variants or settings. But that also makes it a totally different system. One that isn't a normal client workstation anymore.

But I still doubt a kiosk system is really what you want. So I'd just recommend you stop here and don't invest more time on not getting this to work. All this effort, just to spare a user one click.

I can tell you that SetForegroundWindow is the right API function. There is BringWindowOnTop, and while trying anything else always is a straw that might help, I can tell you that will only literally bring a window to the top, it does not, therefore, become the foreground window that receives the keyboard-related windows messages, which is what you want your window to be. SetForegroundWindow is right about that aspect.

And even if there are some more functions available in the Windows API that focus on the aspect of which process and window gets the keyboard input, I know for very sure, that the foreground process state is not something you can take in your hands forever anyway. This would mean deciding about a system modal state, and as strongm said already, Windows had that, but MS removed it, fortunately. It would allow one malware process to take your desktop session hostage.

Chriss

 

[Mandy_crw]

Oh I see.... Thank you so much Chriss for explaining it to me... always.... God bless!