|
double a;
sscanf_s("0.02", "%lf", &a);
|
|
|
|
|
yes, it works. but since the format is the same as what is used for showing the property (CMFCPropertyGridProperty::m_strFormatDouble), i've to specify the number of digits i want to be shown after the decimal point, so i can't use %lf.
|
|
|
|
|
Your format string is wrong, see here[^] for the width specification in sscanf.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
thank u, i read it, but i couldn't figure out what to choose as format for a floating point variable with read part of variable digits number and floating point of always two digits.
|
|
|
|
|
As it says in the link I showed: The width field is a positive decimal integer controlling the maximum number of characters to be read for that field. No more than width characters are converted and stored at the corresponding argument. Fewer than width characters may be read if a whitespace character (space, tab, or newline) or a character that cannot be converted according to the given format occurs before width is reached.
So in your case you would code it as
double a;
sscanf_s("0.02", "%4f", &a);
since you have 4 characters in your string value. The number of digits after the decimal point is largely irrelevant for floats and doubles when reading in, it is only important when formatting for output. In general you are better off not specifying a width value as it can lead to loss of precision in input strings - unless your users all know exactly what format to use for their input data.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
thank u for the description. the problem is that format strings for sprintf_s and sscanf_s differ. for sscanf_s including a . in format causes Invalid Input Format exception in anyway. as u mentioned, the input string is read by the number of bytes specified in the format b4 f and the chunk string is processed to be converted into a float. while in sprintf_s . has meaning. %4.2f for example means that the output string must contain at least 4 characters and exactly 2 digits after decimal point. if it be needed this may increase, eg. %2.2f or even %1.2f lead to the same output 0.02 or even 123456789.00.
this is while we has only one format for a grid ctrl, not two separate formats, one for sprintf_s and one for sscanf_s. as i said b4 it's stored in CMFCPropertyGridProperty::m_strFormatFloat or CMFCPropertyGridProperty::m_strFormatDouble. this uniqueness in the source of the problem.
now what's ur suggestion?
i've also another problem. spin ctrls are designated for integral fields. i need to attach a spin ctrl to a field of type float. for example when i've 12.34 in the field it may get 11.34 or 13.34 with up and down arrows. if i specify it to limit to 20, after 19.34 it gets 20.00 with arrow up. when i specify low limit of zero it gets 0.00 after 0.34 with arrow down. the spin ctrl doesn't expect the input field to be a float while it doesn't contrast with its behavior.
so the summary of the two problems are:
1. how can i overcome the uniqueness of floating point fields format in a grid ctrl which is both used for showing and inputting?
2. how can i have a spin ctrl for a floating point input field?
thx
|
|
|
|
|
1. I'm not sure I understand the problem, if you require different format strings for input and output then you need to code round the problem.
2. Don't use a floting point number, use an integer and multiply by 100 and display in the form you want. You may need to use a separate text box for the display rather than one that is directly connected to the spin control. Thus to display 1.05, you would use a value of 105 and use division and mod to separate the two halves, then display using a format of "%d.%.2d".
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
all of the problem is that i like to least code, otherwise i would code another CSpinCtrl class as well as another CMFCPropertyGridProperty!
2. i've also to set steps of up and down arrows to 100 instead of increment and decrement. i prefer to use a different class than the original CSpinCtrl instead.
1. i tried to explain accurately! the problem is that the format strings for sprintf_s and sscanf_s do not process similarly. dot in the format string for sscanf_s has no sense while in the format string of sprintf_s has meaning. since the format string for type double or float is only one for both presenting the value or evaluating it, i've to replace the class with another one which i alter by code rounding it and this is what exactly i wanted to avoid.
2. it's the same for a spin ctrl. instead of calling EnableSpinControl for the property, i've to define another function to create another spin ctrl class with the desired functionality and this is also what i wanted to avoid.
i wonder how such great class are coded with such fool limitations!
thanx anyway
|
|
|
|
|
ilostmyid2 wrote: i wonder how such great class are coded with such fool limitations!
Sorry, no idea, perhaps you should direct your comments to Microsoft, as they are the ones responsible for it.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
yeah, good idea, although i get my answers mostly from codeproject rather than MS!
and u mean there's really no option other than replacing codes?
|
|
|
|
|
ilostmyid2 wrote: i wonder how such great class are coded with such fool limitations!
The origins are from C or even earlier.
And myself I don't see the problem.
First since the methods do not in fact do the same thing it isn't surprising that they use different idioms.
Second the point of scanf is to read/parse data. And the solution you were given seems to me to do exactly that. Could you explain what exactly it isn't doing that you want it to do in terms of reading/parsing data?
|
|
|
|
|
1. i found the way. indeed, the default implementations of converting text into value which is done in the virtual function TextToVar of a CMFCPropertyGridProperty and converting value into text which is done in the virtual function FormatProperty use m_strFormatFloat for float types and m_strFormatDouble for double types and we may override this behavior. so it's enough to leave m_strFormatFloat as is and override method FormatProperty in a derived class.
|
|
|
|
|
Hey, basically what I am trying is to modify the data of a harddrive.
I want it to show more free space than it has, i know it would be only visually but that's exactly what I am trying to do.
OS would be windows server 2008, if that matters.
How would I go about doing this?
I tried to google but couldn't really find anything neccessary.
Thanks
|
|
|
|
|
The only way that comes to mind is to add a filter to the driver and fake up the size when the driver responds to an IOCTL for the freespace. You need to read up on Windows Driver Development Kit.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
ALLERSLIT wrote: I want it to show more free space than it has...
In just your application, or do you want Windows to "lie" too?
"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
|
|
|
|
|
I am in the process of learning how to use arrays. To be more specifc, how to modify the code of "for loops" to learn different ways to work with arrays. Listed below is a basic program where I am attempting to learn how to modify a two dimensional array. I would like to place a 1 in the first dimension and a 2 in the second dimension.
The issue I do not understand is why my for loop is advancing to array element 2. Shouldn't the elements updated through the loop be [0] and [1]? Shouldn't my for loop stop when it encounters the for statement test condition <=1?
What is happening is that the statement advances to element [2]. Do I have a correct understanding of the for loop? Advice is much appreciated.
#include <iostream>
using std::endl;
using std::cout;
using std::cin;
int initialize[2][2];
int row;
int col;
int main()
{
for(row=0;row<=1;row++)
{
for(col=0;col<=1;col++)
{
initialize[row][col] = 1;
cout << "Row ""Col "<< row << col << initialize[row][col] << '\n';
}
}
}
|
|
|
|
|
A loop such as for(row=0;row<=1;row++) should be read like this: 'Set row to 0, and then keep adding 1 to row until row is no longer less or equal to 1.' So what happens is this:
First iteration (row is now 0):
Is row <= 1? Yes; execute the code in the loop's body and when that's done, add 1 to row.
Second iteration (row is now 1):
Is row <= 1? Yes; execute the code in the loop's body and when that's done, add 1 to row.
Third iteration (row is now 2):
Is row <= 1? No; execute the code after the loop.
So although row is equal to 2 áfter the loop, row is always less or equal to 1 within the loop.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
I am a bit unclear on the issue of Arrays vs vectors. Recently, I have started learning STL. I am more familiar with MFC. What is the big difference between vectors and the CArray, Cstring and std::string.
Vectors vs CArrays: CArray has all the tools that I need just like vectors and to me it looks more straight forward than vectors, but thats only me. I do realize there is a problem with copy constructors in CArrays. I know CArray is derived from objects and I am guessing vecto is not. So, does this make vectors a lot more efficient interms of memory usage?
CString vs std::string: same goes for strings, even though I find that I can do more with CString.
Besides portability, I don't see a major advantage of vectors.
Can someone clarify the real differences for me?
Thanks
modified on Friday, December 17, 2010 1:04 PM
|
|
|
|
|
All things that you noted are correct.
One of the design consideration of STL was to separate algorithms from containers.
So there are just one copy of algorithms that work with a whole range of containers.
They use iterators for this to happen.
So this makes it very easy to change containers if necessary.
|
|
|
|
|
It's a question of modernity; MFC collections are obsolete.
STL is the standard template library.
STL is faster (test in release, not debug mode) and offer more flexibility (algorithms, iterators, ...)
here's a link to a discussion :
http://www.codeguru.com/forum/archive/index.php/t-391319.html[^]
"...And frankly the team will give you the same answer. The MFC collection classes are only there for backwards compatibility. C++ has a standard for collection classes and that is the Standards C++ Library. There is no technical drawback for using any of the standard library in an MFC application.
We do not plan on making significant changes in this area.
Ronald Laeremans
Acting Product Unit Manager
Vsual C++ Team..."
Watched code never compiles.
|
|
|
|
|
As once said distinguished Mr. Grauss: "MFC containers are a crap". I do believe he was right.
STL container design is more rigorous and clean.
Now you feel more comfortable with CArrays, etc.., but, once get used with STL, you won't go back.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi,
I am using DT_CALCRECT in DrawText() function. If I use
dc.DrawText(m_szText,rect,DT_LEFT|DT_WORDBREAK); It works fine.
But If I use dc.DrawText(m_szText,rect,DT_LEFT|DT_WORDBREAK|DT_CALCRECT);
I am having issue, text is not getting displyed.
What is the problem?
|
|
|
|
|
Read the documentation.
Using DT_CALCRECT will only compute the RECT needed for the text pass to DrawText, not draw the text.
usual workflow is to call CDC::DrawText with DT_CALRECT to get the valid RECT and then do something with it, normally call CDC::DrawText with the good RECT.
Watched code never compiles.
|
|
|
|
|
|
Please rephrase your questions.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
