If you have more than one window showing, say FormA and Form B, how can you make one rather than the other active under program control (as you can manually with mouse clicks)?
If you mouse click on such a window, say FormA the previously active window (say FormB) receives the deactive event and the window you click, FormA get the active event. (Now if FormA has its own menu, then that menu will appear.)
The obvious solution you would expect would be to use vpi::winPostEvent to send the e_active event for FormA. Sadly that is forbidden and so the following (superficially plausible code fragment) gives a run time error:
%The menu of FormA is only visible when FormA is active
%and we want it to show! So:
%set em up:
Window=FormA,
WindowHandle = Window:getVPIWindow(),
Event= vpiDomains::e_Activate,
%ready to rock! so go for it!:-
vpi::winPostEvent (WindowHandle, Event) ,
%RATS! the following line cuase a runtime error: the e_Activate event is proscribe with vpi::winPostEvent (its actually documented thus)
so how CAN you activate a given Windows, (FormA in the above example) (just as though you had mouse clicked it?)
- Thomas Linder Puls
- VIP Member
- Posts: 1431
- Joined: 28 Feb 2000 0:01
e_activate is not an event that can be sent to a window to activate it, it is an event the window receives to be informed that it has been activated.
To achieve the desired effect you must put focus to the form:
To achieve the desired effect you must put focus to the form:
Code: Select all
FormA:setFocus()
Regards Thomas Linder Puls
PDC
PDC
- Richard Clarke
- Posts: 13
- Joined: 15 Mar 2012 15:55
Thanks, that works.
Believe it or not, setting focus was the first thing that occured to me. Sadly I used vpi::winSetFocus
instead of setfocus(), as in:-
Window=FormA,
WindowHandle = Window:getVPIWindow(),
vpi::winSetFocus (WindowHandle) ,
This, for some reason, does not have the desired effect (which is acheived by
FormA : setFocus(). Because the FormA's menu did not appear, and because FormA did not "brighten" (as it does when mouse-clicked), I assumed that it was necessary for FormA to be activated in addition to getting focus.
Now it seems that if FormsA gets focus, (resulting from FormA : setFocus() or mouse-clciking,) in addition to getting focus it becomes activated. There must presumably be a difference between having focus and being active (and/or being "on top" ???) but the differences are as clear to me as the proverbial mud.
I am rather curious about what is the point of vpi::winSetFocus (WindowHandle) and what is it suppposed to do that is different from FormA : setFocus().
Believe it or not, setting focus was the first thing that occured to me. Sadly I used vpi::winSetFocus
instead of setfocus(), as in:-
Window=FormA,
WindowHandle = Window:getVPIWindow(),
vpi::winSetFocus (WindowHandle) ,
This, for some reason, does not have the desired effect (which is acheived by
FormA : setFocus(). Because the FormA's menu did not appear, and because FormA did not "brighten" (as it does when mouse-clicked), I assumed that it was necessary for FormA to be activated in addition to getting focus.
Now it seems that if FormsA gets focus, (resulting from FormA : setFocus() or mouse-clciking,) in addition to getting focus it becomes activated. There must presumably be a difference between having focus and being active (and/or being "on top" ???) but the differences are as clear to me as the proverbial mud.
I am rather curious about what is the point of vpi::winSetFocus (WindowHandle) and what is it suppposed to do that is different from FormA : setFocus().
RSC
- Thomas Linder Puls
- VIP Member
- Posts: 1431
- Joined: 28 Feb 2000 0:01
The reason is that a form window is actually two windows, an outer document window which contains the frame and an inner dialog window which holds the "contents" of the form. The window you obtain with getVpiWindow is the inner dialog, but the window that should receive "focus" is the outer document window.
Regards Thomas Linder Puls
PDC
PDC