In assembly, how can I be notified that a edit box in a dialog box has
been populated?

Basically, I want to disable a button when the edit box contains
nothing, and I want to enable a button when the edit box contains
something.  But I'm not sure how to do this in assembly.

On Wed, 20 Aug 2008 18:51:07 -0700 (PDT), "bwaichu@yahoo.com"
<spamtrap@crayne.org> wrote:

>In assembly, how can I be notified that a edit box in a dialog box has
>been populated?
>
>Basically, I want to disable a button when the edit box contains
>nothing, and I want to enable a button when the edit box contains
>something.  But I'm not sure how to do this in assembly.
>

An edit box isn't populated automatically, you normally do it in
response to a WM_INITDIALOG message which is sent just before the
dialog box is first drawn.  If your edit box is on the main window
instead of in a separate dialog box, you would do the initialization
when the app starts up.

If you want the edit box to be disabled when you have no valid value
to send it, you can send nothing when you initialize it, then disable
it.  It won't receive any more messages, so the user can't change the
blank state.  (But you can send values to it from your app, even when
it is disabled.  You might want to do this to show the values that
would be applied when the app is changed to another mode of some
sort.)

Best regards,

  
Bob Masta
 
              DAQARTA  v4.00
   Data AcQuisition And Real-Time Analysis
             www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
           FREE Signal Generator
        Science with your sound card!

In article <d331e256-5493-497c-b614-fd173f52db49
@v26g2000prm.googlegroups.com>, spamtrap@crayne.org says...
> In assembly, how can I be notified that a edit box in a dialog box has
> been populated?
> 
> Basically, I want to disable a button when the edit box contains
> nothing, and I want to enable a button when the edit box contains
> something.  But I'm not sure how to do this in assembly.

You do it pretty much the same in assembly language as you would in any 
other language.

When the user does something to change the contents of an edit control, 
the edit control:
1) Takes the input and validates to the extent it can.
2) Assuming the data is valid, it formats the data.
3) Sends its parent an EN_UPDATE message.
4) Redraws itself.
5) Sends its parent an EN_CHANGE message.

Your code can reject invalid input by responding to either EN_UPDATE or 
EN_CHANGE. Responding to EN_UPDATE means that it appears to the user 
that invalid input is completely ignored -- when/if they enter something 
that's not allowed, there's no (visible) change in the data at all.

Responding to EN_CHANGE means that when they enter invalid data, it 
shows up on screen for a fraction of a second before it's rejected. If 
you want that, EN_CHANGE isn't necessarily the best way to do it though 
-- you can (for example) take note of the incorrect input in response to 
EN_UPDATE, and then handle WM_CTLCOLOR by (for example) setting the edit 
control's background to bright red (or whatever) to indicate bad input, 
then wait a fraction of a second, and remove the invalid input. Another 
possibility is to use an RTF control so you can highlight just the 
invalid part of the input before rejecting it.

Of course, there's also the "big hammer" approach -- if the messages 
above don't give you the control you need, you can subclass the control 
and do whatever else you need/want...

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

On Aug 21, 7:00�am, Jerry Coffin  <spamt...@crayne.org> wrote:

>
> When the user does something to change the contents of an edit control,
> the edit control:
> 1) Takes the input and validates to the extent it can.
> 2) Assuming the data is valid, it formats the data.
> 3) Sends its parent an EN_UPDATE message.
> 4) Redraws itself.
> 5) Sends its parent an EN_CHANGE message.
>
> Your code can reject invalid input by responding to either EN_UPDATE or
> EN_CHANGE. Responding to EN_UPDATE means that it appears to the user
> that invalid input is completely ignored -- when/if they enter something
> that's not allowed, there's no (visible) change in the data at all.
>
> Responding to EN_CHANGE means that when they enter invalid data, it
> shows up on screen for a fraction of a second before it's rejected. If
> you want that, EN_CHANGE isn't necessarily the best way to do it though
> -- you can (for example) take note of the incorrect input in response to
> EN_UPDATE, and then handle WM_CTLCOLOR by (for example) setting the edit
> control's background to bright red (or whatever) to indicate bad input,
> then wait a fraction of a second, and remove the invalid input. Another
> possibility is to use an RTF control so you can highlight just the
> invalid part of the input before rejecting it.
>
> Of course, there's also the "big hammer" approach -- if the messages
> above don't give you the control you need, you can subclass the control
> and do whatever else you need/want...
>
> --
> � � Later,
> � � Jerry.
>
> The universe is a figment of its own imagination.

Thanks.

I ended up with this approach:

