In addition to what Jochen said, sometimes looking at the disassembly is helpful.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
First of all: Casting happens implicitly so you don't need to cast in this scenario.
Secondly: These types that you are specifying in non-standard types, so uint32_t could be defined as anything which will give you an incorrect result.
Thirdly: How to you check what the result is? Though debugging or though a print statement? The print statement could be wrong.
Fouth: Know your platform you writing the code for (its limitations and the standard it is using). Not necessarily that the pic32 uses the specific c standard which you are looking at.
"Program testing can be used to show the presence of bugs, but never to show their absence."
I put a TRACE macro inside of ON_UPDATE_COMMAND_UI handler, but strange, it doesn't call at all ... that is why the text is not changing ... this message (ON_UPDATE_COMMAND_UI) is not calling for menu items that has derived menu from itself ?
It is difficult to guess what may be happening in your code, but changing the text of a control should have no effect on the message passing and event handling for that control. I would try it myself but do not have MFC on my system.
have this code in secure shell
and I want to keep log of the users input
I fopen the file in the beginning
and fprinf on the data specific that needs to be written
then at end of file I fclose it
the problem is that its not writing the file
when I cat gamelog it just sends me to the next calling line