|
Somebody know how to get the Handle window of the child window created with the Instruction CreateProcess, to relocate, resize, etc. this new window..
Thanks for your help.
|
|
|
|
|
This probably a hack, and someone else will come along and say "Don't do that, use function so-and-so". But I don't know of any function that does this directly. So what I came up with is to use EnumWindows() to enumerate all the top level windows. In the EnumWindowsProc() use GetWindowThreadProcessId() to compare the window process ID with the one you got from CreateProcess(). Just be sure to leave enough time between the CreateProcess call and the EnumWindows call for the window to be actually created.
Works like a charm.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
|
|
|
|
|
hello,
I have always asked myself, how a program as flashget knows download speed? is there any library that those that job? anyone can give me some info about? thanks a lot!
Paolo
|
|
|
|
|
Is there a way to jump of out a heavily-nested loop not by using goto statement? Since most people would agree that goto statement is evil, and it will easily destory a program's structure, so, I want to stay away from it. However, to my surprise, there is really no easy and effective way to jump out of a heavily-nested loop not by using it.
Well, I thought I should consult those experts on codeproject.com, so I could learn from them -- you.
Thanks
-----------------------------
C++ without virtual functions is not OO. Programming with classes but without dynamic binding is called "object based", but not "object oriented".
|
|
|
|
|
Alex Ngai wrote:
goto statement is evil,
It is not evil to use a goto statement when it transfers control to the end of the containing block. The C language even supplies you a couple of built-in constructs to make this easy to do - continue and break, the latter being nothing more than a continue followed by a loop terminator.
If you can't get yourself to use a goto for fear that someone will throw things at you in a code review (because they "learned in school that a goto is bad, bad, very bad"), you could instead throw an exception when you want to break out of a nested block, and take appropriate action in the catch.
Whatever you do, be sure to write a nice comment explaining what you've done. The person who ends up maintaining your code (usually yourself) will thank you for this while debugging at 3am on a winter's night. 
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
I recently saw a horrible code structure (thankfully that I didn't have to maintain) that looked like:
while ( TRUE )
{
if ( condition1 )
{
break;
}
if ( condition2 )
{
break;
}
break;
}Note the break at the bottom of the while block.
That's right: the while block isn't actually a loop at all - it's simply a device to get break to skip to the bottom of the block.
I'M NOT RECOMMENDING THIS. I think it's a horrible practice. It took me a good two hours to actually realise that it was, in fact, a goto.
When Dijkstra originally wrote his 'goto considered harmful' paper, he was pointing out the benefits of block control structures for those programmers using languages without them, or die-hard programmers not using those structures in the new languages. Uncontrolled, poorly-designed use of gotos is simply confusing - it's hard for a maintainer to know what's going on - but so is the misuse of any control structure. I don't recommend misusing exceptions in the way you suggest, either.
For more, see Gotos Considered Harmful and Other Programmers' Taboos[^].
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
|
Mike Dimmick wrote:
horrible code structure
Yikes! Three nested if-elses would have sufficed, since that it in fact the programmer's intent.
Mike Dimmick wrote:
I don't recommend misusing exceptions in the way you suggest, either.
Neither do I, as I'm sure you'd surmise if you re-read the "if" preceding the "suggestion".
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Just use a goto. You could use a meaningless throw with a catch at the point you want to jump to, but why do that? The end result is the same, and even less clear because there's not really an exception happening. If someone bitches at you for the goto, ask them for better suggestions.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
Come quietly or there will be... trouble.
|
|
|
|
|
I would advice against using exceptions for application flow, I've seen this mismanaged far too many times. 'goto's are not evil, programmers are , but in addition to different ways of breaking, you might want to revise your heavily nested loop and see if you can simplify it.
|
|
|
|
|
Alex Ngai wrote:
heavily-nested loop
You should attempt to restructure your code. Heavily nested statements (more than 3 levels deep), are not good programming practice!
So, I suggest, that while "goto" is fine to use in your case (remember, everything has its value), but I strongly suggest your restructure your loops!
cheers!
Bikram Singh
|
|
|
|
|
bikram singh wrote:
Heavily nested statements (more than 3 levels deep), are not good programming practice!
I agree. But they're also (unfortunately) very common.
Kevin
|
|
|
|
|
You're right there. But as KarstenK said, deep nesting is an indication that the code is too complex.
There are very few loops out there that cant be broken down... sure you may need to use functions to accomplish it sometimes, but the cleaner code is well worth that effort.
Bikram Singh
|
|
|
|
|
I wasn't implying that I agreed with deeply nested conditionals and loops! Quite the opposite. Just observing that they're very common. This is another way of saying that there are lots of poor programmers out there.
Kevin
|
|
|
|
|
I know !
The implication that i implicated was that the code was too complex, which implied that the implication i implicated was correct. I didnt imply that i was implicating you for your note, but just that i didnt really mean to implicate what you thought i was implicating.
Bikram Singh
|
|
|
|
|
Just use goto and if some dumbass starts asking questions, just quote Stroustrup (TC++PL 3rd ed).
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
just quote Stroustrup (TC++PL 3rd ed).
For those of us that do not have this book, would you please provide the relevant quote?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
If you don't have it, you really should... Still there are those who can't afford it (yet...).
This is from the special edition, which should be identical to the 3rd edition except most of the errata is corrected. (I used snip where I cut some text that is interesting, but doesn't apply here) I copied this by hand, so mistakes are mine.
Page 137:
The goto has few uses in general high-level programing, (snip)
The goto can also be important in the rare save in which optimal efficiency is essential, (snip)
(snip a couple paragraphs)
One of the few sensible uses of goto in ordinary code is to break out from a nested loop or switch statement.
There you have it: Most of the time goto should not be used. However there are exceptions to that rule, where goto makes the code more readable, or where there is critical speed problem that can be corrected by goto, use it.
Remember when applying the latter that the premature application of optimization is evil! Only do so when you can't get a better algorithm or CPU, and a profiler reveales that this area is a problem. Goto will only at best save a few cycles from your loop, so it rarely is enough of a solution to help speed problems. Sometimes embedded systems run into those cases where it matters.
|
|
|
|
|
Alex Ngai wrote:
and it will easily destory a program's structure,
and
Alex Ngai wrote:
a heavily-nested loop
So you want to protect the structure of your heavily nested loop code? Isn't that a bit of an oxymoron?
If you are actually concerned with program structure you might consider refactoring the code into a modern object oriented design that utilizes known patterns and techniques to solve simple structure problems like nested loops and 500 line if/elseif/switch statements.
But, that's just my opinion... I could be wrong.
Hate is not a family value
-pete
|
|
|
|
|
Thanks for all you guys's replies,
Unfortunately, at least 3-nested loop is a common practice:
while( )
{
for( ; ; ){
for( ; ; ){
}
}
}
Java does not have goto statement at all, but in order to jump out of a several-nested loop, Java has a smart extended break statement, it works like this:
first:{
second:{
third:{
System.out.println("Before break.");
if(condition)
break second;
System.out.println("This won't execute.");
}
}
System.out.println("after second block.");
}
As we see, it does the job of breaking out of a loop, and it won't have the problem of goto statment which will easily destroy a program's structure. Jave really is a great language, if only it was a system language like C/C++.
-----------------------------
C++ without virtual functions is not OO. Programming with classes but without dynamic binding is called "object based", but not "object oriented".
|
|
|
|
|
Alex Ngai wrote:
Unfortunately, at least 3-nested loop is a common practice:
Smoking crack is a common practice, but what does that have to do with Object Oriented Design? 
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Seems to me, Java's "smart extended break statement" is nothing but a goto in disguise!
A disguised goto is worse than if it was naked!
Bikram Singh
|
|
|
|
|
At first: my expirience is, if it is going to get too complex, there ist some going wrong. Try to make subfunctions.
A good way to leave loops is to leave the whole funktion with "return" + exitcode.
Another option ist to use a central boolean which in every loop is checked.
Try this @ home. (B&B)
|
|
|
|
|
Well, the return statement only return back to the function calling point, that's breaking out of a function, not breaking out of a nested-loop.
The second option seems interesting, would you explain it a little more? I'm interested.
Thanks
-----------------------------
C++ without virtual functions is not OO. Programming with classes but without dynamic binding is called "object based", but not "object oriented".
|
|
|
|
|
Ravi Bhavnani wrote:
If you can't get yourself to use a goto ... you could instead throw an exception
I disagree. If goto is evil then throwing an exception just to avoid using a goto is even worse! Which one is clearer to the person maintaining the code? Which one are you more likely to get wrong? Sometimes a goto is the right way to do something so long as it's well commented and isn't abused.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
