IE programmatic resize/scrollbar problem

[prstm]

From within my BHO, I'm trying to display a window above the HTML display but below the toolbars (much like the info bar in XP SP2).

And in fact, I can: I've subclassed the Shell Doc ObjView window, and created a child window of that. However, when I resize the Internet Explorer Server window (MoveWindow), it doesn't seem to recognize this. Although Spy++ says the IES window is the correct size, its display and scrollbars don't change. Visually, it looks like the bottom 30 pixels (the height of my new window) are tucked down behind the status bar. Frankly, it's absurd that the HTML control doesn't pay attention to resizes.

It almost seems like I need to access functionality of the Shell DocObjView window to manage its children, but despite much searching and googling, I haven't found any mention of this.

Anyone have any ideas or pointers?

tia

[Bond]

So you're using MoveWindow() to resize/reposition the IE window? Have you tried any other functions, like SetWindowPos()? I know I've had some nasty experiences using MoveWindow in the past.

Also, what about invalidating? Are you attempting to redraw your window, or its parent?

[prstm]

Yes, I've used SetWindowPos, too, and each time I've asked it to repaint.

IE will even browse in this state.

[hankdane]

You say you subclassed the Shell Doc View window. Are you sure you are not filtering any critical messages out?

[prstm]

As sure as I can be. I'm only intercepting two messages, WM_WINDOWPOSCHANGING and WM_TIMER, and in each case I'm calling DefWindowProc.

[hankdane]

Don't call DefWindowProc. Call the original Window procedure for that window. WM_WINDOWPOSCHANGING could very well be the missing link.

[prstm]

But if I've used CWindowImpl<CMyWin>::Subclass, doesn't DefWindowProc() call the original window proc? I've used it that way in other situations for months, and it sure seems like that's what it does.

Either that, or I've been severely confused, and extremely lucky...

[hankdane]

I'm not familiar with CWindowImpl<>, but the documentation suggests you are right. I thought you meant ::DefWindowProc(), which would definitely have been a problem.

It still sounds a little fishy: you subclass for WM_WINDOWPOSCHANGING, which sounds exactly like that is what the Shell Doc window is missing.

However, it's also possible that the MoveWindow() call is ignored by the IE window. I have had similar problems before: a window will refuse to be resized programmatically. You can check for this situation by getting the size of the window after calling MoveWindow(). The solution for me has been to either resize a parent window (probably won't work for you), or using a COM interface to send a command instead.

Have you implemented IDeskBand?

[prstm]

Spy++ definitely says the HTML window is the size I set it to, but the scroll bars don't seem to know it.

Yeah, it's looking like those wacky folks in Redmond have an undocumented COM or other backdoor interface into the control while it's hosted in IE, because the scrollbars work perfectly if I host the control in my own app.

I might go the route of IDeskBand if I have to; I'm thinking that trying to manipulate the child windows of the Shell Doc View might be sorta, well, impolite anyway.

[hankdane]

I think either "Tool Band" or "Explorer Band" is the official route to do what you're trying. The following article may be helpful:

http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/bands.asp

I realized after my last entry that my problems with MoveWindow() has been mostly on PocketPC.

[prstm]

Oh, yeah, I know about toolbands; I was hoping to do something a little slicker.

Thanks for your comments, though.