 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Bill Carson
Guest
|
 Posted: Wed Jul 02, 2003 9:05 pm Post subject: sprintf and SetDlgItemText behavior |
 |
|
I have a WIN32 API dialog procedure that uses the sprintf
function to fill a string which I display with an edit control
using the SetDlgItemText function in the WM_INITDIALOG
case:
sprintf(gmessage, "min: %f max: %f range: %f", min, max, max - min);
SetDlgItemText(hwndDlg, 199, gmessage);
This works fine, and the variable values are displayed correctly. But
when I use the exact same call in another case of the dialog procedure
the variables no longer display with the correct values. For instance,
for the WM_INITDIALOG case an output was:
min: 150.000000 max: 2832.000000 range: 2682.000000
But for the WM_COMMAND case in which a button activates
the edit display using the exact same code as above, I get this:
min: -0.000000 max: 0.000000 range: 0.000000
The variables are defined and intialized within the dialog procedure as:
char gmessage[400];
double min, max;
I've tried declaring them as global variables, but the result is the
same.
I'm stumped. Any insights into possible reasons for this behavior
would be most welcome.
Thanks,
Bill
|
|
| Back to top |
|
 |
Ed Mulroy [TeamB]
Guest
|
| Posted: Thu Jul 03, 2003 12:05 am Post subject: Re: sprintf and SetDlgItemText behavior |
|
|
If I had that problem I'd start by renaming the variables 'min' and 'max' to
remove the name clash with either of names of standard C++ functions and
with macros in Windows' header files.
Since you are hard coding the control number in the call to SetDlgItemText
instead of using a macro or constant, double check the control-id number
used in the call that doesn't work.
I don't understand the reference to WM_COMMAND. A Dialog Procedure doesn't
use that message. If a main window procedure uses that command and calls
SetDlgItemText, doesn't it take until messages flow again (until a
PeekMessage or GetMessage loop) before the alteration takes? (Ok, so in
Win32 the answer is "not always", it depends upon how it's designed - check
it.)
.. Ed
| Quote: | Bill Carson wrote in message
news:3f034921 (AT) newsgroups (DOT) borland.com...
I have a WIN32 API dialog procedure that uses the sprintf
function to fill a string which I display with an edit control
using the SetDlgItemText function in the WM_INITDIALOG
case:
sprintf(gmessage, "min: %f max: %f range: %f", min, max,
max - min);
SetDlgItemText(hwndDlg, 199, gmessage);
This works fine, and the variable values are displayed correctly.
But when I use the exact same call in another case of the dialog
procedure the variables no longer display with the correct values.
For instance,
for the WM_INITDIALOG case an output was:
min: 150.000000 max: 2832.000000 range: 2682.000000
But for the WM_COMMAND case in which a button activates
the edit display using the exact same code as above, I get this:
min: -0.000000 max: 0.000000 range: 0.000000
The variables are defined and intialized within the dialog procedure as:
char gmessage[400];
double min, max;
I've tried declaring them as global variables, but the result is the
same.
I'm stumped. Any insights into possible reasons for this behavior
would be most welcome.
|
|
|
| Back to top |
|
|
Bill Carson
Guest
|
| Posted: Thu Jul 03, 2003 4:16 am Post subject: Re: sprintf and SetDlgItemText behavior |
|
|
Ed:
Thanks for your reply:
| Quote: | If I had that problem I'd start by renaming the variables 'min' and 'max'
to
remove the name clash with either of names of standard C++ functions and
with macros in Windows' header files.
|
Yikes! - good point, I renamed the variables, but to no avail. Even with
new
names the result was the same.
| Quote: | Since you are hard coding the control number in the call to SetDlgItemText
instead of using a macro or constant, double check the control-id number
used in the call that doesn't work.
|
The control numbers were the same. I changed the hard coded control number
to a constant, recompiled my resource file, etc. but the result was the same
except
that I got a new set of numbers:
min: -2.325263400790467563000000000000000000000e+267 max: 0.000000 range:
2.325263400790467563000000000000000000000e+267
hmmmmm???
| Quote: | I don't understand the reference to WM_COMMAND. A Dialog Procedure
doesn't
use that message.
|
Yes they do. From the Windows SDK help: "Most dialog box procedures process
the WM_INITDIALOG message and the WM_COMMAND messages sent by the controls,
but process few if any other messages. If a dialog box procedure does not
process a message, it must return FALSE to direct Windows to process the
messages internally." See the SDK for several examples of using
a WM_COMMAND message in a modal dialog box.
This is a modal dialog box I am creating from a resource file using the
DialogBox function. I
think you can also create a dialog box as a child window, which may be what
you are
thinking of?
| Quote: | If a main window procedure uses that command and calls
SetDlgItemText, doesn't it take until messages flow again (until a
PeekMessage or GetMessage loop) before the alteration takes?
|
I don't know, I have yet to use the SetDlgItemText call in a main
window.
I am still perplexed as to what is happening. I could paste the whole
dialog
box procedure in a message but is over 110 lines long. Is that too long to
post to the newsgroup?
Thanks,
Mike
|
|
| Back to top |
|
|
Ed Mulroy [TeamB]
Guest
|
| Posted: Thu Jul 03, 2003 12:12 pm Post subject: Re: sprintf and SetDlgItemText behavior |
|
|
You are correct. I was talking about something other than a modal dialog
box/vanilla API style code. There's a trap that I fall into where I'm into
how someone does his stuff, reply to that and stay in that mode for the next
reply - your message was my next reply :-(
| Quote: | The control numbers were the same. I changed the hard
coded control number to a constant, recompiled my
resource file, etc. but the result was the same except
that I got a new set of numbers:
|
The hard coded number itself is really not the issue. The issue was that
using an actual number instead of a macro provides a greater chance for an
error where the number in the resource file and that in the source (or
number in this function vs in that function, etc) do not agree. In projects
of any size, when I didn't use a macro for a control ID number I often would
mess up a number somewhere when making a change or revision with results
vaguely similar to what you described.
The fact that when you changed the control number nothing happened other
than the bad data's value changed suggests a good chance of a memory
over-write, stack imbalance or other memory corruption. Failure to init
something could do it also, but I assume you've checked that by now.
Look at array and pointer usage. Also check "I already know this part is
right" stuff such as if the dialog procedure name needed a cast in the line
which calls DialogBox - if so the procedure is wrong and needs to be checked
(missing CALLBACK?, arg list wrong? stuff like that).
110 lines is a bit long for a newsgroup message, and it will be longer
because you'll invariably need to show the declarations for some variables,
types etc and probably the creation code for the dialog box. The
attachments group could be used for that but nobody will look there unless
you post telling something is over there.
If you still cannot find it after a good look, feel free to zip it up and
aim it at my email box [email]ed (AT) mulroy (DOT) org[/email] (to others reading this, please don't
send your questions or programs to my email box unless unvited. I can't
handle the volume). I cannot promise success but can promise to try to find
the problem. If you do that, I'll need to be able to build and debug so
I'll need make file, resource file, sources etc. If you're worried about
security - this only goes to me and not to any others and I've no interest
in ripping off what you're doing.
.. Ed
| Quote: | Bill Carson wrote in message
news:3f03ae1c (AT) newsgroups (DOT) borland.com...
Since you are hard coding the control number in the
call to SetDlgItemText instead of using a macro or
constant, double check the control-id number
used in the call that doesn't work.
The control numbers were the same. I changed the hard
coded control number to a constant, recompiled my
resource file, etc. but the result was the same except
that I got a new set of numbers:
min: -2.325263400790467563000000000000000000000e+267
max: 0.000000
range: 2.325263400790467563000000000000000000000e+267
...
This is a modal dialog box I am creating from a resource file
using the DialogBox function. I think you can also create a
dialog box as a child window, which may be what you are
thinking of?
I am still perplexed as to what is happening. I could paste
the whole dialog box procedure in a message but is over 110
lines long. Is that too long to post to the newsgroup?
|
|
|
| Back to top |
|
|
Bill Carson
Guest
|
| Posted: Fri Jul 04, 2003 9:03 pm Post subject: Re: sprintf and SetDlgItemText behavior |
|
|
Ed:
| Quote: | Look at array and pointer usage. Also check "I already know this part is
right" stuff such as if the dialog procedure name needed a cast in the
line
which calls DialogBox - if so the procedure is wrong and needs to be
checked
(missing CALLBACK?, arg list wrong? stuff like that).
I went through all my dialog box procedure from the resource template |
to the code but didn't see anything obvious, but I am still looking.
| Quote: | 110 lines is a bit long for a newsgroup message, and it will be longer
because you'll invariably need to show the declarations for some
variables,
types etc and probably the creation code for the dialog box. The
attachments group could be used for that but nobody will look there unless
you post telling something is over there.
I didn't realize there was an attachments group, thanks for the heads up. |
Instead
of emailing you the code, I have put it up on the attachment group for you
to
look at if you have the time. I imagine since I am a complete beginner at
Windows programming it is something real simple that you may spot.
I am continuing to work the problem. Please let me know if you see anything
suspicious.
Thanks,
Bill
|
|
| Back to top |
|
|
Bill Carson
Guest
|
| Posted: Sun Jul 06, 2003 1:58 am Post subject: Re: sprintf and SetDlgItemText behavior |
|
|
Bob :
| Quote: | minelev and maxelev are set in the init dialog function, set to the
edit control, then immediately forgotten (they are local variables).
By the time the second set of sprintf/sendmessage happens, those
variables are uninitialized.
|
It's probably my ignorance, but I thought that when I declare a
variable in a dialog procedure, it should persist until the dialog
box is closed with EndDialog(). Since the dialog box is the top
window during both calls to the edit control, then I would expect
the variables to remain initialized. Obviously not!
If I declare them thus: "static double minelev, maxelev;"
then they do display correctly in the second sprintf/ SetDlgItemText
calls. However, even when I declare them as global variables
(declare before WinMain) they still do not show correctly in
the second calls (even if I declare them as static).
I think I will change to the DialogBoxParam function to see if I can't
maintain more persistent variables, and get away from the globals.
Thanks for your insights.
Bill
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
