TimoSoft-Software.de

I have a strange bug for you...I tried to find a workaround for hours....

Run the attached form. It puts your WindowlessLabel inside a picturebox then draws directly on the picturebox. A black line appears on top of the picturebox and the picturebox moves down one pixel. If I remove the WindowlessLabel, the picturebox draws fine. So somehow the label control is affecting its container.

I also saw this effect on another Container control so it affects other container controls besides the PictureBox, but other label controls work fine.

Any ideas or workarounds?

This seems to be related to the usage of the AutoRedraw feature. So far I've no idea what is causing the black line. If I comment out all the drawing code of the WindowlessLabel control, the problem is still there. If I comment out the line drawing in the sample, the problem vanishes.
As a workaround you may move the drawing code to the PictureBox' Paint event - without the AutoRedraw stuff of course.

Regards
TiKu

Well I simplified it for you by using a PictureBox, but the original bug I found was in another Container which I don't have 100% control over. I don't think I can change the AutoRedraw call unless I switch to another container and make my own control. Plus, doesn't AutoRedraw help with constant redraws and flickering by making it persistent? The graphics I need will not be simple so I'm not sure this workaround can help. I will experiment.

If you can think of anything else, I would appreciate it. What bothers me is that the VB Label which is also windowless doesn't have this effect so it doesn't seem to be a bug in the Containers logically.

The VB Label control is special in that it isn't a real COM/ActiveX control.
I didn't say it's a bug in the container. But windowless controls interact heavily with their containers, so you never know. I remember drawing bugs in this control that turned out to be partly caused by the container and partly by the control itself.

Unfortunately the workaround doesn't work. It causes flicker with complex graphics, but worse than that: There seems to be another bug where the Windowless label removes all of the graphics from its Container drawn without Autoredraw. As soon as I remove the label, the graphics come back. You can see the effect in the attached project (notice the X no longer appears in the Container).

If I can't place the label in a Container with graphics that means i can't use the label inside ANY custom container control such as a third-party tab or frame component. This is obviously a critical issue.

I don't mean to bug you, I just need to know if you think there is a chance of a fix or workaround for this. I need to know whether to seek alternatives so I can move forward with the project.

Thanks.

I'm still investigating this problem. However, I'm doing this in my spare time and currently I don't have much of it. So it's unlikey that I'll find a solution within the next week. Sorry.

I appreciate the work and need for spare time. I'll wait as long as I can (probably a week or so). There are alternatives but the ones I saw aren't very good with GDI/User handles.

It seems to be an ATL specific problem. ATL is the C++ library that I use in my controls. A small test control that uses MFC instead of ATL doesn't have this problem. However, switching to MFC would require a complete rewrite. Also I prefer ATL because it is much more lightweight and doesn't pull in external dependencies.
I'll try to find out what ATL is doing differently than MFC in respect of drawing.

Not my area sorry, but did you try commenting out ALL of your code in the control just to see if an empty ATL control produces the same result? Perhaps a process of elimination...

I did something similar: I created a new "empty" ATL ActiveX control.
I also am a step further: I know which part of the code is causing it. It's a return value of a special method. And it's not a ATL problem, I can reproduce it with MFC, if I implement this special method like in ATL. The only problem is that background transparency won't work anymore if I implement this special method like it should be implemented. So now I'm looking for a way to provide transparency while still implementing this special method correctly.

I think I've found a solution. I cannot say that I like it very much though... It requires the container control to have a Refresh method.

www.timosoft-software.de/stuff/lblctls10468-rel.zip
www.timosoft-software.de/stuff/LblCtls10468-Release.exe

Regards
TiKu

Impressive. I think it works even better than you said because I used it in a control without a public Refresh method and it works there now as well. Unless it is using some kind of internal VB refresh or I misunderstood you. In any case, I retested in all the problematic scenarios i previously found and they work perfectly so far. I even tested GDI/User objects and they look great too. I tested in WinXp and Win7.

Thank you! I'm trying to arrange a small donation in appreciation.

Thank you. I've just released new versions of the ButtonControls, EditControls and LabelControls libraries.

The new label control seems to be calling all the public Refresh functions on my controls and forms now. The trouble is, I use these Refresh functions for other purposes besides painting. Is there any way to switch this behaviour off?

For now I changed the functions to Friend instead of Public and that seemed to work but you should know that this may cause very unexpected behaviour since other people may use an existing Refresh method for purposes other than what you had in mind.