|
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 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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Hi friends,
Can I do like this
class CodeProject
{
public:
CodeProject()
{
delete this;
}
~CodeProject()
{
}
};
int main()
{
CodeProject *object= new CodeProject();
return 0;
}
Please Assume that I am always going to allocate memory on heap using new.
|
|
|
|
|
hey vik, seriously, why do you want to use a constructor to destruct the object ?
don't you think this kind of action is inapropriate for a constructor ? 
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
 Dude, you you need to do that for? Just a quick sily question ...
|
|
|
|
|
Really I don't know why I asked this question 
But consider a situation where I am taking some argument in constructor and depending upon this I want "control" over object creation.
I know there are other way to do it.
But can we use such nasty code?
|
|
|
|
|
yes, it will work.
the only strange bit is that your variable "object" will receive the value that it would have received even if you didn't delete the object, however (ie. not NULL). it will look like a valid pointer, but the memory it pointed to will have been freed by the delete.
more[^]
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Chris Losinger wrote: yes, it will work.
It will not 'work'. The object is not fully constructed so its destructor cannot be called. At best, the code represents undefined behavior.
|
|
|
|
|
Roland Pibinger wrote: It will not 'work'.
of course it will. step through the code in a debugger and see what happens.
memory is allocated in 'new', then the ctor is called. 'delete' is called, which releases the memory allocated by new. since there are no instructions after the delete, the ctor exits and that's it - no uninitialized members are touched, nothing is unconstructed.
there is certainly potential for dangerous behavior here, ad there's definitely a better way to do whatever the OP is trying to do. but as written, this is safe.
Roland Pibinger wrote: The object is not fully constructed so its destructor cannot be called
that statement is not true in all situations
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Chris Losinger wrote: memory is allocated in 'new', then the ctor is called. 'delete' is called, which releases the memory allocated by new
I haven't tried the code, but it will change the behaviour of the new operator which may return a pointer to the deleted object instead of NULL.
I assume the code will "work" in the aspect of performing a delete on the constructed object, but the returned pointer from new cannot be trusted; the object may have been deleted and if used will cause an access violation.
I suggest overriding the new operator instead.
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Roger Stoltz wrote: but it will change the behaviour of the new operator which may return a pointer to the deleted object instead of NULL.
yes, as i noted in my first reply.
it's not good programming practice in general, and i can't think of a single situation where this is the best solution. but, as written, (as an academic question), it appears safe.
i've spent a bit of time this AM looking over the web for someone who can definitively show that it (as written in the OP) isn't safe - haven't found one yet. a lot of people have asked this question, and the discussions all agree that it's safe as long as you pay attention to things like virtual dtors, derived classes, no stack allocation of the object, don't trust the return from new, etc..
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Chris Losinger wrote: as i noted in my first reply
Sorry Chris, didn't pay enough attention.
Chris Losinger wrote: looking over the web for someone who can definitively show that it (as written in the OP) isn't safe - haven't found one yet
I think you can stop looking.
IMO it's quite clear what happens, the same way you described it previously.
Whether it's "safe" or not depends on how we define "safe"; It will run and the behaviour is predictable and in that aspect it's considered safe. But it has to be used with certain restrictions, otherwise it's not safe.
Better safe than sorry...;)
--
Roger
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Roger Stoltz wrote: Sorry Chris, didn't pay enough attention
and i probably wasn't as clear about what i was saying as i should have been. ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Roger Stoltz wrote: But it has to be used with certain restrictions, otherwise it's not safe.
if i was in charge of writing coding standards for my company (oh wait, i am!), those restrictions would be simple: never do this.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Chris Losinger wrote: never do this
Ahh, the good old KISS! 
Well, I'm off now; have a nice weekend.
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Chris Losinger wrote: of course it will. step through the code in a debugger and see what happens.
Hmmm, works with g++ under Linux as well.
However, I am not sure what would other compilers do.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
