What Is The Proper Way to Format?
I am working with Petzold's "Colors1" program. The program uses three child-window scroll-bars to adjust color values. Three static child-windows are used to display the numerical values of the scroll bars.
Well, the program keeps hanging when the code attempts to change the text in the static windows. Here is that bit of code:
"szBuffer" is the pointer to a string, of type "wchar_t"
"color[i]" is the numerical position of scrollbar 'i' (0-255)
"hwndValue[i]" is the handle to child scrollbar 'i'
'i' has values 0-2
I realize that "wsprintf" has been superseded. This particular formatting statement has given me nothing but trouble in Petzold's programs. Yet, I cannot find the proper format function. "wsprintf" works great with TextOut(). But, it crashes the program when I try to use the output for a window caption, dialog box, etc.
Well, the program keeps hanging when the code attempts to change the text in the static windows. Here is that bit of code:
|
|
"szBuffer" is the pointer to a string, of type "wchar_t"
"color[i]" is the numerical position of scrollbar 'i' (0-255)
"hwndValue[i]" is the handle to child scrollbar 'i'
'i' has values 0-2
I realize that "wsprintf" has been superseded. This particular formatting statement has given me nothing but trouble in Petzold's programs. Yet, I cannot find the proper format function. "wsprintf" works great with TextOut(). But, it crashes the program when I try to use the output for a window caption, dialog box, etc.
Last edited on
sounds like a memory screw up, not the code here, eg one of {szBuffer, color, i, hwndValue} is not quite right. Check them one by one in your debugger, be sure i is in range of color, color is a valid array, szBuffer has memory, hwndValue is an array of the correct pointers...
(color and i sound fine if its part of an object).
where did you get memory for szBuffer?
(color and i sound fine if its part of an object).
where did you get memory for szBuffer?
Last edited on
Thanks Jonnin. I have tried initializing "szBuffer" two different ways. Both resulted in lockup. First I tried:
wchar_t szBuffer[10];
Then, I tried changing it to just a pointer: wchar_t* szBuffer;
I got the same result both times. It only needs to handle a three-digit number (four characters, if you include the zero termination of the string).
"color[i]" is the scrollbar thumb position. I know that it is valid, because, when I comment-out the two trouble-causing lines, the program works as it should. Same with the "hwndValue[i] handle. All of these are global variables.
wchar_t szBuffer[10];
Then, I tried changing it to just a pointer: wchar_t* szBuffer;
I got the same result both times. It only needs to handle a three-digit number (four characters, if you include the zero termination of the string).
"color[i]" is the scrollbar thumb position. I know that it is valid, because, when I comment-out the two trouble-causing lines, the program works as it should. Same with the "hwndValue[i] handle. All of these are global variables.
Could it be that windows captions and message boxes will only accept "constant" character strings? According to the documentation, windows captions and message boxes only accept type "LPCWSTR"---'C' standing for "constant". Conversely, "wsprintf" outputs type "wchar_t*". The only difference being, that "wchar_t*" is not "constant". Is this some kind of Windows security measure?
Then, I tried changing it to just a pointer: wchar_t* szBuffer;
that for sure will not work: it has no memory. pointers are not automated in c++ you have to call new and delete to use one, and there isnt any point here (arrays will collapse to pointers and do the work for you for this task).
wchar_t szBuffer[10]; <- this should work if 10 is sufficient. you can try 100 instead just to knock that out of the running as a potential fail, just in case colors[i] is a goofed up value. This seems unlikely, though.
I would think if it were mad about constants it would be at compile time. Windows does not to my knowledge treat const any different than normal code, and if it compiles, as far as I know, it should work and any compile time fails would tell you "type mismatch const blah blah differs from blah blah at some place"
What is in the buffer after the printf? Can you debug check just that to see if the string is legit?
also can you setwindowtext with a constant string like "test" ? You probably need a L or whatever it is on the string to force it to be wide, but see if a constant works ...
finally, check the global variable stuff. is this being called before those have valid values? That can happen in windows event driven areas, esp the hwnd one could be sour if called before it is populated.
that for sure will not work: it has no memory. pointers are not automated in c++ you have to call new and delete to use one, and there isnt any point here (arrays will collapse to pointers and do the work for you for this task).
wchar_t szBuffer[10]; <- this should work if 10 is sufficient. you can try 100 instead just to knock that out of the running as a potential fail, just in case colors[i] is a goofed up value. This seems unlikely, though.
I would think if it were mad about constants it would be at compile time. Windows does not to my knowledge treat const any different than normal code, and if it compiles, as far as I know, it should work and any compile time fails would tell you "type mismatch const blah blah differs from blah blah at some place"
What is in the buffer after the printf? Can you debug check just that to see if the string is legit?
also can you setwindowtext with a constant string like "test" ? You probably need a L or whatever it is on the string to force it to be wide, but see if a constant works ...
finally, check the global variable stuff. is this being called before those have valid values? That can happen in windows event driven areas, esp the hwnd one could be sour if called before it is populated.
Last edited on
Someone has taken the time and trouble to update most of Petzold's 1998 5th Edition Win32 API C source to more up-to-date Win32 API. I've used it successfully with Visual Studio 2017/2019 to have working Windows apps.
https://github.com/recombinant/petzold-pw5e
https://github.com/recombinant/petzold-pw5e
Thanks Jonnin and Furry Guy. Y'all want to hear something crazy? I fired-up that program this morning, and it's suddenly working! There must have been a glitch in the compiler. Or, maybe, seeing that I'm using a cheap laptop, the compiler may have had a memory overrun, after I had to fix so many errors. Next time, I'll think to reboot, when I have this problem. Why it always wants to hang on "wsprintf" though, I'll never know.
The code looks fine.
You had a separate coprocessor if you were one of the cool kids, the rest of us had to put up the code bloat of an emulation library and the x5 execution slow down. So pretty much everything was done with ints.
wsprintf is a stripped down version of sprintf, with no floating point support, It goes back to WIN16, when floating point support was a big deal.You had a separate coprocessor if you were one of the cool kids, the rest of us had to put up the code bloat of an emulation library and the x5 execution slow down. So pretty much everything was done with ints.
Last edited on
Topic archived. No new replies allowed.