AnsweredAssumed Answered

vrf 'popping-up' the window, activate & setfocus

Question asked by hansolofalcon on Oct 10, 2003
Hello (again) from Gregg C Levine
Funny you should mention that event.... I was at the one for Thursday,
this week. Your name came up several times. And, so did mine. It seems
that both of us, are fondly remembered by the participants of this
list, that were there. Also the company representatives of the
company, also recognized my name from the list. They did mention what
you've described. All in all, it was a good meeting.
Gregg C Levine
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke." Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )

> -----Original Message-----
> From: Shawn Fessenden []
> Sent: Friday, October 10, 2003 5:05 PM
> To: VEE vrf
> Subject: [vrf] RE: 'popping-up' the window, activate & setfocus
> > Shawn, Are you able to offer more info?
> Yes. SendMessage(hVWnd, WM_SHOWWINDOW, SW_NORMAL, 0) is exactly
> what
> User32.ShowWindow(hVWnd, SW_NORMAL) does. The case for VB is a lot
> simpler -
> we were trying to get VEE back on top with that. There are very few
> calls having to do with window management that don't boil down to
posting or
> sending a message to the target window.
> But anyway, you can use a combination of the WindowState property
and the
> ZOrder method to restore from an icon and bring to top. Focus issues
> also easily handled with the SetFocus method. All of these
properties &
> methods are owned by the Form object.
> The attached VB normalizes itself and brings itself to the top every
> seconds. A counter is incremented at each interval, and if the count
is odd
> focus is set to Text1. If it's even focus is set to Text2. I didn't
> it though - I kind of assumed you have VB installed. Anyway, the
code is
> really simple.
> In the case of VEE, similar operations exist. User32.IsIconic(hWnd)
> TRUE (i.e. a non-zero int) if hWnd is minimized, in which case that
> SendMessage will restore it. It turns out many of the standard
> *won't* "bring VEE to the top" as it were. Um, yes, I was assuming
and I
> made an *** out of myself
> I can't offer any explanation for much of this. All I can assume is
that VEE
> is eating some of these window messages and not doing anything about
> In the case of BringWindowToTop(hWnd) or SendMessage(hWnd,
> SW_NORMAL, 0) I can see the message being received by VEE, but I
don't see a
> subsequent call to DefWindowProc from VEE to user, which it should
do if it
> doesn't process the message. However, the return value from
SendMessage is
> 0, indicating that the message was processed. Something seems to be
> And so I offer the work-around. All you do is send SC_MINIMIZE
followed by
> SC_MAXIMIZE (i.e. SendMessage(hWnd, 0x112, 0xf020, 0),
> 0x112, 0xf030, 0)) and VEE is guaranteed to restore, maximize and be
on top.
> It's not real elegant but it will work.
> This "on-top" stuff is of course relative. The top of the ZOrder
> belongs to what are called "topmost" windows. A non-topmost window
> *never* get on top of a topmost window, no matter what you do.
> "Always on top" option is an example. This option changes the help
window to
> a topmost window with User32.SetWindowPos. The number of
combinations of
> possible scenarios is staggering. Most important is the
> extended window-style bit (set or reset with SetWindowPos). Next
> important is the activation state of the window. Then the number of
> non-minimized windows. It's no wonder it's a confusing subject -
what works
> in one situation doesn't work in another and so on.
> All in all, SetWindowPos is master of all. This function can do just
> anything with window ZOrder, size & position. It's also a better way
> redraw windows, alluding to the SysMenu example. I used
> WM_NCPAINT, 1, 0) to redraw the window frame after removing the
> style bit. This is kind of a short-cut from the old days that used
to be
> used to speed up redrawing. This really ought to be done by calling
> SetWindowPos(hWnd, 0, 0, 0, 0, 0, SWP_NOMOVE + SWP_NOSIZE +
> Finally, focus. Setting focus to a VEE object (like a constant or
> used as an input field) is *extraordinarily* difficult from a
> programmatic viewpoint. The concept of input focus is bound to the
> of a window handle. Now, it's not difficult to get a window handle
for a VEE
> object, but (in VEE 5 anyway) VEE objects are composed of several
> windows of class VEE_CHILD bounded with a window of class
> The
> key point is that VEE component windows do not use the Windows
> manager to store what they contain. IOW, If I plop down a real
constant and
> type .1234 in it, there is no window listed in the window manager
> contains a title of ".1234" so a call to FindWindow won't find it. I
have no
> way to get the window handle, so I can't set focus to that window.
> There is a way to find particular Windows windows that represent the
> important components of particular VEE objects, but it involves
> around in VEE's memory and WAGs (Wild *** Guesses) about VEE's
> memory structures and how VEE works. The Subclass example of years
gone by
> demonstrated how to subclass a Confirm Button object in VEE 5 to
change it's
> text, font & color programmatically.
> We learned at VEE Days that VEE is moving more and more toward
> and indeed version 4 didn't even use Windows' window manager for the
> application workspace at all, so things have gotten better. In
> we learned that the central "meat" window of VEE objects is moving
to a
> regular Win32 standard control. This will be nice for the little
> like being able to hold down the Shift key and highlight as the
> moves - but it will also be a boon for this particular problem. It's
> to be a standard control, probably an edit or a rich edit control I
> think, so if it's a single line (as in the case of an input field on
a form)
> it's contents will be it's "WINDOWTEXT", and FindWindow will be able
to find
> it.
> Of course you can use all kinds of goofy jazz to set the focus.
Probably the
> most popular is using SendKeys to send a function key to a bogus
> then sending tabs from there to get you to the input field you want.
> that of course implies using script host automation or the script
> and that comes with it's own difficulties. Not to mention that this
> really the most reliable way to drive a program, even if it is the
> universal.
> I think it's a lot easier to use a masked edit control, or to wrap a
VB text
> box in a VB UserControl and use that in VEE as an input field for a
> lighter-weight solution. These controls have an hWnd property so
setting the
> focus to them is no problem. You can also supply nice touches, like
> automatically highlighting whatever is in the control so the user
> have to double click to start typing a replacement. And there's all
kinds of
> events you can catch for on-the-fly input validation too.
> Put it this way: out of all the requests you get for features (from
users of
> the system, not from the designers or salespeople), how many relate
to the
> actual purpose of the test system in the first place? Now, how many
> to the user interface? We also learned at VEE Days that VEE 7 has a
lot of
> UI design features that are going to make that particular job a lot

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".