I'm ressurecting this thread a bit because I have another problem. Recently I've been able to start the tooltip skin (i.e. Tooltip.ini) hidden thanks to a (new, maybe?) option in Rainmeter.ini's skin section, called StartHidden, and everything goes smoothly ... except for the fact that the built-in variables #CURRENTCONFIGX#/#CURRENTCONFIGY# (and possibly even #CURRENTCONFIGWIDTH#/#CURRENTCONFIGWIDTH# - although these don't interfere with the process here because their values are unchanged) are "behind" the mouse movement actions, from a timeline point of view.
In other words, if I move the parent skin on the screen and then quickly hover over the relevant text, the tooltip (i.e. Tooltip.ini) skin's coordinates (and thus, #CURRENTCONFIGX#/#CURRENTCONFIGY# values) don't update according to the parent skin's last actual position, but to values from the recent past, resulting in the tooltip being shown in a past position from the dragging trajectory of its parent skin. However, if I move the the parent skin, wait a bit, and only then hover to show the tooltip skin, all works well and the tooltip is shown according to its parent skin's actual position.
So, this begs the question: why are #CURRENTCONFIGX#/#CURRENTCONFIGY# not updated to reflect their correct values in case of fast mouse movements / actions? Also, what can be done to correct this issue?
This is my (updated) skin:
Custom Tooltip Skin 2.0.0.rmskin
And the code, if you don't want to download/install it (the files should exist in 2 subfolders - Skin and Tooltip - of a normal skin folder):
And yes, I've used DynamicVariables=1 properly, so it's not that. You can see the parent skin's (correct or incorrect, depending on circumstances) position by checking the ParentX and ParentY variables from the Tooltip.ini file.
You do not have the required permissions to view the files attached to this post.
Yincognito wrote: ↑February 19th, 2020, 5:30 pm
So, this begs the question: why are #CURRENTCONFIGX#/#CURRENTCONFIGY# not updated to reflect their correct values in case of fast mouse movements / actions?
They are, but when you're writing them using !WriteKeyValue bangs, the other skin can't follow the new values, they not being dynamic.
Yincognito wrote: ↑February 19th, 2020, 5:30 pm
Also, what can be done to correct this issue?
I'd try to add a [!Move "#CURRENTCONFIGX#" "#CURRENTCONFIGY#" "#ROOTCONFIG#\Tooltip"] bang to the end of the MouseOverAction option of the [MT_Rainmeter_HoverHere] meter, within the Skin.ini skin.
balala wrote: ↑February 19th, 2020, 6:56 pm
They are, but when you're writing them using !WriteKeyValue bangs, the other skin can't follow the new values, they not being dynamic.
I'd try to add a [!Move "#CURRENTCONFIGX#" "#CURRENTCONFIGY#" "#ROOTCONFIG#\Tooltip"] bang to the end of the MouseOverAction option of the [MT_Rainmeter_HoverHere] meter, within the Skin.ini skin.
First paragraph is not plausible, in my view. Either they're dynamic or they're not. They are dynamic when they are parsed by the parent skin, why wouldn't they be updated as such when written in the tooltip one?
Second paragraph does nothing but move the tooltip to an intermediate position, and that doesn't change anything. Not to mention that the fact that I move the tooltip from within Tooltip.ini is because I need its width and height when computing the position. I can't get another skin's width and height from the current skin, can I?
1) !WriteKeyValue is never "dynamic" in any way. It writes to a file, and if that is a .ini or .inc, those file must be refreshed / reloaded to see any change.
2) No, you can't "pull" any information about any other skin from within a skin.
jsmorley wrote: ↑February 19th, 2020, 7:24 pm
1) !WriteKeyValue is never "dynamic" in any way. It writes to a file, and if that is a .ini or .inc, those file must be refreshed / reloaded to see any change.
2) No, you can't "pull" any information about any other skin from within a skin.
1) Yeah, I didn't say !WriteKeyValue was dynamic. I said that it already has the dynamic value provided by #CURRENTCONFIG...# prepared to be (non-dynamically, of course) written. Regarding the refresh / reload, doesn't this happen when "activating" the tooltip skin (which I do, after previously being "deactivated")?
2) Exactly. Which is why I have to use the !Move in the tooltip skin and not in the parent.
Yincognito wrote: ↑February 19th, 2020, 7:39 pm
1) Yeah, I didn't say !WriteKeyValue was dynamic. I said that it already has the dynamic value provided by #CURRENTCONFIG...# prepared to be (non-dynamically, of course) written. Regarding the refresh / reload, doesn't this happen when "activating" the tooltip skin (which I do, after previously being "deactivated")?
When you unload, then reload a skin, it is loaded in the same place where it was before unloading. To move it you have to use a !Move bang. That's why I proposed to add a !Move bang.
balala wrote: ↑February 19th, 2020, 7:50 pm
When you unload, then reload a skin, it is loaded in the same place where it was before unloading. To move it you have to use a !Move bang. That's why I proposed to add a !Move bang.
Yes, it's true that at first (i.e. before updating the ToolTipGroup measure group from Tooltip.ini) the position of the tooltip is the same as before loading - but that doesn't matter, as the tooltip is started hidden anyway. However, in the [MS_Rainmeter_PopulateTooltip] measure from the parent skin, I update the previously mentioned measure group, hence computing the new (and final) position as well as moving the tooltip there, before actually showing the tooltip to the user.
Yincognito wrote: ↑February 19th, 2020, 8:15 pm
Yes, it's true that at first (i.e. before updating the ToolTipGroup measure group from Tooltip.ini) the position of the tooltip is the same as before loading - but that doesn't matter, as the tooltip is started hidden anyway. However, in the [MS_Rainmeter_PopulateTooltip] measure from the parent skin, I update the previously mentioned measure group, hence computing the new (and final) position as well as moving the tooltip there, before actually showing the tooltip to the user.
Ok, please give me a hint on EXACTLY what should I do and what should I get. I mean that would be needed a description of what to load, what to drag, what the mouse to hover over and what should I see. It seems all these are not exactly clear to me.
Sorry...
Nevermind, I finally got it done, and it's working perfectly, irrespective of the speed I'm hovering with the mouse. It even updates to the correct position while dragging, if I put the code in [MS_Rainmeter_PopulateTooltip]. What I did is to change the !WriteKeyValue bangs into !SetOption ones, and instead of variables in the (undynamic) [Variables] section of Tooltip.ini, I used Calc measures.
I believe now it does things faster, as !SetOption works with the memory, instead of the hard drive. I'll post the final code right away - I need to celebrate with a cigar first. Yay!
balala wrote: ↑February 19th, 2020, 8:27 pmOk, please give me a hint on EXACTLY what should I do and what should I get. I mean that would be needed a description of what to load, what to drag, what the mouse to hover over and what should I see. It seems all these are not exactly clear to me. Sorry...
I told you, balala - no need to apologize, at least not with me. Your hints and jsmorley's ones actually helped, as I decided to get rid of the !WriteKeyValue bangs. I never liked having to use them anyway, for speed / performance considerations. Stay tune for the final code.
Your hints and jsmorley's ones actually helped, as I decided to get rid of the !WriteKeyValue bangs. I never liked having to use them anyway, for speed / performance considerations. Stay tune for the final code.