|
The return value from OnNext() determines which page is displayed next:Return 0 to allow the wizard to go to the next page. Return -1 to prevent the wizard from changing pages. To display a particular page, return its dialog resource identifier.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Thanks, but when you say
Michael Dunn wrote: To display a particular page, return its dialog resource identifier.
im not sure what you mean, can you give me an example??
|
|
|
|
|
|
Hi,
How to get Current Color Scheme of the System.I am working on Widnows Xp.How to get the current Color Scheme that is selected .
Thanks in before
James
|
|
|
|
|
RockyJames wrote: How to get Current Color Scheme of the System.I am working on Widnows Xp.How to get the current Color Scheme that is selected .
Take a look at GetSysColor.
Nibu thomas
Software Developer
Programming Tips[^]
|
|
|
|
|
RockyJames wrote: How to get Current Color Scheme of the System.I am working on Widnows Xp.How to get the current Color Scheme that is selected .
You can get the different colors of the system from the following path of the registry
HKEY_CURRENT_USER\Control Panel\Colors
and for the the current color schemes
HKEY_CURRENT_USER\Control Panel\Current
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
when we right click on the desktop.. properties -> In Appearances tab i want the current selected color scheme in ColorScheme Combo Box..and its respective RGB value..IS there any method to do it?
Thank`s in berfore
James
|
|
|
|
|
Hello,
SCENARIO:
- I have some "C" code that runs heavy math, that takes time to get the results.
- Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
- Compiling under a Release configuration, fails to get the required results.
(Release configuration with its default Speed code optimization (/O2 flag)) - When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.
QUESTIONS
- How can I detect what does causes this differences on the code?
- How can I debug this code and catch the affecting lines?
I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static.
Any hint? 
Thanks in Advance.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
rbid wrote: All this code runs under the same thread
Create the seperate synchronised threads for the large calculations
and which is not much dependent on each other
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
A_Laxman wrote: rbid wrote:
All this code runs under the same thread
Create the seperate synchronised threads for the large calculations
and which is not much dependent on each other
This is exactly how it is implemented. The code that has the problem runs on a separate synchronized thread.
Even if I encapsulate the code on a single "console application", the problem persists.
Thanks for your thoughts, this place is a great place for getting good ideas and solutions.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
If a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations.
If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem.
If you are using some older versions then try debugging the usual way. Look carefully at pointers, if you are using them. Try putting testing fprintf's/ or AfxMessageBox's (if you are using MFC) in release mode at various places and see how far code is able to execute. Another way might be to take crash address and find which souce line it corresponds to using a map file[^]. When using a map file you might get crash at a line which is not in your code or at a place where you are sure there's nothing wrong. In that case you will have to figure out which functions are calling the function which crashed.
Hope this helps.
-Saurabh
|
|
|
|
|
Saurabh.Garg wrote: ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Saurabh.Garg
Date:4:32 20 May '06
If a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations.
If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem.
Hope this helps.
-Saurabh
You are right, but the code does not crash, just gives a different result that is not acceptable. Puting a breakpoint or dumping via TRACE or printf is like searching for needle in a montain of hay (or how you say it).. I'm running VS 2003.
A great article about Surviving the Release version[^] can be found in this site as well..
I'm also thinking about what is mentioned here[^].
Have a nice day.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
Oh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using
#pragma optimize( "", off )
.
.
.
#pragma optimize( "", on )
any functions with these two statements won't be optimized. Try disbaling optimization for most critical functions and see if results are as expected. Keep trying until you get correct result. If your code is huge then it might be a tedious process but its better then checking intermediate results as computing them by hand might be difficult.
-Saurabh
|
|
|
|
|
Saurabh.Garg wrote: ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Saurabh.Garg
Date:22:21 20 May '06
Oh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using
#pragma optimize( "", off )
.
.
.
#pragma optimize( "", on )
Eureka , thanks for the idea. (It is so simple when you know it  ).
Thanks.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
So were you able to solve the problem. It would be nice if you can share what type of code can cause optimization problems.
-Saurabh
|
|
|
|
|
Saurabh.Garg wrote: ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Saurabh.Garg
Date:22:36 21 May '06
So were you able to solve the problem. It would be nice if you can share what type of code can cause optimization problems.
-Saurabh
I'm still fighting with it. But at least, I know which files are the cause. It seems that the developer was not aware that optimizations could cause some aliasing..about aliasing. (Using pointers to variables that the compiler may supress during optimization)
Look in:
I will sumarize when I finish my investigation.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
I hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile.
Good luck ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote: ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Ryan Binns
Date:7:53 20 May '06
I hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile.
Yes, you have interpreted my question correctly. I guess that I will continue to dumping (via TRACE) debug information to catch the problem, it is like looking for a needle in a montain of hay. and even worse, the problem is detected only after running for almost 1hour. (That is the reason why speed optimizations are required)
Thanks for your help.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
One other thing you could try is to enable optimisation for your debug build and see if it has the same problem. If it does, you can step through it with the debugger. You won't be able to go one line at a time, but you should be able to narrow it down enough to find the problem area.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote: ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Ryan Binns
Date:20:38 20 May '06
One other thing you could try is to enable optimisation for your debug build and see if it has the same problem. If it does, you can step through it with the debugger. You won't be able to go one line at a time, but you should be able to narrow it down enough to find the problem area.
Ryan
I'm using your sugestion together with the sugestion in:
http://www.codeproject.com/script/comments/forums.asp?forumid=1647&select=1497199&fr=364&df=100#xx1497199xx[^]
So far, I managed to isolate a bunch of files that cause the problem, it seems that the developer that wrote that code was not aware about aliased code. (I asked him to take a look and maybe re-design some code that causes the problem.)
I will sumarize the results.
Thanks.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
Sounds a lot like scientific programming.
I do not know your code, but this sort of problem often arises from:
1.)Array overrun (Solution: interface array access through an intermediary function that executes a bunch of assert(); to verify that access is always within bounds. The asserts all dissappear in the release mode so that they do not slow production down at all.)
2.)Optimizer bug. (Here the machine-code generated by the compiler is just flat wrong. Every mature scientific programmer must be prepared to deal with this horrible sort of problem. I have NEVER (since 1965) dealt with a compiler that I did not find bugs in its code generation. Here, my best approach is to start backward from the crash line. Either some datum going into the crash is wrong or the line is encoded wrong.)
Item 1.) is about 100 times more common than item 2.) but they lead to comparable amount of grief in toto.
Gematria
|
|
|
|
|
Ray Hagstrom wrote: ForumVisual C++ / MFC
Subject:Re: Release Code Optimization Problems..
Sender:Ray Hagstrom
Date:14:46 20 May '06
Sounds a lot like scientific programming.
I'm doing some system verification code, the system guys use Matlab for generating their models, and I run some "C" code to verify their models.
Ray Hagstrom wrote: 1.)Array overrun (Solution: interface array access through an intermediary function that executes a bunch of assert(); to verify that access is always within bounds. The asserts all dissappear in the release mode so that they do not slow production down at all.)
Yes, But this could also happen in the Debug or Release without speed optimization, and it does not happen, the problem arises only when I compile the code with speed optimization (/O2 flag) (PC-Lint[^] did not find any access out of bounds in the code)
Ray Hagstrom wrote: 2.)Optimizer bug. (Here the machine-code generated by the compiler is just flat wrong. Every mature scientific programmer must be prepared to deal with this horrible sort of problem. I have NEVER (since 1965) dealt with a compiler that I did not find bugs in its code generation. Here, my best approach is to start backward from the crash line. Either some datum going into the crash is wrong or the line is encoded wrong.)
The program does not crash, but produces wrong results when compiled with the optimize for speed flag. I'm currently adding some TRACE lines to print out the computed results and then compare them with the Debug (or Release without code optimization).. but that is like looking for a needle in a montain of hay 
Any additional hint?
Thanks to all in advance.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
Hello to all,
First of all, thanks for your help in trying to solve this problem.
The problem is solved, and was caused by variable aliasing that confused
the compiler optimizations.
The code that caused the problem has been re-designed and fixed. (I found also other spaguetti programming problems there).
How was this problem isolated
#pragma optimize( "", off )
...
#pragma optimize ("", on )
At the end, I found that only a small number of functions were the ones that caused the problem, and the reason was variable aliasing.
The code was belonging to a novice developer, that with my help he has re-designed his code and now we all are happy
Note: Variable aliasing is described in the VC documentation, look under Compiler Optimizations, specially for the flags /Ow or /Oa.
Thanks to all who helped me to identify the problem.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
Is there any possibilities to convert my string to PUCHAR with out doing looping.
PUCHAR buffer = new UCHAR[length];
As well vice-versa case; meaning convert PUCHAR to String with out doing looping.
Please explain me.
|
|
|
|
|
sivaprakashshanmugam wrote: Is there any possibilities to convert my string to PUCHAR with out doing looping.
PUCHAR buffer = new UCHAR[length];
As well vice-versa case; meaning convert PUCHAR to String with out doing looping.
From PUCHAR to CString...
CString csPUCHAR = buffer;
From CString to PUCHAR...
PUCHAR puCS = (PUCHAR)csPUCHAR.GetBuffer(0);
csPUCHAR.ReleaseBuffer();
Nibu thomas
Software Developer
Programming Tips[^]
-- modified at 2:40 Saturday 20th May, 2006
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
