Re: Notification when a window is subclassed

From:

Ranjit <ranjitiyer@gmail.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Tue, 8 Apr 2008 12:21:46 -0700 (PDT)

Message-ID:

<879306cb-f1ca-4b00-a489-5a51e09f5c8f@m44g2000hsc.googlegroups.com>

Thanks Joseph and Ajay,

I did finally realize that I might be trying to solve a problem that
isn't cause by me after all. Every subclasser must remember the
previous subclasser and pass the messages down (or up?). I did confirm
that the subclasser (after me) is some code in the ActiveX control and
not in Java.

Now, it could be the case that the ActiveX control is holding on to
the original WndProc address very early on even before I get a chance
to subclass it and is then using that old value later on when it
subclasses again. So the control isn't accounting for the fact that
there could be multiple subclassers other than itself. My code is
agnostic of it's position in the order of subclassers; it just needs
to receive the msgs.

I have been treating the control as a third-party component for the
purposes of this discussion but the good part is that the code is
available; it's just owned by a different team within the company. So
I'll look through the code and see what's going on therein.

Thanks for all your help. I'll summarize the issue if I find a
solution or ask more questions if I need further advise.

Ranjit

On Apr 8, 12:01 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:

Java has a single window, on which it paints all the images that look like buttons, etc.,
so it does not Play Well With Others in this regard.

On Tue, 8 Apr 2008 11:37:34 -0700 (PDT), Ranjit <ranjiti...@gmail.com> wrote:

Thanks for your responses. For starters, all of this subclassing
activity is happening within the *same* application. Secondly, am
constrained to using the raw Win32 API.

Before I provide code details, here's rougly what am trying to
achieve. I have a Java UI application that hosts a few third-party COM/
ActiveX controls in it. One of the challenges of this integration is
Focus Management. Java's focus manager is unaware of these COM objects
sitting on it's canvas and hence doesn't account for them in it's
implementation of focus management. This results in two problems:

1. An ActiveX control that currently has the focus (by clicking on it)
does not get it back when the application regains focus, say when the
user switches away and then switches back on to app.
2. Focus does not cycle (using the Tab and Shift-tab keys) seamlessly
between Java UI elements and the ActiveX controls.

To fix these focus related problems am writing some bridging code that
works with Java's focus manager to make it aware of the ActiveX
controls hosted on it's canvas. For the implementation to work I need
to know when the ActiveX control gained focus (WM_SETFOCUS) and when
it receives the Tab and Shift-Tab key events (WM_KEYDOWN).

So when the application is being realized I create the control and
then subclass it by supplying my own window procedure. For events that
don't interest me I forward them to the OriginalWndProc.

/* Subclassing code */

// Get the Hwnd of the control from the Control host.
HWND controlWindow = GetWindow(atlAxWin, GW_CHILD);
// Subclass the Window
WNDPROC controlWndProc = (WNDPROC)SetWindowLong(controlWindow,
GWL_WNDPROC, (LONG)SubclassProc);

****
LONG is incorrect here. It should be something like
        WNDPROC controlWndProc = (WNDPROC)::SetWindowLongPtr(controlWindow,
                        GWLP_WNDPROC,
                        (LONG_PTR)SubclassProc);
****

// Remember the original WndProc
BOOL res = SetProp(controlWindow,
_T("OcxFocusMgr_ControlOrigWndProc"), (HANDLE)controlWndProc);

/* My WndProc */

LRESULT CALLBACK SubclassProc(HWND hwnd, UINT message, WPARAM wparam,
LPARAM lparam)
{
HANDLE origWndProc = GetProp(hwnd,
L"OcxFocusMgr_ControlOrigWndProc");

switch(message)
{
case WM_SETFOCUS:
   {
     LRESULT result = CallWindowProc((WNDPROC)origWndProc, hwnd,
message, wparam, lparam);
           // Do something.
     return result;
   }
   break;
case WM_KEYDOWN:
   if(wparam == VK_TAB)
   {
     LRESULT result = CallWindowProc((WNDPROC)origWndProc, hwnd,
message, wparam, lparam);

     if(GetKeyState(VK_SHIFT) < 0) // Shift-Tab
       // Do something
     else
       // Do something else
     return result;
   }
   break;
}
return CallWindowProc((WNDPROC)origWndProc, hwnd, message, wparam,
lparam);

****
This looks like perfectly fine code.
****>}

This works fine until the time that the control tries to internally
load a particular file at which time it again subclasses this very
window that I originally subclassed. The sad part is I can't know when
it does that - it could be a result of an explicit UI operation or a
side-effect of something else. As a result I stop receiving the events
that am interested in which causes my focus mgt solution to stop
working.

****
Who subclasses it? For what reason? Have you looked at the GWLP_WNDPROC value? This may
be indicative of who is subclassing it, for example.

Note that whomever is subclassing it has failed to properly call the superclass (which is
you)

But there is no way to find out who is subclassing it. It could be that Java is
gratuitously re-subclassing it to its own code, but if properly done, this should not pose
a problem. Your code looks correct.
****

I hope I was able to clearly explain what am trying to get at. Based
on this I would appreciate any suggestions you may have.

Ranjit
P.S - I will research PreSubClassWindow in the meanwhile.

****
This won't help what you are trying to do. Your approach appears to be correct. But
someone else is doing you in.
****

On Apr 8, 10:23 am, Joseph M. Newcomer <newco...@flounder.com> wrote:

This is a very vague question. For example, you can't "subclass" the window of another
application; you can only subclass windows in your *own* application. There is a
PreSubclassWindow event that is called for your subclass before the subclassing actually
occurs.

But there are two kinds of subclassing: the MFC style of subclassing and the classic
"Windows API" subclassing. There is NO possibility of "notification" of the second kind
of subclassing.

When you subclass a window at the API level, it is your responsibility to maintain the
original function pointer and CallWindowProc on that function if you don't process the
message. If you are using MFC subclassing, you just call the superclass method.

You can use hooks to intercept messages going to a window in another application, but that
is not consistent with the description you have given below.

You will need to illustrate this with some code.
joe

On Tue, 8 Apr 2008 09:43:28 -0700 (PDT), Ranjit <ranjiti...@gmail.com> wrote:

Is there a way for an application to be notified when one of it's
windows is being subclassed?

The scenario am dealing with is that I subclass a window to take a
crack at a few messages. But the implementation of one of the messages
that am not interested in and hence destined for the OriginalWndProc
is seeming to subclass the Window once again. I am kinda lost at this
point, because neither am I getting those select messages anymore nor
am I being notified that the Window was further subclassed after I
did.

Any suggestions?
Ranjit

Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm