Board index » delphi » Wacky EM_SETSEL Problem

Wacky EM_SETSEL Problem

It's me again! This's got to be the weirdest of the weird things I've
seen in a long time.

I've got some code that does this:
  Form1.dbEdit1.SetFocus;
  PostMessage(Form1.dbEdit1.Handle, EM_SETSEL, 0, -1);

(1) When returning focus to Form1 after having focus on another form.
(2) Upon arriving on a new record displayed on Form1.

Summary: It doesn't always work.

Details:
This has been working fine for over a year, but recently I added a new
form, which, unlike all the other forms, is *not* destroyed when the user
leaves. (It is an fsNormal form, unlike the other forms, which are all
fsMDIChild forms. It is hidden when the user leaves it.)  

For one of around 2 dozen users, the field contents are sometimes not
selected after returning to Form1 from the fsNormal form; *but* his
cursor is in the control, and Form1 has focus.   When he starts up the
system, behavior is normal, but after the first time that the EM_SETSEL
fails to work, it doesn't work again until he exits and restarts the app.

It happens whether we compile the app in D2 or D3.02. His h/w & s/w
configuration and network logins are the same as everyone else, but we
tried giving him a new pc just in case. Didn't help any.

We recorded his keystrokes but can't reproduce the problem on any other
machines.  One other user did manage to reproduce the problem twice, but
doens't know what he did, and can't seem to do it again.

One last thing: This fsNormal form replaces a call to InputQuery. When we
were using InputQuery this problem didn't exist.

Ideas, anyone?

 

Re:Wacky EM_SETSEL Problem


As I'm sure you know, the Rich Edit control is far from stable.  A couple of
thoughts (or perhaps questions...).  What is the operating system Win 95 or
NT?  If it is NT, would suggest installing Service Pack 3.  Has IE 4.xx been
installed on the system?  If so, there are some very bizarre problems that
can occur with visual controls, and in particular with the Windows desktop.
The only other thought is that this sounds like a resource that may not be
freed properly.  Hope this helps a little..

Martin

Quote
Maggie Owens wrote in message ...
>It's me again! This's got to be the weirdest of the weird things I've
>seen in a long time.

>I've got some code that does this:
>  Form1.dbEdit1.SetFocus;
>  PostMessage(Form1.dbEdit1.Handle, EM_SETSEL, 0, -1);

>(1) When returning focus to Form1 after having focus on another form.
>(2) Upon arriving on a new record displayed on Form1.

>Summary: It doesn't always work.

>Ideas, anyone?

Re:Wacky EM_SETSEL Problem


Martin Vernon wrote

Quote
>As I'm sure you know, the Rich Edit control is far from stable.

A DbEdit, which is what Maggie appears to be using, isn't a Rich Edit.

Quote

>Maggie Owens wrote in message ...
>>It's me again! This's got to be the weirdest of the weird things I've
>>seen in a long time.

>>I've got some code that does this:
>>  Form1.dbEdit1.SetFocus;
>>  PostMessage(Form1.dbEdit1.Handle, EM_SETSEL, 0, -1);

>>(1) When returning focus to Form1 after having focus on another form.
>>(2) Upon arriving on a new record displayed on Form1.

>>Summary: It doesn't always work.

>>Ideas, anyone?

Maggie, can I ask why you are using PostMessage? I'd have thought
SendMessage would be more appropriate in this context. If you use Post, you
are opening up the possibility of "something else" happening  before your
edit gets the message. If this something involves focus changes, there's a
chance your EM_SETSEL won't work. (old Windows programmer joke: "focus" is
actually a contraction). You could also try:

dbEdit1.SelStart := 0;
dbEdit1.SelLength := length( dbEdit1.Text );

NeilB

neil_butterwo...@compuserve.com
 http://ourworld.compuserve.com/homepages/neil_butterworth

Re:Wacky EM_SETSEL Problem


The control being used may not be a rich edit, but the message that is being
sent to the control is indeed an Edit Message that is used by and directly
affected by the Rich Edit control support functions.  Rich Edit messages are
prefixed with EM_ and a few are EN_ or ES_.  You may refer to the Waite
Group's API Bible for more specific information.

The point of my response to the author was not to provide a definitive
answer, but merely to do as she suggested and give some possible areas to
look into.

By the way, your comment regarding the use of SendMessage as opposed to
PostMessage appears on the surface to be a good one.

Quote
Neil Butterworth <101565.2...@compuserve.com> wrote in message

<69fg5s$b...@forums.borland.com>...
Quote
>Martin Vernon wrote

>>As I'm sure you know, the Rich Edit control is far from stable.

>A DbEdit, which is what Maggie appears to be using, isn't a Rich Edit.

Re:Wacky EM_SETSEL Problem


Martin Vernon wrote

Quote
>The control being used may not be a rich edit, but the message that is
being
>sent to the control is indeed an Edit Message that is used by and directly
>affected by the Rich Edit control support functions.

No it isn't. Messages affect things, they are not affected _by_ things. If
the control the message is being sent to is not a Rich edit, then Rich edits
are completely out of the picture.

Quote
>Rich Edit messages are prefixed with EM_ and a few are EN_ or ES_.

True, but so are the messages for "non-rich" edit controls.  EM_ messages
have been in Windows since at least Windows 3.0, while Rich edits came in
with 32-bit. Rich edits simply re-use some existing messages, and add a few
of their own. EM_SETSEL has always been available for use with the original
edit control.

Quote
>You may refer to the Waite Group's API Bible for more specific information.

Gee thanks. Actually, I've been programming Windows at the API level since
before Windows 3.0 appeared, so I do know what the EM_ messages do! Also, I
tend to use primary sources (like Microsoft's API documentation) to support
my views.

NeilB

neil_butterwo...@compuserve.com
 http://ourworld.compuserve.com/homepages/neil_butterworth

Other Threads