DDX_Text(,,short&) overflow?
Thomas GESSL -- 100072.1067@CompuServe.COM
Thursday, July 18, 1996
Environment: VC4.1, Win95
In our dialog the user is allowed to type into a specific field only values in
the short range. But when he types in a long number (longer than a short), the
DDX_Text routine returns whithout any error message and results a wrong number.
I tried it with a minimal AppWizard application, with one dialog and one edit
field. With ClassWizard I added a member to this field of type short and
validation in the range [0..9999].
The DoDataExchange shows as expected:
DDX_Text (pDX, IDC_TESTFLD, m_nTest);
DDV_MinMaxInt (pDX, m_nTest, 0, 9999);
m_nTest is declared as:
short m_nTest;
When the user types in e.g. "400077", the resulting m_nTest is "6861" without
any error.
Any ideas what's wrong? Is this a bug?
The MFC sources shows DDX_Text(,,short&) calls DDX_TextWithFormat(,,_T("%d")..).
I think %d formats int, which should be 32 bits. I think the correct form should
be to call with parameter "%sd" to force short readings.
Thank you in advance.
Sincerly,
Thomas Gessl
KOPFWERK EDV SW
AUSTRIA/EUROPE
David.Lowndes@bj.co.uk
Monday, July 22, 1996
>In our dialog the user is allowed to type into a specific field only values in
>the short range. But when he types in a long number (longer than a short), the
>DDX_Text routine returns whithout any error message and results a wrong number.
>
>The DoDataExchange shows as expected:
>DDX_Text (pDX, IDC_TESTFLD, m_nTest);
>DDV_MinMaxInt (pDX, m_nTest, 0, 9999);
>
>m_nTest is declared as:
>short m_nTest;
>
>When the user types in e.g. "400077", the resulting m_nTest is "6861" without
>any error.
A bit of hex conversion will show that 6861 is just the decimal
representation of the lower 16 bits of 400077.
>The MFC sources shows DDX_Text(,,short&) calls DDX_TextWithFormat(,,_T("%d")..).
>I think %d formats int, which should be 32 bits. I think the correct form should
>be to call with parameter "%sd" to force short readings.
I'd agree with that, though %sd should be %hd I think.
In fact after a brief scan of the source code I see these subtle comments in
DDX_TextWithFormat "the following works for %d, %u, %ld, %lu" and above
AfxSimpleScanf it says "only supports '%d', '%u', '%ld' and '%lu'". Perhaps that says
it all!
It might be better to declare your DDX member variable as int and have an external
copy of the variable as short.
Dave Lowndes
Dan Kirby -- dkirby@accessone.com
Thursday, July 25, 1996
I believe this was fixed in VC++ 4.2. Have you tried the code under VC++ 4.2?
--dan
----------
From: Thomas GESSL[SMTP:100072.1067@CompuServe.COM]
Sent: Thursday, July 18, 1996 6:21 AM
To: mfc-l@netcom.com
Subject: DDX_Text(,,short&) overflow?
Environment: VC4.1, Win95
In our dialog the user is allowed to type into a specific field only values in
the short range. But when he types in a long number (longer than a short), the
DDX_Text routine returns whithout any error message and results a wrong number.
I tried it with a minimal AppWizard application, with one dialog and one edit
field. With ClassWizard I added a member to this field of type short and
validation in the range [0..9999].
The DoDataExchange shows as expected:
DDX_Text (pDX, IDC_TESTFLD, m_nTest);
DDV_MinMaxInt (pDX, m_nTest, 0, 9999);
m_nTest is declared as:
short m_nTest;
When the user types in e.g. "400077", the resulting m_nTest is "6861" without
any error.
Any ideas what's wrong? Is this a bug?
The MFC sources shows DDX_Text(,,short&) calls DDX_TextWithFormat(,,_T("%d")..).
I think %d formats int, which should be 32 bits. I think the correct form should
be to call with parameter "%sd" to force short readings.
Thank you in advance.
Sincerly,
Thomas Gessl
KOPFWERK EDV SW
AUSTRIA/EUROPE
begin 600 WINMAIL.DAT
M>)\^(C8%`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <`
M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$
MD 8`I (```(````,`````P``, ,````+``\.``````(!_P\!````/P``````
M``"!*Q^DOJ,0&9UN`-T!#U0"`````&UF8RUL0&YE=&-O;2YC;VT`4TU44 !M
M9F,M;$!N971C;VTN8V]M```>``(P`0````4```!33510`````!X``S !````
M$0```&UF8RUL0&YE=&-O;2YC;VT``````P`5# $````#`/X/!@```!X``3 !
M````$P```"=M9F,M;$!N971C;VTN8V]M)P```@$+, $````6````4TU44#I-
M1D,M3$!.151#3TTN0T]-`````P``.0`````+`$ Z`0````(!]@\!````! ``
M``````,-`````P``, 0````+``\.`0````(!_P\!````4P````````"!*Q^D
MOJ,0&9UN`-T!#U0"```!`#$P,# W,BXQ,#8W0$-O;7!U4V5R=F4N0T]-`%--
M5% `,3 P,#``$P`0```!T````G,3 P,#KL!'@!P``$````A````
M4D4Z($1$6%]497AT*"PL# $````%````4TU44 ``
M```>`!\,`0```!4```!D:VER8GE 86-C97-S;VYE+F-O;0`````#``800 G9
M* ,`!Q '! ``'@`($ $```!E````24)%3$E%5D542$E35T%31DE8141)3E9#
M*RLT,DA!5D593U544DE%1%1(14-/1$553D1%4E9#*RLT,C\M+41!3BTM+2TM
M+2TM+2U&4D]-.E1(3TU!4T=%4U-,4TU44#HQ,# P-P`````"`0D0`0```.($
M``#>! ``@ @``$Q:1G5?M&1L_P`*`0\"%0*D`^0%ZP*#`% 3`U0"`&-H"L!S
M973N,@8`!L,"@S(#Q@<3`H-&,P/%`@!P0A@'1 (@1WP
MCQT@'0`%H VP('5N!(&-'C<_"H4*A2TM9 !P1R%<"HL2 D4 $S(#$Y.38@-CHR,AQ@
M04TNCRBM5&\+,,\JZVT1H"UL0&YS$@`%H&TN.2$TGR^>=1QB:B:Q-K\JZT1$
M6 !?5&5X="@L+(9S*\ `("8I(&\<\#)R&G!O=R%-(]8S-@\E=Q7"# $F=D5N
M=FF]`V!N!X PHAY 'I Q,R#25PN .34A7$D#H AAI"!D!S%O9Q_#=1'P7P7
M'4$'0#]A'Z)O'1!YCG =``N 1S%A('-'@/)C!I!I8QVA'+ =\ (@_3-A=@=
M"E $( N "H4?TAD^DR!R&I$N("!"=?T%0'9*\ A@= N '0#=%Z!T"' &
M,4NP:1T@4%%]1J!N,W $D -@!< '@7->84LP4<$=\!>@P'M#X%910PM@!!!751R 8?YD#;!7
MH5)A35-',ATR2+6^9D=42J12\0J%26%I(E /6#(>`A_22P,@6S N=BXSX#/@
M752=*[ =`$3$;T18(&%%>!&Q8/)]/I%W1I$$(#XP2#$50&0R.D].*' ]\#,@
M242&0SX0+#!41DQ$,R"8;5]N/B 5,"D[3T>(5E]-"X!-87A%$/=EYFG"H7_9S5&<@6!"V 7H60Q9/9*I'MG-6J-5TO"1?=,-RX@9\T>P"(D
M\"SQ-R).\U,E!PN 1=!K>2(V.#8QOB)6(U!1"H51UU2=05'AW5_@91V!2[!8
M("<=45/BGC\<< 0@'2-(`&)U=R!C(H]B=DU&0T@0"&%C_P>18^0][S[P6!!&
MP'K(6S(>1@6P`, ^4CX0*"(E>&0B*6%0?C!5&!TP;OQK('X`':!]0TFR:=%1
M09\1L$J2,U =\!R@(#,2(/IB46!S'L!^]A_44B FLO]_HH#%"H6!04D!R,V L"H47B^$KME*!;(N(2T]0X$9715)+0I!H0 8`
M$E>+B$%59L!224'0+T554HV017@_D)]?0'\;J"9V"H46P0"4\ ```P`0$ ``
M```#`!$0`````$ `!S!@L9Z?M'J[`4 `"#!@L9Z?M'J[`1X`/0`!````!0``
3`%)%.B ``````P`--/TW``!=]7J[
`
end
| Вернуться в корень Архива
|