I discovered something while playing with a "fully featured" custom tooltip skin that has images in it (like a ToolTipIcon equivalent, for example) and meters aligning to the images using the
r /
R relative positioning:
the W and H options of the image meters must be set to 0 in the tooltip skin (along with the
ImageName set to nothing - just like the
Text option of the String meters is set to nothing above), and everything about populating those options (not just
ImageName, but also
W and
H) with the actual values
must be done from the parent skin.
If you don't, the tooltip skin will not be hidden when it is first drawn in the "wrong" position, and although the movement to the right position will take place, this operation will be visible and not "behind the scenes" (as it's supposed to happen). By the way, this behavior will only happen when the parent skin is at the edges of the screen area and the tooltip "doesn't fit" completely up to those edges (and is moved to fit within the screen area as a result). Otherwise, when there is place for the tooltip skin to fit inside the screen area (when the parent skin is further away from the edges, for example), no such behavior will happen.
HINT: If you
don't want to set the
W and
H on the image meter (i.e. you want them to stay blank in order for the meter to automatically adapt to the image dimensions - horizontally, vertically or both), use a MeterStyle to restore the "blank" option, as explained in the
SetOption guide here. For example, say one has an unknown size image that needs to be displayed in the tooltip skin at its original dimensions (and not some hardcoded ones); all that needs to be done is:
- set a MeterStyle for the image meter (either in the tooltip skin or in an .inc that the tooltip skin uses) where
W and/or
H are either omitted or explicitly set to nothing
- set the
W and/or
H to
0 in the tooltip skin, right
after the
MeterStyle=... option of the image meter
- use a !SetOption bang from the measure that populates the tooltip in the parent skin to set the
W and/or
H to
"", thus allowing the MeterStyle setting on the image meter to again control those options
Thankfully, I solved this issue much faster than the rest of the issues that make up this thread. Kudos to the Rainmeter manual (and its authors)
UPDATE: So, after overcoming another little issue with images (for some reason, the .ico in the skin didn't like more than 1px of left padding - now I'm not even sure it's strictly about images or that an image applied to the sample above would cause issues, as I perform other visual enhancements in my own tooltip skin version, like a custom width bevel, so this might interfere somehow), this is what you can do with it - it's time for my own preview (OS tooltip at the top, custom one using multirow title, inline options and a monospaced font for right-alignment at the bottom) - notice that changing position at the edges of the screen area works smoothly:
UPDATE 2: Forget about the images issue, I figured out why that happened and how to solve it once and for all: it was just a matter of moving the
[!Redraw "#ROOTCONFIG#\Tooltip"] before the update of the tooltip skin's measures, in the measure that populates the tooltip. This, along with a couple of changes (switching back to variables as it's less code to write) and one or two variables to properly check things before acting in a certain way solved it -
no need for the above precautions anymore when using images with padding or relative positioning towards them. The "final product" has been moved to the "Tips & Tricks" section of the forum, to (hopefully) help others as well.
UPDATE 3: I
really hate to change my statements like that but apparently, there is
something going on regarding images with undefined dimensions, padding, dynamic variables and relative positioning towards them. It turns out that the issues I mentioned here had nothing to do with my code, but rather with the way Rainmeter works. Anyway, the good thing is that there are multiple workarounds for this little annoyance, and they're all mentioned in the note at the bottom of the
"Tips & Tricks" post on this.
You do not have the required permissions to view the files attached to this post.