Hello, Mandy. Good to hear that you are making such good progress.

Place the following code in the Init of the form that you want to activate:


I think that should do what you want.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

If you put something into that Autostart folder there is no guaranteed order and priority. What becomes active last will become the foreground process and its foreground window becomes the focussed window of the whole desktop session.

We've had a lengthy disccussion about all this in an older thread. You can't control this within a single exe that wants to be the foreground process, because if any process could make itself the foreground process which no other process could override that would mean a security hole, because one viral GUI app could hinder you to use your windows OS and anything other than it.

So you can only gain partial control about this, and the best would be to have both EXEs as one, instead. What is the reason to have two executables?

Chriss

Mike Lewis,

yes, that API call makes one window of the current process the foreground window. If a second EXE in the Autostart becomes visible later, it will still override this, you can't force one EXE to be foreground forever, just for thee moment.

So in case of two executables, the one that should be background would have to know which hwnd should be foreground and, just in case it becomes the active process as last of both of them, it should set the foreground window to that other process. That will not protect against a third EXE becomeing the foregrpund window.

But before I'd go this route to at least resolve the issue between your own to EXEs, why do you actually need two EXEs? If one should be a background process for the foreground process, there are several reasons it should not simple start in parallel, buut be started by the foreground (GUI) EXE anyway, because you'd want to be the owner of that background process and be able to controll it, communicate with it, etc.

Chriss

Hi Chriss... i got a timer in the second exe, that executes in an interval time, the first exe is to accept all input for the second exe to process... i 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... so i deparated it... Thanks Chriss

Mike... I already have that one in my init... but still i have to click the first window for it to accept input from the user... Thanks Mike...

Mandy, are you saying that, even though the relevant form is now at the front, the textbox does not have focus? If so, calling the textbox's SetFocus should solve that (you would do this in form's Init, after the call to SetForegroundWindow().)

Or have I misunderstood what you are asking?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Quote (Mandy_crw)

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...

Well, that is okay, but still the way you do this is wrong, the main GUI exe should start its background processing EXE and not Windows Autostart folder, which gives ou no guaranteed order of ecxecution. But mainly, because you want to know about your second EXE, it's processID, for example, to address it.

What's the processing that takes so long that you want to go this complicated route, especially for the beginner you are, and do things in two processes? One more typical way would be to start a second EXE just to process something and quit, so just use a secondary EXE for each processing step, not one EXE that starts with the PC and runs in parallel all the time. It's much easier to pass in the data the second EXE should process in the main.prg LPARAMETERS than to establish an interprocess communication, even if you choose a simple one.

In short, since your idea didn't turn out to be that great, better than to try and fix this is to rethink it to something much simpler.

Now, if you're saying: "But it's only this one small problem", please think back how often you thought so and just didn't yet know what can of worms you just opened.

How do you even pass over data? And how do you pass back a result? Or signal finishing? Or do you think this will be easy once you got the focussed window thing right?

Chriss

Hi Mandy,

You could automatically start the first executable and start the second executable from there.
In other words, executable ONE uses “run” or a “shellexec” command to run executable TWO.

This will give you the right starting order.

Regards, Gerrit

Rule of thumb: If something takes longer than 3 seconds indicate progress to the user with a progress bar.

That says nothing about when to do something in a background process, but you can also take it for saying any shorter period is not yet worth caring for.
Also, I'm pretty sure the 2 seconds your code needs can be cut down. It would be wirth more asking about improving that thn trying to cover up by doing that in asepaate process and not even knowing how to get a window as foreground window.

By the way, in thread184-1817657: How to put my app be on top, and active...? you already used SetForegroundWindow and it didnt work. And in that thread, if you reread everythinng carefully, I told you why. SetForegroundWindow can make a window the foregroudwindow, but that's not making it a permanent foreground window. If another process is still stating and becomes the new active process with foreground window, then it's worth nothing you set your window to be fooreround window as that's overridden.

And you can't solve that sufficiently, even if you make use of a delay before using SetForegroundWindow. The easiest way is your background process last step before its own READ EVENTS will be to start the UI EXE. But even in that scenario you only solved the foreground window state and nothing else yet. I said the foreground process should start the background process, for a good reason. But it will take a long article to show you why and how.

Chriss

Here's the essence.

Lesson 1 or Realization 1:
There is no such thing as a VFP background process in terms of what background process means from the point of view of the Windows OS.

First of all, notice the foreground process in Windows is defined by having the foreground window, and you can influence that momentarily by the SetForegroundWindow API call, and you can also find out what it is by GetForegroundWindow. That's not all to it, but if you google for how to find out the foregroundprocess, the base line is to use GetForegroundWindow followed by GetWindowThreadProcessId or GetProcessHandleFromHwnd. Which means the foregroundwindow is easy to determine first and is already the essential information for the currently active process.

