I'm having this problem:
Every object on my dialog accepts this function:

exept for an EditBox, which is what I need most. Whenever I put an ID of some
'EDIT' dialogitem, the function returns unexpectedly with ESP-452 and never
reaches the instruction right after it so this loops forever:

Any ideas? or should I use labels (called 'STATIC' by FASM)

Ok, I've debugged and rewritten my code and realized that the problem isn't
with EditBox's, but the way items are updated. I don't know is it API or FASM,
but if the same Item that posted a WM_COMMAND(EN_CHANGE) is edited the
error occurs. When first Getting the text and Setting then it just quits, but if
no GetDlgItemText has been made on that Item and Set anyway - the result
is stack overflow

why do you modify esp value like that?

It's the only way it works
There seems to be a problem with the SetDlgItemText,because
it does NOT return from the call, but sets the ESP 452 less than
it should be and then returns (or jumps - haven't figured it out
yet) so EIP never gets begger than the one where SetDlgItemText
call is made, but loops it forever (or ends with a stack error when
I don't change esp) strange!

Perhaps you should post the code or the exe. Personally you should never change esp values unless you know what you are doing.

Ok, try these:
I have 1.54, so compiling in it is guaranteed, but back to 1.52 should work the
same because no big changes have been made (I think)

Took me some time to figure out. When you call SetDlgItemText, the message EN_CHANGE is sent to the windows handler, hence your function get trapped in a loop which eats up the stack.

Why is that and how can I fix it.
I made my own experiments and I tried skipping Set, when Get was zero
and I got it to work, but it crashed again, when trying to modify the
problematic Edit in question

I think you should handle keydown instead of EN_CHANGE

Sorry, but MSDN doesn't give me any helpful information on that. I don't know what to catch and when. I have research so far that I know something about constants, like WM_... messages are in the main message [msg] and other constants are usually in [wParam] but are the kind of buttons clicked in [lParam] or WORD part of [wParam] and my tries catching Keydown have failed, because I get confusing messages like CTLCOLOR and CHANGE or UPDATE (not both in same cycle!!!) it makes it even harder, when MSDN codes everything in C, but I need to translate them to ASM

Let me explain myself.

Using SetDlgItemText in a EN_CHANGE handler will result in an endless loop because the SetDlgItemText will send the message EN_CHANGE.

I was thinking of the line of handle WM_KEYUP and checking whether the focus is in editcontrol (GetFocus + GetDlgItem). Not sure whether it would work.

I'm gonna try. It just too much trouble to make my own EN_UPDATE kinda thing by checking KBinput. I can get this to work, but APIs should make life easier ...hmm
I think it's called a bug, when something doesn't do what it is supposed to do, but ok, maybe those guys at M$ didn't expect someone to be so stupid to change the same EditBox, that just has changed:P
P.S. It isn't documented either - the Get-Set for the same item ^o)

But don't you find it weird? After you type, the value in the editbox changes?

I know what to do:D
I got it working, when flagging what I was doing so on start of every cycle it checks the flag and when it is set by some other 'thread' it passes and exits so it won't loop and one 'thread' finishes by setting value to 0 again to flag ending what its doing. Then when some other change happens, flag=0 enables it to start again. Why didn't I think of that before