Click Bug

[baron]

Sorry...found another bug. Hope this isn't a tricky one.

The label control grabs clicks even for controls that are on top of it. Interestingly, it only does it after you click on it. I.e. run the attached, click on the image that is overlapping the label, but do this either after you clicked on the label or after clicking on the form around it.

[TiKu]

This one is tricky. I capture the mouse in order to be able to raise the MouseLeave event. When handling mouse messages, I try to find out whether the cursor is still over the control. I do the following checks:

1. I let the container shrink the label's bounding rectangle to the label's clipping rectangle. The clipping rectangle is the smallest rectangle that still contains all visible parts of the label.
2. I get the mouse position and check whether it is within this rectangle.
3. I use WindowFromPoint to check whether the mouse cursor is still over the label's parent window.

So, why does none of these checks work in your example? Let's have a look again.

1. The Image control does not simply cover the WindowlessLabel control. Instead it extends into the label control. Therefore the label's smallest bounding rectangle contains parts of the Image control. Note that this check does work correctly in cases where the visible parts of the label control form a rectangle.
2. Since the rectangle covers those parts of the Image control that the mouse cursor is over, this check won't help.
3. This would work fine for controls that create their own window. Unfortunately the Image control is windowless as well, so WindowFromPoint will retrieve the Form, which surprisingly also is the label's parent window.

I'm still looking for a solution.

[baron]

Well I found this because I have this specific interface with labels and small icons overlaying the labels so that the users can perform actions related to each 'label'. In other words, in my original case, the icons are completely 'contained' within the label, except they no longer receive click events.

I haven't tried this, but I suppose if all else fails I could replace either the label with a read-only text field, or the images with pictures, but this isn't ideal as they are both heavier controls. I also haven't tested what happens when I place one label ontop/overlapping another label to see which one gets the click events but I presume this issue could cause various unexpected problems like these.

I'm not sure how it works but I would presume that the image control's z-order would send it the click event first. Unless you are grabbing the mouse event away from it somehow...

Is there any way to define the region only according to the parts you painted? I.e. not necessarily a rectangle but to only include the pieces that were painted.

Just my 2 cents which may give ideas...

[TiKu]

Do you need the MouseLeave event? If not, I probably could implement an option that disables MouseLeave in favor of better support for overlapping controls.
As a (very ugly) workaround you could also change your Label_Click events to take the click coordinates and calculate whether this point is within the Image's rectangle and forward the click event.

[baron]

I don't need MouseLeave for now but I or someone else may need it in the future obviously.

I suppose you could add an option to switch between these two modes. It is better than me having to calculate which control is currently sitting over the label as I would have to loop over perhaps a hundred of them and check their regions every time there's a click.

I'm not sure how you implemented MouseLeave, but I've done it in the past by starting a timer on MouseMove and then checking every x ms whether the mouse is still over the control. This didn't require any 'capturing' of click events from other controls, but it's possible that I don't know enough about Windowless controls.

[TiKu]

For windowed controls I've implemented MouseLeave using the TrackMouseEvent function. You obviously cannot use it for windowless controls due to the lack of a window handle, so I decided to capture the mouse instead.
Using a timer wouldn't help in this current scenario as you would still have the same task: Find out whether the mouse cursor is still over the control. As long as the control is rectangular and not covered by any other control, this is simple. But if the visible parts of the control form a complex shape, you're lost.

[TiKu]

I've extended the DisabledEvents property by deMouseEnterHoverLeave (for the WindowlessLabel control only). Now it's possible to have mouse events, without the MouseEnter, MouseHover, MouseLeave events. MouseEnter and MouseHover depend on MouseLeave, that's why the new flag affects them as well.

I hope I did not introduce new bugs.

Edit: I hope you did not yet install this version. I just had an idea for a better solution. I'll implement it tonight or tomorrow.

[TiKu]

This version uses a timer to detect the MouseLeave events:

www.timosoft-software.de/stuff/lblctls10574-rel.zip
www.timosoft-software.de/stuff/LblCtls10574-Release.exe

How did I solve the problem that I don't know the control's complex shape? I store the position of the last mouse move event. In the timer event, I check whether the current position is different than the last known position. If it is, this means that the control didn't receive a mouse move event although the cursor has moved. This can only mean that the cursor is no longer over the control.

[baron]

Very creative solution! Good one.

It almost works perfectly. But I think there is one little bug in the logic left over. I am attaching a sample that demonstrates the problem: This time click on the second label and try the +/- buttons to make it bigger/smaller. You'll see that sometimes when you click on the label itself FIRST, and then try clicking the +/- buttons they don't work. You have to click outside of the label to get the button clicks back.

[TiKu]

Fixed it, thanks for reporting.

www.timosoft-software.de/stuff/lblctls10575-rel.zip
www.timosoft-software.de/stuff/LblCtls10575-Release.exe

[TiKu]

Hi,

Is everything running well? Did you find any new problems?

Regards
TiKu

[baron]

No problems. Been testing and it looks stable. Thanks!

There was a crash in the IDE when I set autosize to -1 instead of 1 by mistake due to the migration, but that isn't your problem.

[TiKu]

Okay, I'm glad to hear this. I'll make this version an official release within the next days.