* wait for WM_COMMAND
* check for EN_CHANGE
* verify the box being changed is the one I want
* send a message WM_GETTEXTLENGTH
* if the length returned is greater or equal to one, enable the button

The un-elegant part about the above is I am constantly sending
messages
every time the edit box is changed.

As for checking for EN_CHANGE, I went about it this way:

mov dword eax, [wparam]
shr eax, 16
cmp word ax, EN_CHANGE
je DoSomething

That's the most straight forward way I could think of.

One frustration I am running into is that I have jumps all over my
assembly,
and every so often, NASM complains about the distance to the jump.  I
can get
around the complaint by setting -O4, especially if I am jumping
ahead.  Any
tips on handling jmps well?  It's a 32 bit app, so I'm not sure about
the jump
syntax for specifying a far jump in NASM.

bwaichu@yahoo.com wrote:

....
> One frustration I am running into is that I have jumps all over my
> assembly,
> and every so often, NASM complains about the distance to the jump.  I
> can get
> around the complaint by setting -O4, especially if I am jumping
> ahead.  Any
> tips on handling jmps well?  It's a 32 bit app, so I'm not sure about
> the jump
> syntax for specifying a far jump in NASM.

"jmp" defaults to "near", "jcc" defaults to "short" (+/- 127 bytes - a 
"signed byte" range). Nasm will complain about a conditional jump 
outside that range. Nasm shouldn't complain about a "jmp" unless you 
specify "jmp short target". Specifying the "-O" switch overrides this 
behavior, and Nasm chooses the size you need, as well as using "signed 
byte" forms of instructions that have such a form, if appropriate. 
(Nasm's default behavior of using the "long form" is kinda brain-dead, 
but is "documented", so unlikely to change). "4" is rather a small 
parameter to give the "-O" switch - Nasm will quit when it's done, the 
parameter is the *maximum* number of passes to use - I used to use 
"-O999", but now Nasm will accept "-Ox" to allow the maximum number of 
passes.

I know "near" is a bit "counter-intuitive" for a "more distant" jump, 
but that's the syntax...

A "far" jump would involve cs as well as (e)ip - almost certainly not 
what you want in a 32-bit app (useful in 16-bit code that exceeds 64k).

Best,
Frank

"bwaichu@yahoo.com"  <spamtrap@crayne.org> wrote:
>
>I ended up with this approach:
>
>* wait for WM_COMMAND
>* check for EN_CHANGE
>* verify the box being changed is the one I want
>* send a message WM_GETTEXTLENGTH
>* if the length returned is greater or equal to one, enable the button
>
>The un-elegant part about the above is I am constantly sending
>messages every time the edit box is changed.

That executes a trivial amount of code.  You can single-step through it to
convince yourself of that.  Most window messages cost very little.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

On Aug 21, 8:47�am, Frank Kotler  <spamt...@crayne.org> wrote:
> bwai...@yahoo.com wrote:

> "jmp" defaults to "near", "jcc" defaults to "short" (+/- 127 bytes - a
> "signed byte" range). Nasm will complain about a conditional jump
> outside that range. Nasm shouldn't complain about a "jmp" unless you
> specify "jmp short target". Specifying the "-O" switch overrides this
> behavior, and Nasm chooses the size you need, as well as using "signed
> byte" forms of instructions that have such a form, if appropriate.
> (Nasm's default behavior of using the "long form" is kinda brain-dead,
> but is "documented", so unlikely to change). "4" is rather a small
> parameter to give the "-O" switch - Nasm will quit when it's done, the
> parameter is the *maximum* number of passes to use - I used to use
> "-O999", but now Nasm will accept "-Ox" to allow the maximum number of
> passes.
>
> I know "near" is a bit "counter-intuitive" for a "more distant" jump,
> but that's the syntax...
>
> A "far" jump would involve cs as well as (e)ip - almost certainly not
> what you want in a 32-bit app (useful in 16-bit code that exceeds 64k).
>
> Best,
> Frank

Thanks.  I am now using the -Ox option.

And thanks for the refresher on conditional jumps.  I had overlooked
the
default for conditional jumps.  But instead of trying to do the math,
I'm
just relying on NASM to optimize them for me.

On Aug 21, 10:03�pm, Tim Roberts  <spamt...@crayne.org> wrote:
> "bwai...@yahoo.com" �<spamt...@crayne.org> wrote:
>
> >I ended up with this approach:
>
> >* wait for WM_COMMAND
> >* check for EN_CHANGE
> >* verify the box being changed is the one I want
> >* send a message WM_GETTEXTLENGTH
> >* if the length returned is greater or equal to one, enable the button
>
> >The un-elegant part about the above is I am constantly sending
> >messages every time the edit box is changed.
>
> That executes a trivial amount of code. �You can single-step through it to
> convince yourself of that. �Most window messages cost very little.