This is the main.prg of an EXE I just did, to check that fact:
On top of that, there is a config.fpw with SCREEN=OFF, which you know from several earlier threads.

And this is the output:


Running it several times, the hWnd windows handle differ by number, but one thing always remains the same: This VFP.exe, though it has no visible screen form, still becomes the foreground process with the foreground window, namely the never visible _vfp system variable that also is a window with a hWnd handle.

Notice several things, here: SCREEN=OFF does not mean there is no screen, it just is not made visible. _VFP and _SCREEN are two of many system variables available in any VFP process. They always exist. And they are windows, by the OS meaning of windows, with a HWnd. That's the basis of many things like the Windows OS messaging system that is based on hWnd handles.

In conjunction with the knowledge that the last started EXE becomes the foreground process it means it takes the status of the previous foregroudwindow away from the previous foreground process. You can't stop that from happening. Also if VFP would be able to build console applications, they have the console window, also a window with a hWnd. There are background processes, real background processes, but that needs more than a process without a (visible) UI.

For what you need this realization does not mean you can't implement your idea of a background process, which only needs the feature to be without a UI and a separate process that can really run code in parallel, even on a separate core of the CPU. But you need to be aware that starting your "background process" it changes the foregroundwindow. And you have to wait for that to happen to then eventually reclaim that stauts by SetForeGroundWindow to your own main form hwnd. It does not work well to do the SetForegroundWindow as soon as possible and be done with it. Always keep in mind, this is just momentarily and no process controls this status forever or can become the permanent foreground window.

Chriss

I'll continue with further Lessons/Realizations later. For now I just have one main question aside from those I already asked:

Do you want your application to be the only application that runs when a computer starts? There is a term for this, that's a kiosk system, and there are both hardware and software solutions to define a kiosk system, but that's a totally separate topic. But it might still be what you're after, too and don't even know exists. Here's a starter about that topic for Windows 10/11: https://learn.microsoft.com/en-us/windows/configur...

That has not the aspect of separating UI from a background parallel process, it has the aspect to automatically start with the system and be the only application running, like an ATM machine or a check-in terminal at an airport and many other such systems.


Chriss

I thought you'd react, but maybe I have to wait til Monday.

Anway, your answer to my first post was:

Quote (Mandy)

i 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.

I can't believe you only vagely know what takes long. You're doing some code with the input. You can measure how long this needs by doing coverage profiling. I already showed you that. Would you please post that code? Because all in all it will be much simpler to optimize it than to run it separately. The question even is whether it can be done by a separate process. If this code works on workareas of your first exe, those are not seen by the second exe. In the second EXE you don't have everything at hand that your first EXE sees. So this is not a universal solution for doing things in parallel. You are not only starting in a new general datasession in a second EXE, you can't switch datasession to one of the datasessions the first EXE has. Seperate processes mean separation of all things.

It's not a solution Foxpro developers use all the time to solve parallel execution and to be able to stay responsive for further input. You don't understand the overall complexity of this and the limits of what a second process can do or can't.

Chriss

Mandy,

are you with me/us? I want you to undertand what you're trying is quite fruitless. Because if you don't even know what code or behavior in your one EXE takes long, what do you want to move to a second EXE. It becomes very useless to show you in which way to start two exes so the first one stays in the foregound, if you don't even know what to make the second EXE do. Then you have a mechanism but still no solution. I want to help you, I really want to solve your problem. But I can't, if I know nothing about it.

Okay, I hope the first lesson has been clear: Every VFP EXE you start will take the foregroundwindow state, even if it starts no form, it will go to the _VFP system variable, which indeed also is a form. It doesn't matter that this is invisble, this also means if the background EXE starts as second process, it will take the foregroundstate from the foregound EXE. And what's most importat: It doesn't matter that your foregrround EXE had used SetForegroundWindow, this is not a function to tell the OS this should be the permanent foreground window unless you say otherwise. The OS will switch this, the user can switch this. Otherwise there could be all kind of malware that takes Windows as hostage as it does not allow the user to pick what window he wants to use. This is not what the OS will allow.


From this information you could learn that starting the foreground EXE as second exe would work. Well, if two processes start at almost the same time, their loading and initialization process can take slightly different times and you sometimes end up with a frontend in focus and sometimes not.

Lesson 2 / Realization 2:

Mandy, so how do you get the foreground state to the foreground EXE, if you can't be sure how Windows starts what is in the autostartfolder and how it turns out, depending on a gazillion other things all starting when the computer starts? How can you gain full control of what happens? You have to start one EXE from the other, so there is a definite starting order. And I already told above

Quote (myself)

the main GUI exe should start its background processing EXE and not Windows Autostart folder, which gives you no guaranteed order of ecxecution

