Windowless Control
Randy
there is anything special I need to do to it to convert the control to
windowless. I've removed all of my PictureBox objects and replaced
them with Image objects and now my PaintPicture function paints onto
the UserControl instead of a PictureBox object. This works if the
UserControl is windowed as long as the BackStyle is set to
opaque(otherwise the initial draw occurs but it doesn't update or
animate). Whenever I change the control to windowless though it stops
showing up entirely inside of IADS. I've run out of ideas at this
point. This isn't critical to make the control windowless since the
windowed version will work, I was just curious since I was playing
with transparency and alpha blending. Ideally I'd like to be able to
make my control windowless so I can alpha blend some of the images
onto the control to allow partial transparency to the underlying IADS
window.
James Bretz
> I've created a windowed ActiveX control in VB6 and I was wondering if
> there is anything special I need to do to it to convert the control to
> windowless. I've removed all of my PictureBox objects and replaced
Could be a problem in my container. I've had issues taking to VB control in
the past.
A quick Google search revealed something interesting:
Open up the VB to open the project properties. Set the control's Windowless
property to True. Also set the BackStyle property to Transparent (looks like
you did this already but you might have missed the Windowless property).
http://support.microsoft.com/kb/184645/EN-US/
Jim
Randy
second when I attempt to drop the control onto the desktop but then
nothing else happens and IADS continues without my control appearing.
James Bretz
>I tried this and it seems to cause IADS to pause and "think" for a
>second when I attempt to drop the control onto the desktop but then
>nothing else happens and IADS continues without my control appearing.
Ok, if you get a chance, zip up your display dll and email it to me (if
possible). When I get some free time I'll step through the container code
and find out what's going on...
Jim
James Bretz
> Ok, if you get a chance, zip up your display dll and email it to me (if
> possible). When I get some free time I'll step through the container code
> and find out what's going on...
Nevermind... Brenda found one of our VB windowless controls that acts the
same way.
I'll put this on on the back burner and let you know later,
Jim
Brenda Rasmussen
Double check that your VB control isn't set to require a license to
run. In VB under the Project Properties, there is a checkbox for the
license. If that is checked, Iads won't be able to run it because it
thinks it needs a license. Uncheck it, recompile your VB control and
try a redrop. Hopefully that is what was going on, if not, reply back
here and we'll keep looking into the problem.
Brenda
>
> - Show quoted text -
Randy
the project and send it to you. It's just me playing around mostly
trying to see what's possible.
James Bretz
>I looked and the license checkbox was unchecked already :(. I'll up
>the project and send it to you. It's just me playing around mostly
>trying to see what's possible.
Thanx for the examples.
Well... I dropped both the "windowed" and the "windowless" version into an
AW and they (both) seem to work exactly the same.
There's some "garbage" initially drawn outside of the bounding area, but
after I attached a parameter to the "Value" property, everything seemed to
clean up nicely. This is most likely due the fact that I'm "denying" the
initialize size request as we've discussed earlier. I think I'll have a fix
for 6.0 that will allow you to negotiate on drop.
Let me emphasize that I didn't get *any* graphics updates (i.e. the display
was black) until I dropped a parameter into the "Value" property. This may
be the heart of the problem. I'm still investigating. My best guess right
now is that the "linkage" between my container and your control on a
"redraw" (i.e. expose) needs some work.... but when I force a property
update down your throat, you in turn call "Refresh" and it all works out in
the wash.
The tape seems a little bit distorted right now but that may be me not
setting a property correctly.
Here's the real kicker: Although "AltitudeTape1" is set for Windowless, it
still uses the picture box to draw into and the picture box _has a window_
(kind defeats the purpose, doesn't it...LOL!). Anyway, I used "Spy" to hover
over your control and found a window called "ThunderRT6UserControlDC", with
is most likely the picture box's "window" that it uses to draw into. I
noticed that my example "dial" has the same issues.
Anyway to draw without a picture box??? Perhaps draw right to the form? If
we can't draw directly to the "form" then we'll be stuck with a window,
Jim
James Bretz
> display
> was black) until I dropped a parameter into the "Value" property. This may
> be the heart of the problem. I'm still investigating. My best guess right
> now is that the "linkage" between my container and your control on a
> "redraw" (i.e. expose) needs some work.... but when I force a property
> update down your throat, you in turn call "Refresh" and it all works out
> in
> the wash.
Ok, I should just go home and lay down now ;) I must be losing my mind. I
do get graphics updates. Everything works fine (with no artifacts) if the
display size is set to it's "native" size.
I think the main obstical right now is that the "picture box" itself has a
window... so we'll have to find some other technique.
Jim
James Bretz
>I've created a windowed ActiveX control in VB6 and I was wondering if
>there is anything special I need to do to it to convert the control to
>windowless.
Sorry it took so long. I'm a little under the weather lately.
Well, you've definitely found a bug in Iads (and a "breaking of the ActiveX
contract" for VB). The windowless controls built in VB6 actually cause Iads
to "exception" (i.e. crash). This exception is caught, but it results in the
display not drawing properly... and possibly other unknown side effects.
It seems that windowless controls built in VB6 have some very strange
characteristics, one of many characteristics that violate the ActiveX
protocol (which leads to the problems):
1) When Iads creates the VB control, it queries for an interface in the
control called "IOleWindow". When it calls the "GetWindow" function, it
expects the *windowless* control to return "failure" or "null". It does not.
From MSDN:
"IOleWindow::GetWindow -> Returns the window handle to one of the windows
participating in in-place activation (frame, document, parent, or in-place
object window). Note: For windowless objects, this method should always fail
and return E_FAIL."
A VB windowless control returns S_OK, and worst of all, it returns the
*container's* HWND. Not good. This is also what sets up the next problem.
2) When Iads gets a windows message event and the windowless control has
"focus", the ActiveX contract dictates that Iads is to pass the message via
a call to the control's IOleInPlaceObjectWindowless::OnWindowMessage
function. When Iads performs this function, the control passes the message
*back* to the container's "WindowProc". This creates a recursive condition
that "exceptions". I have never seen this behavior before in a windowless
control. I suppose this behavior follows because of the what was discovered
in #1 above. Again, not good.
Having said all of this, I have put in measures in our container code to
prevent this recursive issue.... and it seems to be operating ok now. I have
a "working" windowless VB6 control which is running right now in my AW. I
can also lay down other windowless object (text, etc) on top of the control,
so I'm 100% positive it's windowless.
I'll be the first to admit that the problem might stem from the fact that we
don't understand the ActiveX contract completely. There are hundreds of
handshakes and rules that play out between a display and a container... and
none of them are spelled out in a single document. All it takes is one wrong
move ;)
At this point, you should probably avoid building windowless controls in VB
until after the Iads 6.0 release. I may have a solid workaround at that
time. Sorry about all of the problems. It's hard to believe that we've never
had anyone develop a windowless control in VB6 up to this point.
Jim