|
I like to retrive the motherboad Number via DOS command by using in 'C' Language.
|
|
|
|
|
I am not aware of any DOS command that can get this information, you probably need to investigat the WMI classes. Take a look at Win32_BaseBoard[^].
It's time for a new signature.
|
|
|
|
|
How to increase the size of a button according to button text.
Thanks..
|
|
|
|
|
You can use the GetTextExtentPoint32[^] to measure the text. Remember to use the same font the button is.
Steve
|
|
|
|
|
Thnx stev, but the above function is giving height and width of string, how to create button on the basis of the string size.
Thanx..
|
|
|
|
|
You can use GetWindowRect to find out where the button currently is and MoveWindow to resize it.
It might be an idea to create a new control based on BUTTON (or derive a new class if you're using MFC) which resizes itself rather than trying to pack all this lot into the containing dialogue box or window.
Cheers,
Ash
|
|
|
|
|
Every release for visual studio must be contain a version of MSDN. As follow described:
A: The October 2001 MSDN Library integrate with Visual Studio 6.0.
B：The January 2003 MSDN Library integrate with Visual Studio .NET (2002).
C：The January 2006 MSDN Library integrate with Visual Studio .NET 2003.
D: The April 2007 MSDN Library integrate with Visual Studio 2005 (Service Pack 1).
E: The January 2008 version integrate with Visual Studio 2008.
F: The November 2008 version integrate with Visual Studio 2008 SP1.
I only have one question, should i use the newest MSDN for query the usage for function, enum, etc. Or should i use the associated version with VS(if use VS6.0 for development, then use MSDN 2001 oct, if use VS2005, then use MSDN 2007 april)?
One day a pretty girl asked me:"Do u think you are handsome?" "I don't think so!".She gave a slap in my face:"Why lying?"...
|
|
|
|
|
Use the one matching the version of the SDK you have installed.
|
|
|
|
|
This c++ application has two static functions that are used everywhere (about 130+ calls for each function):
incCount()
and
decCount()
At the start of the program the Count = 0, the problem is that once the processing is complete the Count must == 0. The Count can go as high as it needs to, but by the time the application ends each incCount() call must be balanced with a decCount() call.
Currently, the Count == 1 by the time the program ends and I must find out where a decCount() isn't called.
What is the best way to find out which code module isn't balancing the Count properly ?
(this is a C++ 6 application)
|
|
|
|
|
You cannot do this with one variable.
This is usually done by creating many instances of a class.
The class will internally have functions to increment and decrement.
When the class is created you can generate some sort of cookie that is unique across instances.
This was we can log which instance in incrementing and decrementing.
|
|
|
|
|
my current idea is to define the following with #ifdef _DEBUG playing a huge role:
in the class:
#ifdef _DEBUG
static Uint32 incCount (char cModule);
static void decCount (char cModule);
#else
static Uint32 incCount ();
static void decCount ();
#endif
the class where these functions are defined also implements a linked list. For each incCount(char) the char is added to the linked list (if it doesn't yet exist in the list), and for each decCount(char) the char is removed from the linked list.
then for each time the functions are called in the code:
#ifdef _DEBUG
decCount(__FILE__);
#else
decCount();
#endif
At the end of the program I dump what's in the linked list and the __FILE__ that is dumped is where I need to focus on by setting breakpoints.
However, this will touch at least 40 files. Is this the best method or is there a better method ?
For example, it would be incredible if I had programmatic access to the call stack (in a debug build) so that I would only need to edit this one class and add the source file to the linked list that's next in the stack.
|
|
|
|
|
First of all, if you are using multiple threads (explicit ones, or implicit ones such as used by asynchronous events, callback routines, etc), and your counter increment/decrement isn't atomic, it may well be that the number of calls is correct and the value is incorrect.
Assuming you have verified that, you will need to differentiate your function calls; an easy way would be to give them one positive integer parameter, using the same value for matching pairs of incCount(id) and decCount(id).
Then you want to count the operations for different id values in separate accumulators. There are many ways to do so:
- use an array, ranging from 0 to maximum(id);
- if that is not doable, use a smaller array with P elements, and use id%P
(the modulo operator will map any value of id to a valid index for your array).
Special case: if only one decCount() call is missing, you might even try this:
int count=0;
int P=32;
void incCount(int id) {
count^=1<<(id%P);
}
void decCount(int id) {
count^=1<<(id%P);
}
which means each call is toggling one bit in a single counter (assuming P is 32 or less); in the end the bit number of the one non-zero bit gives you the id%P. And you could use additional runs with different P values to find the actual value of id!
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I see, your method uses each bit in P to track a different code module.
That's less work than implementing a linked list and I don't have to edit a load of compiler conditionals.
EDIT:
I counted 43 code modules that need to be ID'd
modified on Wednesday, May 19, 2010 5:29 PM
|
|
|
|
|
if you have a limited number of id values, you can count their calls individually.
if they are many, you fold them to a smaller value.
And you already expect only one mishap, you could take advantage of that.
But first of all, you should inspect the potential multi-threading issue; your observation could simply be wrong!
I would avoid introducing fancy things (such as your linked list idea), as things in there can also go wrong; especially with a list, you would find it either difficult or expensive to get it thread-safe. Whatever code you add, it would better be thread-safe!
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I went with your idea of passing in an ID.
The integer ID is used by the counting functions to track which module the call came from (keeps track with an array).
with this method I can track what modules inc's and dec's don't match up.
|
|
|
|
|
Hi,
If you're using static functions then the functions can only be called from one translation unit - the one that they're defined in. Funnily enough that's the one the balancing won't be happening in. From what you've said there's something a bit more going on - perhaps if you described what you were trying to count someone could give you a suggestion as to how to count it more accurately?
Cheers,
Ash
PS: For example if you're counting objects of a particular class you can use RAII to keep track of your count. If the count's unbalanced because you're not clearing up objects properly then a decent debug heap might be able to give you clue as to what sort of object is still alive when the program terminates. You might have to do something a bit gauche like look at the still allocated block and compare vtable pointers but it's possible.
|
|
|
|
|
Are there the same number of calls to each function in your source code.
Assuming each inc cas a corresponding dec, look for the code section without the missing dec.
If that cannot be done. I would suggest checking all the dec calss to make sure one cannot be bypassed by an early "return" within the function code.
Next I would place breakpoints at given points so you can check the count value at the inc and dec calls. This should allow you to narrow done the rea of code which is not inc/dec correctly.
Are you sure its not a threading issue? Is it multithreaded and how are the numbrs being increemnted/decremented? this is where InterlockedIncrement and InterlockedDecrement can be of help.
If you vote me down, my score will only get lower
|
|
|
|
|
Roger, thanks for your reply.
my initial problem statement is a little bit simplified... in actuality the two calls vary wildly in the project. For example, 110 inc's and 140 dec's.
However, with the aid of some flags and using an array to track which modules are making the calls I have been able to balance the code such that dec count == inc count by the time the executable is finished.
I am actually really pleased with the implementation. So much so that I will keep the code in place and let it trigger only when an environment variable is set so that I can debug this problem if it shows up again
|
|
|
|
|
I want to stop the program run after the message box display
int npoints=(tmax+1000)/sam_interval;
if (npoints>32768) {MessageBox("The sampling time interval is too small. Please select a larger sampling interval.");
}
With the above statement, after I close the message box, the program resumes the run. In fact, I want to stop the program after closing the message box.
Please give me help
Thanks
modified on Wednesday, May 19, 2010 1:16 PM
|
|
|
|
|
How about sending it a WM_CLOSE message?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thanks.
I use
exit(-1); after the message box. it works.
if (npoints>32768) {MessageBox("The sampling time interval is too small. Please select a larger sampling interval.");
exit(-1);
}
|
|
|
|
|
mrby123 wrote: I use
exit(-1)...
To exit a Windows GUI application? 
Not a good choice.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
mrby123 wrote: Please select a larger sampling interval.
That message does not make sense if your app is exiting anyway.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
When you program suddenly stop, you may want to inform the use what happen.
Otherwise, the use feels not good.
|
|
|
|
|
I agree, but then you should choose a more accurate message; maybe "next time you run this program, please enter ...".
Although I still think it is rather rude to stop a program just because the interactive user entered something you did not like; you should allow for another chance.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
