Capturing Text in an Edit Control

[Mike M]

Hello,

I'm a novice Win32 GUI programmer, so please forgive if my question is too
silly.

A vendor my company works with, provides a "server" component which is
nothing more then their GUI application in server mode. The majority of the
time processes is pounding my sql server db with nonsense log messages.
Unfortunately, my configuration options are limited. Either I log the
diagnostics to the db and/or the GUI edit control. The edit control only
keeps a short history before the contents scroll away and are gone for good
however by enabling the db persistence at least we have a record of the
errors. Even more disappointing is that the level of log is very
weak...basically all records are written to the db and the edit control or
just to the edit control.

Why bore you with this? Basically the idea floating around is if we disable
the db persistence can we "hook" into the edit control, capture the text in
the control then dump the contents to a log file. Hooking into the edit
control is where I'm having some trouble.

Conceptually, I think I can use FindWindow to retrieve a handle to the
control. The I believe I needed to use SetProp to inject my callback handle
into the controls message loop? If that is successful, then I should receive
each windows message. How do I extract the text contents? I've been logging
the activity in the window using Spy++ however I never see any EM_* messages.
All I see are WM_PAINT, WM_ERASEBKGND, WM_SETREDRAW messages. I don't
understand where to find the data buffer in these messages?

Any help would be appreciated...

Cheers,
Mike

[r***@pen_fact.com]

On Wed, 8 Aug 2007 12:46:04 -0700, Mike M <Mike

Post by Mike M
Hello,
I'm a novice Win32 GUI programmer, so please forgive if my question is too
silly.
A vendor my company works with, provides a "server" component which is
nothing more then their GUI application in server mode. The majority of the
time processes is pounding my sql server db with nonsense log messages.
Unfortunately, my configuration options are limited. Either I log the
diagnostics to the db and/or the GUI edit control. The edit control only
keeps a short history before the contents scroll away and are gone for good
however by enabling the db persistence at least we have a record of the
errors. Even more disappointing is that the level of log is very
weak...basically all records are written to the db and the edit control or
just to the edit control.
Why bore you with this? Basically the idea floating around is if we disable
the db persistence can we "hook" into the edit control, capture the text in
the control then dump the contents to a log file. Hooking into the edit
control is where I'm having some trouble.
Conceptually, I think I can use FindWindow to retrieve a handle to the
control. The I believe I needed to use SetProp to inject my callback handle
into the controls message loop? If that is successful, then I should receive
each windows message. How do I extract the text contents? I've been logging
the activity in the window using Spy++ however I never see any EM_* messages.
All I see are WM_PAINT, WM_ERASEBKGND, WM_SETREDRAW messages. I don't
understand where to find the data buffer in these messages?

Use GetWindowText to retrieve the content.

Post by Mike M
Any help would be appreciated...
Cheers,
Mike

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

[Gary Chanson]

Post by Mike M
Hello,
I'm a novice Win32 GUI programmer, so please forgive if my question is too
silly.
A vendor my company works with, provides a "server" component which is
nothing more then their GUI application in server mode. The majority of the
time processes is pounding my sql server db with nonsense log messages.
Unfortunately, my configuration options are limited. Either I log the
diagnostics to the db and/or the GUI edit control. The edit control only
keeps a short history before the contents scroll away and are gone for good
however by enabling the db persistence at least we have a record of the
errors. Even more disappointing is that the level of log is very
weak...basically all records are written to the db and the edit control or
just to the edit control.
Why bore you with this? Basically the idea floating around is if we disable
the db persistence can we "hook" into the edit control, capture the text in
the control then dump the contents to a log file. Hooking into the edit
control is where I'm having some trouble.
Conceptually, I think I can use FindWindow to retrieve a handle to the
control. The I believe I needed to use SetProp to inject my callback handle
into the controls message loop? If that is successful, then I should receive
each windows message. How do I extract the text contents? I've been logging
the activity in the window using Spy++ however I never see any EM_* messages.
All I see are WM_PAINT, WM_ERASEBKGND, WM_SETREDRAW messages. I don't
understand where to find the data buffer in these messages?

