Re: edit box population in a dialog box
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 21 Aug 2008 18:36:41 -0400
See below...
On Thu, 21 Aug 2008 13:14:52 -0700 (PDT), "bwaichu@xxxxxxxxx" <bwaichu@xxxxxxxxx> wrote:
On Aug 21, 12:15 pm, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:****
****
So if I type a space, you enable the button, even though the contents may be nonsensical
because there is actually nothing there?
****
Good point. However, a space is still a legit ascii character. Right
now, this is just a framework
to experiment with later, so I might want to add some checking
depending on how I process the
content in the edit box.
"Legitimate" is a term which is very application-specific. For example, if I have a field
that is "blank" then a field with 20 spaces may not convey any more meaning than a field
that is completely empty. Take a look at my logging listbox control, for example, which
parses floating-point numbers and changes the background based on the validity of the
number as typed.
****
****
I really need to know what messages are available to review. There is
a lot of power there that
I am neglecting.
I have one problem though. Every time a change occurs to the edit
box, I check to
see the length of the item in the edit box. I wonder if there is a
more elegant way to
this.
*****
No. It is the only correct and possible way to do it. There is no need to look at the
control unless it tells you it changed.
I would use WM_GETTEXT and strip leading and trailing spaces off to make sure I had
content.
*****
I will need to experiment with this.
Tweaking the bits was a challenge as well. I need to experiment with
some
better ways to test for EN_CHANGE.
*****
Have you considered writing in a modern language like C++/MFC? What, exactly, favors the
1950s model of programming?
joe
*****
I all ready have a version of this written using MFC. I just wanted
to write an equivalent version in
assembly. It helps my debugging skills. And since translating MFC
stuff over in assembly is a pain, I
just wanted to deal with the messaging system. What really surprises
me is that this app links to
being 3k, and my MFC app is 33k. That's an amazing difference, not
that storage is a problem.
And what makes you think that 30K has the slightest impact on overall system performance,
the performance of your program, or anything else? It isn't an "amazing" difference, it
is a completely irrelevant difference. It only shows that tiny programs can be made very
small, but unless you ALSO compare this code with IDENTICAL functionality written in pure
C, the comparison is completely meaningless.
A desire to learn assembly code is one thing, but trying to justify assembly code as being
a meaningful means of implementing code for OTHER than the experience of having written it
is problematic (I have written hundreds of thousands of lines of assembly code on, let's
see, the IBM 1620, the IBM 1401, the IBM /360 series, the Honeywell 200 series, the
DECSYSTEM 10/20 systems, the PDP-11 system, the Z80, the 6809, the 80x86 family and the
Motorola 68000 family, plus a few other weird machines that I only wrote tiny programs
for. It is not cost-effective as a development strategy.
*****
****
I also like how I can touch anything in windows in assembly; there are
very few limitations.
There are no limitations if you do it in C or C++ either.
****
However, I****
stick to assembly for just writing small little apps, for bigger stuff
I'll use C, and if it's really tiny, I might
use Ruby. Windows doesn't have the equivalent of ksh.
For which the entire universe should be grateful. There are few programming languages
more horrific, badly-designed, and destructively idiosyncratic than the various Unix shell
languages (I spent 15 years in Unix, and learned to hate *every* shell in existence; csh
was the least offensive)
****
****
If I am using *BSD, I will try to write it in ksh first, and if that
doesn't work, I'll jump over to C. C just
works better for me on *BSD. Windows really needs stronger shells.
No, shells are basically crap. I rarely run across anything that I would want to write a
shell-script for. The only issue in shells is the comparative crappiness of them. If you
have to resort to shell programming, there's something wrong in your design.
*****
****
The bit tweaking wasn't really that bad; I was just over thinking it.
Ends up looking like:
mov dword eax, [wparam]
shr eax, 16 ; put the high word in ax for compare
cmp word ax, EN_CHANGE
je DoSomething
Pretty bad code. The fastest way to do it is
mov ax, wparam+2
cmp ax, EN_CHANGE
je DoSomething
does it in one instruction, no shifting required. I would typically use a struct I
overlay on wParam and load from that. And yes, you can create structs in assembly code
and you can decide how they are being addressed. So [wparam] implies that you have some
register pointing to wParam, probably the ebp, so you could declare a struct and declare
it as ebp-relative (when I wrote x86 code we would declare "stack frame" structs, I no
longer recall the syntax, because that was almost 20 years ago, but it is relatively easy.
*****
*****
then, I just check lparam against the handle of the control, and all
is good.
You shouldn't be checking lparam against a control handle. You should be checking
LOWORD(wParam) against the control ID
*****
****
Thanks again. You got me in the right direction. I plan to finish up
this little app this
evening, and then move onto figuring out how windows handles sockets.
Shouldn't
be a whole lot different from BSD sockets. Is there a windows
networking newsgroup?
Yes. Raw socket programming is an exercise in pain and suffering, both in BSD/Unix/linux
and in Windows. I try to avoid ever going near it. I live in a world in which
CAsyncSocket does everything I need. Key in Windows is that the select vector is no
longer a bitmap, but an array of handles to sockets. Otherwise, it is simply every bit as
miserable as BSD was.
joe
*****
.
- References:
- Re: edit box population in a dialog box
- From: bwaichu@xxxxxxxxx
- Re: edit box population in a dialog box
- From: Joseph M . Newcomer
- Re: edit box population in a dialog box
- From: bwaichu@xxxxxxxxx
- Re: edit box population in a dialog box
- Prev by Date: Re: edit box population in a dialog box
- Next by Date: Re: Create multiple page EMF files???
- Previous by thread: Re: edit box population in a dialog box
- Next by thread: Create multiple page EMF files???
- Index(es):
Relevant Pages
|