The code amount is very trivial.  I just didn't know if there was an
alternative
that was more effective.  I think I'm still at the stage of just
trying to get stuff to
work.

"bwaichu@yahoo.com" wrote:
: The code amount is trivial. I just didn't know if there was an
: alternative that was more effective.

That's just the way Windows (and all of it's windows) works. It
works quite well. Every window (edit box, list box, combo box,
scroll bar, status bar) either relies upon it's parent message
handler, and/or has a handler itself. It makes programming very
nice. For instance, when you click on the arrow next to a list
box or combo box, that window responds by presenting a drop down
list. When you type a character into one of those windows, the
window responds according to the way the message handler tells it
to.

When using a higher level language, this gets noted and then the
programmers start wanting to make the objects do things they lack.
This whole process of taking over the message handler ends up as
something called subclassing and callbacks.

1) Just like a window (dialog box or other), every control has a
   window message handler where the various windows messages get
   handled.

2) The address of the message handler of a control is stored in a
   way so as to make it easily accessible.

3) You can change the address of the message handler and build a
   routine to define how the messages get handled.

4) Upon seeing the message, you control how to handle the message and
   so determine if you'd like to pass the message on to the original
   message handler of the control, or handle and then consume the whole
   message so that nothing gets passed on.

NOTE

Microsoft should have called Windows by her true name, Sweet Windows
Message Handlers.

In answer to your question, is there an alternative?

An alternative ALWAYS exists. Do you want to build your own OS ?
I suppose there might be another way, but I'm thinking it's going
to involve a lot of determination, time and effort. That's just the way
Windows works, worked back in the days of Windows 3.1 and the early
versions of NT, and possibly even earlier. I'm even thinking along the
lines that DOS worked in much the same way, handling events created by
interrupts, waiting for activity from the keyboard, and if you think
about it for a moment, that's the way it all works, hardware constantly
sends a variety of messages to the software. And it all gets handled
somewhere. Inside of Windows it gets handled in the WndProc() procedures
for each window.

Can anyone enlighten us how things work in Unix/Linux? If they work
in a fashion like that on Windows? Perhaps someone can comment on
the names of the procedures on Linux, if they carry something like
WinMain() and WndProc().

-- 
Jim Carlock
You Have More Than Five Senses
http://www.associatedcontent.com/article/381163/more_than_five_senses.html

On Aug 23, 1:05�am, "bwai...@yahoo.com"  <spamt...@crayne.org> wrote:
> On Aug 21, 8:47�am, Frank Kotler �<spamt...@crayne.org> wrote:
>
>
>
> > bwai...@yahoo.com wrote:
> > "jmp" defaults to "near", "jcc" defaults to "short" (+/- 127 bytes - a
> > "signed byte" range). Nasm will complain about a conditional jump
> > outside that range. Nasm shouldn't complain about a "jmp" unless you
> > specify "jmp short target". Specifying the "-O" switch overrides this
> > behavior, and Nasm chooses the size you need, as well as using "signed
> > byte" forms of instructions that have such a form, if appropriate.
> > (Nasm's default behavior of using the "long form" is kinda brain-dead,
> > but is "documented", so unlikely to change). "4" is rather a small
> > parameter to give the "-O" switch - Nasm will quit when it's done, the
> > parameter is the *maximum* number of passes to use - I used to use
> > "-O999", but now Nasm will accept "-Ox" to allow the maximum number of
> > passes.
>
> > I know "near" is a bit "counter-intuitive" for a "more distant" jump,
> > but that's the syntax...
>
> > A "far" jump would involve cs as well as (e)ip - almost certainly not
> > what you want in a 32-bit app (useful in 16-bit code that exceeds 64k).
>
> > Best,
> > Frank
>
> Thanks. �I am now using the -Ox option.
>
> And thanks for the refresher on conditional jumps. �I had overlooked
> the
> default for conditional jumps. �But instead of trying to do the math,
> I'm
> just relying on NASM to optimize them for me.

Before the advent of modern frameworks, C programmers used "message
crackers" to keep their code more maintainable.  In the ASM world,
this is "jump table" (er... "call table") and some people feel it is
very helpful in keeping your code structured sanely.

http://hlaex.svn.sourceforge.net/viewvc/hlaex/generic/JumpTables2.hla?revision=2&view=markup

Nathan.