Foreground process
-
Please have a look on CreateThread[^] function. Some good examples you can found on http://www.codeproject.com/threads/[^]
-
What do you mean by "foreground process?" Windows does not have the concept of foreground/background processes. This is a concept from platforms such as Unix.
"The largest fire starts but with the smallest spark." - David Crow
-
What do you mean by "foreground process?" Windows does not have the concept of foreground/background processes. This is a concept from platforms such as Unix.
"The largest fire starts but with the smallest spark." - David Crow
It does. Just not exactly in the *nix sense. @Topic Basically, if you start a program - either under Unix or Windows - its a foreground-process. Its the background-processes which need special consideration. Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
-
It does. Just not exactly in the *nix sense. @Topic Basically, if you start a program - either under Unix or Windows - its a foreground-process. Its the background-processes which need special consideration. Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
Sebastian Schneider wrote:
Its the background-processes which need special consideration.
Windows does not have "background processes." Please explain what you are referring to.
"The largest fire starts but with the smallest spark." - David Crow
-
Sebastian Schneider wrote:
Its the background-processes which need special consideration.
Windows does not have "background processes." Please explain what you are referring to.
"The largest fire starts but with the smallest spark." - David Crow
-
My problem is that, I want to make a window active ( foreground ). When i do this, the window icon in the taskbar is flashing. Not getting exact focus. (Used function 'SetForegroundWindow()') Please comment Krishnakumar
This behavior is by design (for Windows 2000). Instead of bringing the window to the front, it simply calls
FlashWindow(). As a workaround, try:if (GetForegroundWindow() != hWnd)
{
DWORD dwThreadID1 = GetWindowThreadProcessId(GetForegroundWindow(), NULL);
DWORD dwThreadID2 = GetWindowThreadProcessId(hWnd, NULL);if (dwThreadID1 != dwThreadID2) { AttachThreadInput(dwThreadID1, dwThreadID2, TRUE); SetForegroundWindow(hWnd); AttachThreadInput(dwThreadID1, dwThreadID2, FALSE); } else SetForegroundWindow(hWnd); if (IsIconic(hWnd)) ShowWindow(hWnd, SW\_RESTORE); else ShowWindow(hWnd, SW\_SHOW);}
"The largest fire starts but with the smallest spark." - David Crow
-
Sebastian Schneider wrote:
Its the background-processes which need special consideration.
Windows does not have "background processes." Please explain what you are referring to.
"The largest fire starts but with the smallest spark." - David Crow
Would a Win32 Service be considered a type of "background process" (quotes intentional), akin to dæmons (demons) in *nix? Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
Would a Win32 Service be considered a type of "background process" (quotes intentional), akin to dæmons (demons) in *nix? Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)Win32 services are similar to Unix daemons, but it is not the same concept as "background processes"
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it. -- modified at 10:55 Friday 2nd June, 2006
-
It does. Just not exactly in the *nix sense. @Topic Basically, if you start a program - either under Unix or Windows - its a foreground-process. Its the background-processes which need special consideration. Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
Sebastian Schneider wrote:
Just not exactly in the *nix sense.
What do you mean by that?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Sebastian Schneider wrote:
Its the background-processes which need special consideration.
Windows does not have "background processes." Please explain what you are referring to.
"The largest fire starts but with the smallest spark." - David Crow
I just checked: Windows allows you to optimize your computer for "Application" or "Background Services" (German Windows XP Pro). Ill admit that services are more likely the "Windows version" of "system daemons". But, well, if you are not using an applications windows, it will literally be "behind" another application. You are unable to use that application until you click its windows and thus "bring it to the front". And that is just what background processes under *nix are like: You specifically put them in the back to use another application and be able to return to them later on without restarting them from scratch. I admit that "foreground processes" and active windows / "background processes" and inactive windows do not follow the exact same definitions under *nix and Windows, but they are similar enough to use the term". Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
-
Sebastian Schneider wrote:
Just not exactly in the *nix sense.
What do you mean by that?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
See my previous post. I consider this to be a "religious issue", so you might want to not reply to that. I am probably gonna be ripped apart soon... ;) Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
-
This behavior is by design (for Windows 2000). Instead of bringing the window to the front, it simply calls
FlashWindow(). As a workaround, try:if (GetForegroundWindow() != hWnd)
{
DWORD dwThreadID1 = GetWindowThreadProcessId(GetForegroundWindow(), NULL);
DWORD dwThreadID2 = GetWindowThreadProcessId(hWnd, NULL);if (dwThreadID1 != dwThreadID2) { AttachThreadInput(dwThreadID1, dwThreadID2, TRUE); SetForegroundWindow(hWnd); AttachThreadInput(dwThreadID1, dwThreadID2, FALSE); } else SetForegroundWindow(hWnd); if (IsIconic(hWnd)) ShowWindow(hWnd, SW\_RESTORE); else ShowWindow(hWnd, SW\_SHOW);}
"The largest fire starts but with the smallest spark." - David Crow
-
I just checked: Windows allows you to optimize your computer for "Application" or "Background Services" (German Windows XP Pro). Ill admit that services are more likely the "Windows version" of "system daemons". But, well, if you are not using an applications windows, it will literally be "behind" another application. You are unable to use that application until you click its windows and thus "bring it to the front". And that is just what background processes under *nix are like: You specifically put them in the back to use another application and be able to return to them later on without restarting them from scratch. I admit that "foreground processes" and active windows / "background processes" and inactive windows do not follow the exact same definitions under *nix and Windows, but they are similar enough to use the term". Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
There are subtle differences between an application that does not have the focus in Windows (which you are equating to "background") and actually backgrounding an application in a *nix system. In Windows, you cannot pause an application that was started on the command line and then tell it to resume in the background (that is, without control of stdout). On top of that, you cannot tell the very same application that you want to have it resume control of the console (stdout). Effectively, all processes in Windows are background applications. That is, when you double click their icon to start them up, they don't have a stdout. When you do start an app from the command line (assuming it is a GUI), it doesn't have a stdout by default (though, you can jump through some hoops to give it one). The concept of "foreground" is different in Windows as well. The foreground application in Windows is whatever application has the current focus. This isn't the case in *nix systems, where you can have as many foreground applications as you have consoles open for. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
There are subtle differences between an application that does not have the focus in Windows (which you are equating to "background") and actually backgrounding an application in a *nix system. In Windows, you cannot pause an application that was started on the command line and then tell it to resume in the background (that is, without control of stdout). On top of that, you cannot tell the very same application that you want to have it resume control of the console (stdout). Effectively, all processes in Windows are background applications. That is, when you double click their icon to start them up, they don't have a stdout. When you do start an app from the command line (assuming it is a GUI), it doesn't have a stdout by default (though, you can jump through some hoops to give it one). The concept of "foreground" is different in Windows as well. The foreground application in Windows is whatever application has the current focus. This isn't the case in *nix systems, where you can have as many foreground applications as you have consoles open for. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
I know. However, this just refers to the ability to easily put an application into the background or pull it into the foreground. However, there are application which do not have a visible Window, namely the "iconified" programs (such as ZoneAlarm, QuickTime Helper, ATI Catalyst Control Center, Antivirus SW, etc.) - and not all of those are service-GUIs. This really is more like a religious thing, so I will stop now. Basically, I'd even say that EVERY program you are not using is a background process - just because there is only a single input-focus, and thus, only one application is active - or "in the foreground". I am not claiming that Windows can do everything Linux can - or vice versa. I am just saying that "foreground", "background" and "process" are not Linux-specific concepts. Just that the implementations vary. Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
-
I know. However, this just refers to the ability to easily put an application into the background or pull it into the foreground. However, there are application which do not have a visible Window, namely the "iconified" programs (such as ZoneAlarm, QuickTime Helper, ATI Catalyst Control Center, Antivirus SW, etc.) - and not all of those are service-GUIs. This really is more like a religious thing, so I will stop now. Basically, I'd even say that EVERY program you are not using is a background process - just because there is only a single input-focus, and thus, only one application is active - or "in the foreground". I am not claiming that Windows can do everything Linux can - or vice versa. I am just saying that "foreground", "background" and "process" are not Linux-specific concepts. Just that the implementations vary. Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
I didn't mean to imply that I was debating you. I understand what you were getting at. I was simply stating that the 2 OS's define these terms (and hence the implementation of those features) differently. When going between systems, it is important to note the differences. You will run into areas where they are not synonomous quite often in low level coding, but if you just view it from a high level point of view, you can ignore those differences. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
I tried. But now also the window (in tastbar icon) is flashing ( not getting the focus ). :( Krishnakumar
What if you do the following prior to calling
SetForegroundWindow():SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, (LPVOID) 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
"The largest fire starts but with the smallest spark." - David Crow
-
I didn't mean to imply that I was debating you. I understand what you were getting at. I was simply stating that the 2 OS's define these terms (and hence the implementation of those features) differently. When going between systems, it is important to note the differences. You will run into areas where they are not synonomous quite often in low level coding, but if you just view it from a high level point of view, you can ignore those differences. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
Me neither. I just thought I had made an ambigious statement and wanted to clarify. I am not a native speaker, and I am really careful not to set people off just because my statements could be misunderstood (because, if they can, they will be ;) ). Cheers, Sebastian -- Contra vim mortem non est medicamen in hortem.
