Issue: Overlapping Click Boxes

[CyrDaan]

I have overlapping images that is shown below but it seems as though the images when clicked on the right most side of the > near the point will actually active the image on the right as opposed to the one my cursor is over.



I believe the issue is the image boxes. How can I make it so when I click on the tip of the > it will activate the correct image instead of the one next to it?

I appreciate your time in helping me with this issue.

[MerlinTheRed]

This topic deals with almost the same problem and suggests a solution you might use as well:

http://rainmeter.net/forum/viewtopic.php?f=5&t=14062

[CyrDaan]

This deals with MouseOver and MouseHover, I do wonder if it will work with clicking as well, I will look into this more to see if it will work, in the mean time I'm still open to suggestions.

[Eastwood]

This topic deals with almost the same problem and suggests a solution you might use as well:

http://rainmeter.net/forum/viewtopic.php?f=5&t=14062

CyrDaan, the conclusion of the other topic is that:
- You can solve your issue by placing your buttons in different configs (aka, skins). That way, RainMeter will be able to achieve your desired behavior.
This means expanding your skin tree with allot of short button dedicated skins.
- Mouseoveraction, mouseleftupaction, mouseleftdownaction... etc, they all deal with the same glitch, stated in the manual:

Mouse actions are action options used on any visible part of the skin. The action is triggered by specific mouse events.
Usage
On any meter. The target area detected by the mouse will be any non-tranparent areas of the meter, or any part of the meter which has a non-transparent meter or skin background behind it.

http://docs.rainmeter.net/manual/mouse-actions

I'm not sure if there will be changes on this glitchy, and mostly unwanted behavior in future versions of rainmeter.
Unless there are more advantages than disadvantages on the current way of handling mouse actions?
I'm not sure, as I never found an advantage upon this day...

[moshi]

the solution seems a little complicated for such a simple task.

why not just using button meters instead of image meters?

[jsmorley]

We are in fact exploring ways to address this issue. There are in fact both programmatic and functional reasons that it has always worked this way.

First, (and not to get too deep into the weeds) meters are "drawn" on the skin in the order that they are encountered in the .ini file, and so when a mouse (hover, click) event is detected on a pixel on the screen, Rainmeter really has no way today to know which meter "owns" that non-transparent pixel. So the mouse actions are fired on all meters whose boundaries include that pixel. There are no "layers" in Rainmeter, and thus no way for it to say "ah that pixel is solid because of [MeterTwo]".

Second, the behavior that mouse actions on a meter that is logically "behind" another are detected and acted upon is actually very desirable in many cases. It is a common use to have a background meter behind a meter, to make clicking on a meter with a lot of transparent areas (an icon image or some text string) much easier. We are going to be very careful not to change this behavior and break hundreds of existing skins in any effort to provide more flexibility in how this works.

Stay tuned as we explore this issue. It may take a little time, as we want to be sure we make a change that adds the right functionality, while protecting the community's rich ecosystem of existing skins. To be honest it is not our number one priority just now either, but we won't forget it.

[Eastwood]

the solution seems a little complicated for such a simple task.

why not just using button meters instead of image meters?

I have tried with button meters, and the behavior is quite the same.
A reason could be that button meters are nothing more than advanced image meters, with easy state changing abilities and a buttoncommand option. (correct me if i'm wrong)
As Jsmorley stated, rainmeter can't tell us which meter owns a certain pixel.

Apparently, Rainmeter does know which SKIN owns certain pixels, cause otherwise the multi-config solution i'm bearing with would have failed as well.

I understand the issue's priority, as well as the advantage.
A SolidColor=0,0,0,1 doesn't solve all design functionality after all.

[CyrDaan]

I understand the priority level on this as this only becomes a problem with certain types of skins. If this problem is addressed then I do have a suggestion on how it can be done so as to no do as you said, destroy the existing skins that rely on this glitch. If you make it something that the Author can decide within the code itself then we can have the best of both worlds. This would be something similar to other codes like

Code: Select all

Hidden=1

, you could simply put

Code: Select all

TransparentPixels=1

where when the value is 1, TransparentPixels are ignored (Default is 0).

Anyways I guess I will continue on until this is addressed once again. Regrettably I can not do different skins as this skin uses dynamic positioning. When I click on one of the > it extends out and pushes the other >'s furthor out, when I click on it again it pulls them back to their original spot.

Thank you for your help and time, it is really nice to see developers taking such a large interest in the day to day issues.

[CyrDaan]

Btw I reworked the skin so this issue no longer was a problem.

Here is my finished skin. It is a simple and functional tool belt for rainmeter authors.

Feel free to check it out.

[Eastwood]

Btw I reworked the skin so this issue no longer was a problem.

Here is my finished skin. It is a simple and functional tool belt for rainmeter authors.

Feel free to check it out.

Nice design!
I see you had to simplify - and therefore making the design less interesting imo - the buttons to make it work. I might jump onto that "tool belt" concept as soon as i have found a nice opportunity where it comes in handy.

I don't want to keep hammering on the glitch here, but you mentioned the "TransparentPixels=1" option as a probable solution.
Transparency isn't really the issue here, as RainMeter does a pretty good job juggling around with png's and gif's.
The issue is just the lack of a definition of 'ownership', as JsMorley explained so well.
With the root cause being the absence of layers. I can imagine pretty well that taking a solution in account that works its way around this, isn't an easy deal.. and pretty much "start from scratch" concerning RainMeter's graphical output.

All I can do my selves to work around this thingy for now, is continue with my multi-config idea.
I might put up an evaluation of the pro's and con's soon