|
Make it for 0 to 2500 and then add 5000 :P
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
|
Definitivelly, there is people that are blind and don't see the symbol of "joke" in the posts. I put a 5 to compensate the bad points.
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
Nelek wrote: Definitivelly, there is people that are blind and don't see the symbol of "joke" in the posts. I put a 5 to compensate the bad points.
Oh I don't care about bad votes of such people. Anyway, thank you very much I really appreciate you kindness.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
(rand() % (UPPER_BOUND - LOWER_BOUND)) + LOWER_BOUND
|
|
|
|
|
On statistical grounds (don't ask me why  ) the best better approach is instead the one provided by the MSDN sample http://msdn2.microsoft.com/en-us/library/398ax69y(VS.80).aspx[^], i.e.
int u = (double)rand() / (RAND_MAX + 1) * (range_max - range_min)
+ range_min;
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi All,
I have functions A & B.
A will be the starter. A will call B.
Again B will call A.
This call will go recursively until a condition is satisfied.
But after around 200 executions, if the condition is not getting satisfied, Stack overflow happens.
fn A{
......
call fn B
}
fb B{
......
call fn A
}
Is there any way to call function B after the complete execution of A is getting finished. So that the scope of A will be completed before calling Function B.
What if call PostMessage in this case?
Any help would be appreciated...
Thanks in advance.........
|
|
|
|
|
krishnan.s wrote: This call will go recursively until a condition is satisfied.
But after around 200 executions, if the condition is not getting satisfied, Stack overflow happens.
IMHO it is a bit too early, but anyway....
krishnan.s wrote: Is there any way to call function B after the complete execution of A is getting finished. So that the scope of A will be completed before calling Function B.
What if call PostMessage in this case?
I think the question is: is the algo recursive?
If the answer is yes, then you can either try to increase stack size or transform the algo to do iteration instead of recursion.
If the answer is no, then you have to modify your buggy code.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
You may be able to prevent this problem by passing less data with each call, passing references instead, keeping your data in a heap allocated structure etc. These changes may be simpler than changing the algorithm. If you post a few more details, function signatures, some idea of the data structures involved as solution may present itself.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hi Everyone,
I need some help regarding implementation of iLBC codec for compressing audio files.
Thanks in advance..
regards,
programmer81
|
|
|
|
|
This is a dialog based application. I want the application execute some code after the main window and all child windows displayed correctly. Where should I write the code ?
I think OnInitDialog is not a good place, because the window have not displayed yet.
Thank you all!
|
|
|
|
|
You can call PostMessage() inside OnInitDialog to post a user message, then in the message handler do needed stuff.
You can also use a one-shot timer for it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Go for the PostMessage approach. Post it at the end of OnInitDialog.
Forget the timer approach. PostMessage is the correct way to do this.
|
|
|
|
|
pierre_ribery wrote: Forget the timer approach. PostMessage is the correct way to do this.
Why?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Because you are not guaranteed that the WM_TIMER message will be handled. THe dialog might be closed before the timer elapses (lets say 200-300ms). If you post a user defined message in OnInitDialog you are guaranteed that it will be handled before any messages sent after this! the timer might be invoked too late.
From MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
also, you have to remember to kill the timer as the first thing in the WM_TIMER handler.
Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources.
Might be more reasons, but it boils down to what is the best approach. The timer approach is a possibility, but not the BEST.
|
|
|
|
|
pierre_ribery wrote: THe dialog might be closed before the timer elapses (lets say 200-300ms).
Provided you know such a feature it may be not a problem.
pierre_ribery wrote: also, you have to remember to kill the timer as the first thing in the WM_TIMER handler.
Of course. one-shot has to be one-shot, after all!
pierre_ribery wrote: The timer approach is a possibility, but not the BEST
pierre_ribery wrote: rom MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
To both points applies: Provided you've to immediatly execute code.
pierre_ribery wrote: Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources.
Oh, there are two possibilities here:
(1) You already have such a timer (for different purposes) and you're just using its first call (in such a case, no performance loss).
(2) You haven't such a timer and hence make a one-shot timer that is a low resource waster.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
modified on Monday, December 17, 2007 5:11:51 AM
|
|
|
|
|
Please re-read my post, I have made some updates.
|
|
|
|
|
Thank you, I've just update mine
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Why wait executing the code? The sooner the better I would think.
That being said, you are wasting resources even if it is a one-shot timer.
I think that any professional windows programmer would agree with me that the timer approach is not the best, but again you are free to do it the timer way if you think that is best.
|
|
|
|
|
pierre_ribery wrote: That being said, you are wasting resources even if it is a one-shot timer.
pierre_ribery wrote: I think that any professional windows programmer would agree with me that the timer approach is not the best
It is just an alternative to me. Anyway, thank you for including me among the hobbysts 
pierre_ribery wrote: you are free to do it the timer way if you think that is best.
Oh freedom, what a wonderful thing!
Have a nice day ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
I agree that it is an alternative.
But can you please answer this question:
Which approach do you think is the best?
|
|
|
|
|
pierre_ribery wrote: I agree that it is an alternative.
But can you please answer this question:
Which approach do you think is the best?
Yours (you're a professional, after all), of course.
just kidding.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Thank you CPallini
Does that message will be the first message that the application received after it showed on the desktop?
|
|
|
|
|
You are not totally right. The constructor is not a good place because the window is not created yet and you will get assertions. The OnInitDialog is called in the very moment when the window and all its controls where created and are going to be shown. If you modify contents, properties and so on of the controls and/or the dialog itself. It should give you no problems.
The window have not been displayed yet, but is the moment where it is being displayed, so all elements and relationships are already there.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
Thank you all!
I found call PostMessage in the dialog's OnInitDialog member before it returned is a good solution, it woks well
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
