Posted by ADnoctum on 2000-06-02
>One thing that might be an issue is: do you KNOW FOR SURE that the >strings in 'buffer' are null terminated. I assume they are, but check to make sure >anyway. atoi() does some wierd things when you pass a sting that's not null >terminated. I think they are, but check just to eliminate the possibility. > >In 'memset()' why are you setting the array to 0? Try setting it to ' ' (a space) >in each element of the array. That's why i put those memset to be sure that there is a null at the end of the string. >Take a look at 'wsprintf()', the second parameter takes null terminated string. >Just to eliminate the possibility, add a null terminator to the end of that statement >just to see that it's not the problem. >Also, look at the final three parameters in wsprintf(). Through any given pass >of the message loop, ONLY one of those 'rgb' fields is filled with the 'atoi()' value. >The rest aren't initalized. It could be that wsprintf() is sometimes trying to convert >some sort of random garbage value(a value that wasn't set with atoi()) to >hexadecimal, while the value that was set with atoi() might be converting properly. >The other two, unintialized(unfilled) 'rgb' values could be causing an error. If the >uninitialized value there can't be changed to hexadecimal.........possible crash 'n' >burn. The global variables fg.r, fg.g, fg.b are initalized in the WM_CREATE message to 255(the value that is displayed in the edit controls), and cur is initialized to `cur = &fg;' so I don't think that may be the problem here. >Try initializing each 'rgb' field first. Set all of them to 0, then go about the >program normally. done >Honestly though, I don't see anything wrong with the code, which means that the >problem is so subtle that it's easially overlooked. The only things that >POTENTIALLY might be wrong are above. That's all that seems out of place to >me. I hope this helps. I don't see either
Previous post | Next post | Timeline | Home