[Rebooted] Re: Can I extract the position of a skin to use as a variable?

[balala]

I do actually use that one

Well, I didn't say it is not used at all. Obviously it is sometimes. But probably it is much less used then for example !ActivateConfig / !DeactivateConfig (this is just my opinion, starting from my own experience). This doesn't mean it would be less important or less useful. When you need it, it is important.

[Mor3bane]

Hello, so I am using this:

Code: Select all

[MeasureMainXY]
Measure=Calc
Formula=( #CURRENTCONFIGX# + #CURRENTCONFIGY# )
OnChangeAction=[!SetOption ImageArcaneR X "#CURRENTCONFIGX#" "Round Arcane\Puzzles"][!SetOption ImageArcaneR Y "#CURRENTCONFIGY#" "Round Arcane\Puzzles][!Update ImageArcaneR] [!Redraw "Round Arcane\Puzzles"]
DynamicVariables=1

It works - sort of. Let me explain briefly.
The "child" skin does indeed move as the "parent" skin is dragged around. The rub is that the "child" skin is waaaay off to the right, and down a fair bit as well. I was hoping to manipulate the translation, but I haven't had any luck in controlling where the "child" skin is when it tails along with the "parent" skin.

Any recommendations? I can post my full code, but that would be kind of difficult as there is quite a bit going on - code-wise. So to avoid those "where is the blabla meter etc. I attached my current rmskin.

[balala]

The "child" skin does indeed move as the "parent" skin is dragged around.

No, it doesn't. It stays unmoved. Its [ImageArcaneR] meter is what is moving, because this is what are you moving, through the !SetOption bangs of the OnChangeAction option of the [MeasureMainXY] measure (MainControl.ini skin).
To "manipulate the translation", you have just to reduce the value, where the meter is placed by the two !SetOption bangs. Replace the original bangs with something like: [!SetOption ImageArcaneR X "[color=#FF0000]([/color]#CURRENTCONFIGX#[color=#FF0000]/2)[/color]" "Round Arcane\Puzzles"] and [!SetOption ImageArcaneR Y "[color=#FF0000]([/color]#CURRENTCONFIGY#[color=#FF0000]/2)[/color]" "Round Arcane\Puzzles"]. The number with which the variables are divided, depends on how would you like to move the meter, probably you have to find the best value(s) for your needs. The two numbers don't even have to be equals. You can experiment to figure out the best values.
On the other hand, the ImageArcaneR name used in the !Update bang of the same OnChangeAction option, is wrong, because you don't have a config named ImageArcaneR. There is a such meter, but that not in the same skin, but in Puzzle_1.ini. So, a correct form of the above bang would be [!Update[color=#FF0000]Meter[/color] "ImageArcaneR" [color=#FF0000]"Round Arcane\Puzzles"[/color]], to update the meter existing in the Puzzle_1.ini skin (within the Round Arcane\Puzzles config).

[Mor3bane]

Hi,
Ok, if i understand the built-in variables #CURRENTCONFIGX# and #CURRENTCONFIGY# those coordinates are according to their *position* on the desktop. Is that correct?

If so then my two skins "should" line up at their upper left-hand corners - shouldn't they? By default, that is?

Again, if so, then that is definitely not happening.

Say then, that is my goal - to line up two skins according to some equation of #CURRENTCONFIGX and Y#.

Where would I go from what we have discussed so far to do that - for any relevant coordinate determined by the Equation of theMeasure=Calc in the "origin-skin"?

Ideally the skins would move together as if they had been ctrl+alt+leftclicked - not just hobbling along according to the actual speed the skins were refreshing at. For example, I have set the update=300 in the Rainmeter section, and the "other-skin" barely keeps up and seems to "loose itself" in the mix of refresh and update, and redraw all going on in there.

[balala]

the built-in variables #CURRENTCONFIGX# and #CURRENTCONFIGY# those coordinates are according to their *position* on the desktop. Is that correct?

Almost. What are you meaning by their? Because the variables are according to the position of the skin on the desktop.

If so then my two skins "should" line up at their upper left-hand corners - shouldn't they? By default, that is?

Not exactly, because in the code posted by you in your last reply a meter of the second skin (Puzzle_1.ini) is moved based on the position of the first skin (MainControl.ini).
So first please decide what you would like to do: move the Puzzle_1.ini skin, or move a meter of it?

[jsmorley]

You simply cannot have two skins "follow each other around" as they are dragged. That is a fool's errand, as Rainmeter is simply not capable of keeping up with Windows Desktop Manager, and to even get close would at best still be "jerky" and would use enormous amounts of CPU.

[balala]

You simply cannot have two skins "follow each other around" as they are dragged.

Maybe following each other around no, but one following the other, yes. Eg:

• The leading skin:

  Code: Select all

  [Rainmeter]
  Update=1000
  
  [MeasureXY]
  Measure=Calc
  Formula=( #CURRENTCONFIGX# + #CURRENTCONFIGY# )
  OnChangeAction=[!Move "#CURRENTCONFIGX#" "#CURRENTCONFIGY#" "THE-CONFIG-OF-THE-FOLLOWER-SKIN"]
  DynamicVariables=1
  
  [Meter1]
  Meter=STRING
  X=0
  Y=0
  Padding=15,5,15,5
  FontColor=220,220,220
  SolidColor=0,0,0,120
  FontSize=18
  FontFace=Segoe UI
  StringStyle=BOLD
  StringAlign=LEFT
  AntiAlias=1
  Text=This will be followed

• The follower skin:

  Code: Select all

  [Rainmeter]
  Update=1000
  
  [Meter2]
  Meter=STRING
  X=0
  Y=38
  Padding=15,5,15,5
  FontColor=220,220,220
  SolidColor=0,0,0,120
  FontSize=18
  FontFace=Segoe UI
  StringStyle=BOLD
  StringAlign=LEFT
  AntiAlias=1
  Text=By this one

[Mor3bane]

You simply cannot have two skins "follow each other around" as they are dragged. That is a fool's errand, as Rainmeter is simply not capable of keeping up with Windows Desktop Manager, and to even get close would at best still be "jerky" and would use enormous amounts of CPU.

Yes, definitely not - as I have noticed. It seemed really cool to see the "best" possible result firsthand. However, in saying that, it just isn't viable to make any further effort in this specific domain due to those performance issues in terms of being "jerky".

I also noted that after making adjustments whilst editing my code to experiment etc, that there was certainly wider performance issues requiring a restart due of my PC due to a DRM program not wanting to go past the launcher app, following a hour or so of tinkering around with the 'follow-me' code.

I think, whilst moving on now, that it 'was' fun tinkering around with this.

[balala]

Yes, definitely not - as I have noticed. It seemed really cool to see the "best" possible result firsthand. However, in saying that, it just isn't viable to make any further effort in this specific domain due to those performance issues in terms of being "jerky".

I also noted that after making adjustments whilst editing my code to experiment etc, that there was certainly wider performance issues requiring a restart due of my PC due to a DRM program not wanting to go past the launcher app, following a hour or so of tinkering around with the 'follow-me' code.

I think, whilst moving on now, that it 'was' fun tinkering around with this.

Not to tease you: https://forum.rainmeter.net/viewtopic.php?p=147005#p147005

[Mor3bane]

@balala
Yes, I looked at the !Move bang as well - it seemed to generate less "lag" but - in apology - I would like to move on from these 'chase the leader' discussions, as jsmorely said, the performance issues make the effort less than desirable in general in terms of having a clean appearing final product - so to speak.

Many thanks for helping me explore this balala and jsmorely


I do however want to explore simply aligning two separate skins to specific coordinates in each skin e.g. skin a & skin b aligning to one another no matter where the end user has them placed on the screen.

I do know to start with a similar requirement will be necessary - that one skin will in actuality be aligning to the other. For simplicity's sake that is fine with me, meaning first skin will determine where second skin will appear and not the other way around. ANd that the skins would NOT be expected to stay together if the end user moved one or the other.

I imagine this will be more direct than having them moving around and staying together?