flat assembler
Message board for the users of flat assembler.
Index
> Windows > [HELP] Problem with SendMessage to Edit Control |
Author |
|
AsmGuru62 07 Jan 2012, 12:36
Works fine -- no matter how many clicks on "Sum" I do.
If you mean EM_GETLINE -- it does not put zero at the end of returned text, so before each message you need to zero out the whole line buffer. See Remarks here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb761584(v=vs.85).aspx Last edited by AsmGuru62 on 07 Jan 2012, 12:42; edited 3 times in total |
|||
07 Jan 2012, 12:36 |
|
MHajduk 07 Jan 2012, 12:39
Yes, I confirm. I haven't observed any problems with your application, see the screenshot:
|
|||
07 Jan 2012, 12:39 |
|
ctl3d32 07 Jan 2012, 13:13
This is very strange.
I keep getting this error. Watch this screencast i made: http://www.youtube.com/watch?feature=player_detailpage&list=ULuyRNFEuVBdE&v=uyRNFEuVBdE Thanks |
|||
07 Jan 2012, 13:13 |
|
MHajduk 07 Jan 2012, 13:38
Are you sure that you have posted here the same version of your program as the tested one? Sometimes such a qui pro quo may happen when you're coding all day long.
Another thing, could it be possible that there's something wrong with your FPU? Overheat or something like that (just guessing)... |
|||
07 Jan 2012, 13:38 |
|
ctl3d32 07 Jan 2012, 13:59
MHajduk wrote: Are you sure that you have posted here the same version of your program as the tested one? Sometimes such a qui pro quo may happen when you're coding all day long. I were using the same version. Placing a Null terminating char at the end of the returned string fixed the problem: Code: ;get text of each line mov word[buff],9d invoke SendMessage,[hEdit1],EM_GETLINE,[count],buff test eax,eax je .endsum ;null terminate the string mov byte[buff+eax],0 The problem is that SendMessage was returning not only the string, but other bytes too. See this olly dump (buff address): Code: 1st run: Read 1st line: CPU Dump Address Hex dump ASCII 0040205A 31 32 2E 33|06 07 AD 77|00 00 12.3w Read 2nd line: CPU Dump Address Hex dump ASCII 0040205A 31 30 2E 30|31 07 AD 77|00 00 10.01w 2nd run: Read 1st line: CPU Dump Address Hex dump ASCII 0040205A 31 32 2E 33|00 00 00 00|00 00 12.3 Read 2nd line: CPU Dump Address Hex dump ASCII 0040205A 31 30 2E 30|31 00 00 00|00 00 10.01 3rd Run: Read 1st line: CPU Dump Address Hex dump ASCII 0040205A 31 32 2E 33|31 00 00 00|00 00 12.31 Read 2nd line: CPU Dump Address Hex dump ASCII 0040205A 31 30 2E 30|31 00 00 00|00 00 10.01 Thanks Last edited by ctl3d32 on 07 Jan 2012, 14:22; edited 1 time in total |
|||
07 Jan 2012, 13:59 |
|
MHajduk 07 Jan 2012, 14:04
Yes, but from the other hand this doesn't explain why we haven't observed this strange behavior - we should see the same, at least from time to time.
|
|||
07 Jan 2012, 14:04 |
|
MHajduk 07 Jan 2012, 15:31
I've checked carefully your program execution under Olly and still haven't seen anything strange. There is no suspicious behavior of 'RtlZeroMemory' and 'SendMessage' functions - buffer isn't "polluted" by any unneeded chars.
My guess is that the same API functions may behave differently when their realization depends on the Windows version - this is the most rational explanation of this fact I can find for now. I think we all have to pay more attention to the more strict control on what is going on in our programs - API functions seem to be unpredictable. Even checking the return codes isn't enough as we can see in the aforementioned example. |
|||
07 Jan 2012, 15:31 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.