890927 - Invalid Input Format exception in sscanf_s
-
in the following code:
double a; sscanf\_s("0.02", "%.2f", &a);i get Invalid Input Format exception! what's the problem? i also tried %1.2f and %4.2f, but no change.
-
in the following code:
double a; sscanf\_s("0.02", "%.2f", &a);i get Invalid Input Format exception! what's the problem? i also tried %1.2f and %4.2f, but no change.
-
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.
-
in the following code:
double a; sscanf\_s("0.02", "%.2f", &a);i get Invalid Input Format exception! what's the problem? i also tried %1.2f and %4.2f, but no change.
-
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.
-
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
-
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
-
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
-
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
-
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
-
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?
-
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!
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?
-
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 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.