OK, so I have a program-frame on color and one on black and white

[pan@ATHENA.PANGARO.dialnet.symbolics.com (Paul Pangaro)]

... and even though they are different flavors of frame, because they
have different purposes, I want the user to see the same command line at
the top. One way (the way I worked my way into) is to define the
commands by define-cp-command, and then use
dw::define-standard-menu-accelerator to map them into the two frames.
Maybe command inheritance would have been better, I dont know, but here
we are: I get one definition for both instances of menu commands, so far
so good.  The user sees the same thing everywhere, it is easier to
learn, more uniform, etc.

What happens if a command has to run a function that results in actions
on the *other* frame, and then you want the mouse to remain on that
other frame and that frame to be in control ("selected"?). Consider, for
example, if the result of the menu command on frame A is that the mouse
moves to frame B, I do a few things there, hit a few mouseable objects,
etc. --- Where is this all "happening"? In the process of frame A, of
course. Still ok, because, after various machinations of switching the
mouse, selecting the new frame, etc. this works *EXCEPT* I end up having to
*reset* the original frame in order get back mouse sensitivity for menu
items on frame B.

Back in the days before bound documentation for Release 4.2 and 5.1, one
did something rather elaborate, only to discover that one's approach was
arcance compared to the idiom that was in the minds of the developers.
Whether the above configuration was in the minds of anyone or not, any
advice on how to make this more clean.... (Let's see, which frame was I
on? Am I on the same frame? NO --- OK, let's reset everything. Do I need
to move the mouse too? OK, fine. Wait, this time that function is being
called by the same frame that the resulting activity appears on ......)

Many thanks.