All you need to do is to send a WM_GETTEXT message to the control to
retrieve its current contents. Before that, you can send a WM_GETTEXTLENGTH
message to find out how large the buffer needs to be. Since the target edit
control is owned by another process, you can't rely on GetWindowText (it may
work in some cases but will not work reliably).

[Mike M]

Cool, thank you both for the responses...

I would prefer not to poll the edit control with WM_GETTEXT queries...what
message event should I trigger the WM_GETTEXT query? Are there any race
conditions I should be mindful of?

Thanks,
Mike

[David Liebtag]

You want to watch for the EN_CHANGE notification. The edit control
notifications are documented here:

http://msdn2.microsoft.com/en-us/library/bb530930.aspx

David Liebtag

[Mike M]

Well that kinda goes back to my original post...I never see any of the EN_*
messages when viewing activity via Spy++.

Thanks for all the help.

Cheers,
Mike

[r***@pen_fact.com]

On Thu, 9 Aug 2007 10:50:05 -0700, Mike M <Mike

Post by Mike M
Well that kinda goes back to my original post...I never see any of the EN_*
messages when viewing activity via Spy++.

Are you monitoring activity in the edit box or its parent? I'm pretty
sure the EN_ messages are notifications sent by a controls to their
parents.

Post by Mike M
Thanks for all the help.
Cheers,
Mike

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

[Mike M]

Just to be sure I re-ran the test...the only thing I disabled in Spy++ were
the mouse and keyboard events. I didn't see the EN_* messages...I'm sure I'm
doing something wrong.

Unfortuately, my current problem with the program is not the notification
trigger because the preceding step of subclassing the external control in my
program is failing. When I try to subclass the edit control in the vendor's
GUI using SetWindowLong, this fn fails with an access denied error. I've
seen samples using the combination of SetProp and SetWindowLong to accomplish
this task of subclassing process A controls in process B. Guess I'm not
fully understanding the mechanics of this method.

Any help would be appreciated.

Thanks,
Mike

[Ivo Beltchev]

EN_CHANGE is not a message. It is sent using the WM_COMMAND message from the child to its parent.

Ivo

Post by Mike M
Just to be sure I re-ran the test...the only thing I disabled in Spy++ were
the mouse and keyboard events. I didn't see the EN_* messages...I'm sure I'm
doing something wrong.
Unfortuately, my current problem with the program is not the notification
trigger because the preceding step of subclassing the external control in my
program is failing. When I try to subclass the edit control in the vendor's
GUI using SetWindowLong, this fn fails with an access denied error. I've
seen samples using the combination of SetProp and SetWindowLong to accomplish
this task of subclassing process A controls in process B. Guess I'm not
fully understanding the mechanics of this method.
Any help would be appreciated.
Thanks,
Mike

[Gary Chanson]

Set Spy++ to show all messages to the process. I expect you're capturing
messages for the wrong window. The EN_xxx messages will be sent to the parent
of the edit control.
--
- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools

Post by Mike M
Just to be sure I re-ran the test...the only thing I disabled in Spy++ were
the mouse and keyboard events. I didn't see the EN_* messages...I'm sure I'm
doing something wrong.
Unfortuately, my current problem with the program is not the notification
trigger because the preceding step of subclassing the external control in my
program is failing. When I try to subclass the edit control in the vendor's
GUI using SetWindowLong, this fn fails with an access denied error. I've
seen samples using the combination of SetProp and SetWindowLong to accomplish
this task of subclassing process A controls in process B. Guess I'm not
fully understanding the mechanics of this method.
Any help would be appreciated.
Thanks,
Mike

[MIke M]

Post by Gary Chanson
Set Spy++ to show all messages to the process. I expect you're capturing
messages for the wrong window. The EN_xxx messages will be sent to the parent
of the edit control.
--
- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools

Ah, that's most likely my problem...I'm not to target the parent control.
Thanks, I'll give it a try.

Cheers,
Mike