Youkai1977 wrote: ↑January 30th, 2021, 1:41 am
My problem is this:
In the meter
[MenuPoint] the
Shape = Rectangle 0,4,18,0 | StrokeWidth 9 | Stroke LinearGradient StrokeGradient | Fill RadialGradient FillGradient | StrokeEndCap Triangle | Offset 0, #CURRENTSECTION# should always move to the menu item where the mouse is is on it.
That works great too.
But the
Shape2 = Rectangle 2,0,2,506 | StrokeWidth 1 | Stroke LinearGradient StrokeGradient | Fill RadialGradient FillGradient should stay on its coordinates. It also moves with what it should NOT.
Of course that doesn't work.
Sure, I could do an extra meter for the 2nd shape and it would be done.
But then what I plan to do doesn't work out.
Namely
Shape3 = Combine Shape | Union Shape2 which should still be installed.
Because if Shape2 has an extra meter, I can hardly do the latter command.
The main actors in my skin are currently:
[Style6] &
[MenuPoint]
I hope I have expressed myself clearly and you understand what I want to achieve in my skin.
Who can help me here?
PS: I have included the (still) necessary graphics, if they are needed when you are testing / correcting the skin
OK, at least I'm going to do eye care first. It's 2:35 in the morning and at the weekend it's family first. So answer from me could take time.
Well, almost. You did include the code, but didn't include the external entities, like include files, images, etc. Anyway, for me it doesn't really matter, because in the simulated basic example below, all works out well:
Code: Select all
[Variables]
Offset=0
[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
---Meters---
[MenuPoint]
Meter=Shape
X=0
Y=0
Shape=Rectangle 1,1,100,100 | StrokeWidth 1 | Stroke Color 0,0,0,255 | Fill Color 255,0,0,255 | Offset 0,#Offset#
Shape2=Rectangle 1,1,20,20 | StrokeWidth 1 | Stroke Color 0,0,0,255 | Fill Color 0,0,255,255
UpdateDivider=-1
MouseOverAction=[!SetVariable Offset 50][!UpdateMeter #CURRENTSECTION#][!Redraw]
MouseLeaveAction=[!SetVariable Offset 0][!UpdateMeter #CURRENTSECTION#][!Redraw]
DynamicVariables=1
So the fact that for you it doesn't work has nothing to do with how shape meters behave. Now that we took this possibility out, try to replace #Offset# with #CURRENTSECTION# in the first Shape - nothing happens. The reason is clear:
Offset 0,#CURRENTSECTION# becomes
Offset 0,MenuPoint. There isn't any value associated with
MenuPoint, so the thing is just defaulted to 0 and basically nothing happens.
Now I don't know all the ins and outs in your skin, but it looks to me that you'd want the value of
[Item_Number:Y] there, where Number would be the number of the currently hovered item meter. This only works using #CURRENTSECTION# if the Shape is part of the [Item_Number] section - which is not, as far as I can see. Otherwise, you'd need to identify somehow the Item that is hovered by the mouse. The thing is,
mouse variables only work for clicks or scrolls, and not for hovering. For that, there are various
mouse plugins where you can use mouse variables in the case of hover as well.
I have no idea if I understood what your actual goal is, so if I didn't or I missed something, let us know.
EDIT: If I think about it, you don't even need mouse variables, you only need to set some Index variable to the index of the item that is hovered, on hovering that meter. Basically, a
MouseOverAction=[!SetVariable SomeIndex TheIndexOfThisItem] in all the item meters, then use SomeIndex in the above Shape, like
Offset 0,[Item_#SomeIndex#:Y] or even
Offset 0,[&Item_[#SomeIndex]:Y] if
nesting variables help here.
EDIT2: On an even better look at the code, it looks like Style6, which you use in all the item meters, has
[!SetOption MenuPoint Y [#CURRENTSECTION#:Y]], so that's why both shapes move ... because the meter itself moves.
The rest of the "CPU hogs" bits can be, if not fixed, at least identified by selectively commenting/uncommenting parts of the skin (CTRL+Q on the selected text in Notepad++ with RainLexer) and see which parts use the CPU most. I suppose the 8% to 12% CPU usage is for your entire suite, because for me, your visualizer alone doesn't consume that much (it takes around 3.5% CPU on average over 1 minute on my 2.3 GHz CPU, if I recall correctly). As with everything, there are multiple factors affecting the CPU usage of a visualizer (some internal, some external), like explained here.
I don't need any temps