Why not the other way around? Well, becuase if you start the second non GUI EXE first, let it start the other EXE with the forms, then the UI becomes the child process of the background process. And that's bad, because of what I already showed you:

Quote (SetForegroundWindow)

The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:

The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The process is being debugged.
The foreground process is not a Modern Application or the Start Screen.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
No menus are active.

Not only SetForegroundWindow has such privilidge restrictions. You want your main process to be the one that starts the background, even though then the background EXE is started last and removes the foreground state. But now you have it in your hands to forward the Hwnd to the background EXE and make it the first task to do for it, to set the foreground back to the first EXE. That's how you solve this.

first EXE main.prg:

second EXE main.prg:

This at the start of the second EXE makes your first exe the foreground again.

There's still no guarantee at the starrt of a computer, no other application will also start and get the foreground state, you're really lamenting about a thing that may need a click from the user anyway, when there are further windows starting on the desktop. Even if your own two EXEs play their role with each other. On Windows, your application is never alone. So, it's actually a detail solution that will not really bring you forward a decent step towards untangling what would really help to improve the responsiveness of the first EXE - without a second EXE.

Mandy, I beg you please don't continue even if that solves your problem, you still have to think about how to communicate between these processes, and how to ensure if the first EXE is quit by the user, the second EXE also quits to not leave endless running background processes, just because you still only have two processes, but have in no way connected them to each other.

Mandy, in your old thread I gave you code for a COM server. That is not started as a normal EXE, that is started by CREATEOBJECT() with a comserver class name. And that is indeed one way you get a new process that doesn't even cause this problem at all. And you have a reference to that background process, and you can program any method you want iside it. You already have a solution, Mandy, you just disregarded it.

Chriss

Hey Everyone,

With all due respect, I have to say that this thread ranks in the top ten of all the absurd threads I have ever read.

Chris, you are a smart guy - but dude, you sure know how to get into the weeds on things. Please learn how to be concise - you cannot expect people to get into the weeds with you.

And Mandy. Without your um, well um questions, this board would have to shut down. Is this the only way (or place) you are learning VFP? Are you being paid to ask questions here?

TIP: You can have two EXEs communicate with each other using the WM_COPYDATA message

Hi Vernspace,

I do this on purpose, because you don't get a memorable lesson, if you just would give a solution, as is often demanded, not only by you.

You know, I could also say do this:

1. start the second.EXE with autostart, and in it do this main.prg:

This works, too. It concisely, precisly and explicitly only solves the foreground problem.

This is not what I want, and I will never answer in such ways. I also get an impression of memebers, who post more regularly or by looking into their post history, so I adapt my answer to that impression.

You're making a concise remark about how to establish interprocess communication. But then there's much more to that, too and it's yet not even a good birdview descpription, you make use of SendMessage and BindEvent to use the Windows message queue and then in dtail see WM_COPYDATA is away to bring over a chunk of bytes, which could be anything and thus it's a universal communication possibility.

But then you still overlook the solution I already gave using a COM Server for the background process. Create a VFP COM Server and a) you have no foreground state change, b) you have a reference to the background process, c) you can pass object references to it, which it then can use. And I bet Mandy needs that, if the background process should, for example, care for an animation on the input control, while the input control is responding to the next input already.

Every ingredient for that was already on the table in thread184-1817657: How to put my app be on top, and active...? and this thread also is that absurd because even after I pointed to it so many times, there's still no understanding of it, obviously.

Chriss

For what it's worth, I wrote an application a few years ago where the main EXE launches a second EXE to run in the background. I used a DBF to pass information between the two, and it worked very well - better than I had expected. I'm not saying it's the best solution (it could be that a method that uses WM_COPYDATA would be better), but it was fine for my needs.

And it might well have been better to use a COM server rather than the second EXE. I tried the two EXE approach as a bit of an experiment, and when I saw how well it worked, I didn't pursue any other methods.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Mike Lewis

We use two separate exe and the second one is started with ShellExecute from the first one, which creates a separate thread.

If you want to get the best response to a question, please check out FAQ184-2483: How to get the best response from the forum first.

Mike Gagnon, that's exactly what I did as well.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Hi everyone… sorry for not answering immediately… to vernpace, i am not being paid to ask here, those question that i have asked were relevant to my project… and all you suggestions are taken noted well…

To Mike and Chriss.. i am so thankful that you you give me answers always…

I have been working with the foreground problem, and while reading all your answers, i was overwhelmed by the info, so i need to read well to understand it well.. im really sorry…

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…

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....

Your description is better.

Quote (Mandy_crw)

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?

Quote (Mandy_crw)

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:
Build it as SendSMS.exe, for example

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

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

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…

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

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

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

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....

Quote (Mandy_crw)

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

Quote (Chris)

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

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

HI everyone.... its been month that i have been observing my application... 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

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

>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

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:

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

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

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:

Quote (Mandy_crw)

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

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