Not sure if this is even possible, so have to ask.

[eclectic-tech]

Eclectic-tech already integrated the Hotkey stuff into the code, and using keys instead of mouse scroll should be easier and more comfortable to work with, so that's already settled. What you should know though, just by looking at eclectic-tech's code is that (Clamp(#YPosition#+2,0,#RulerWidth#)) basically does what I did by using Max() and Min() formulas: it constraints a value (#YPosition#+2 in this case) between two others (i.e. 0 and #RulerWidth#). My method was more rudimentar, and could have been more or less written in this case using Max(#YPosition#+2, 0) and Min(#YPosition#+2, #RulerWidth#).

I agree that either method gives the same result; there is usually more then one way to achieve the result, and it is entirely up to the author to decide which method they want to use.

Yes, I did write the hotkey measures basically because they need to be updated with a bang to reflect the new value; DynamicVariables=1 alone, added to the measure, doesn't update the hotkey value (a little different since the plugin is not dynamic).

I didn't look at your skin until after posting... (bad manners perhaps ) I like how you toggle the left mouse bang using the middle mouse! Well done!

[Yincognito]

I didn't look at your skin until after posting... (bad manners perhaps ) I like how you toggle the left mouse bang using the middle mouse! Well done!

Nah, it's not bad manners. It's much easier to understand your own code than to decifer other's, it happens in my case too. Regarding toggling, having to deal with constraints (of resources like time, space, or in this case, mouse buttons) forces one to find all kinds of tricks like this - and my skins suffer from a lot of such constraints (space and mouse buttons for sure). I use such methods in my skins for years, out of necessity. Necessity is one of the best "teachers" there is.

I agree that either method gives the same result; there is usually more then one way to achieve the result, and it is entirely up to the author to decide which method they want to use.

True that, but there is another aspect in this: some methods offer greater flexibility. That's one of the reasons why I don't use Loop measures to this day, and prefer "classic" counters like the one in [MeasureScrollMode], for example. The Clamp function, well, I didn't get to use it either, not because it was necessarily less flexible, but because I didn't feel like rewriting my existing code just to convert an older method to a newer one (although, if I think about handling disjoint intervals, I guess the Min/Max method is a bit more flexible than Clamp, maybe).

[Beuwolf]

First off... WOW ! Bit stunned having looked over both Yincognito's and eclectic-tech's revised coding and just realizing how far out I am in the deep water here ! I got to swim back and start going over things more thoroughly before taking another step forward, and not jumping ahead !

Well, I'm going to be honest with you: you messed up the code a bit when "playing around" with it. Adding things just like that and expecting them to work is not how one efficiently builds stuff. You must at least have an idea about what this and that does before you copy paste things here and there. If you don't, you ask!

Honesty is good ! So don't worry about it, just dish it out when needed !

Yeah, I see now it was a big mess indeed. I just played around, seeing what worked and not. I realize though I have to do more reading, although it is a bit easier to understand things when you see the effects of what you doing. That's one of the reasons I started playing around with this idea actually. The new Icon Dock I'm working on, I removed a r (relative positioning) expecting the Icon to move a little, but instead it moved much further then expected. So I started looking around for something ruler like to figure out why, but didn't find exactly what I was hoping for and so here we are !

If you took a look at my code trying to understand what's happening there, you wouldn't even think to use one pixel middle / right mouse click to move things - I mean, come on, what are we, turtles?! If you set up a "move mode", then you can use the much faster mouse scroll for both horizontal and vertical movement, and the middle mouse click to toggle between them (like I did in my version of the skin). And of course, you'd free up the right mouse click entirely (no need for CTRL key to be pressed anymore).

Yup, I did not inspect your code properly and jump the gun a bit there.

The revised code:

Be aware that the 1100 and 600 in [MeasureScrollChange] are the hardcoded values you have used yourself in [BG]. Normally, they should be the screen area dimensions, so that it would suit every monitor, since hardcoded values have the potential to be "incompatible" when the resolution of the monitor changes (to smaller dimensions, for example).

Was not aware of that, thought it had to be of the area used, i.e. the minimized dock. I'll revise that after looked over your new code thoroughly.

Some notes regarding your mistakes in the previously posted code:
- all the shapes you had in [BG] represent a single meter, so no matter how you arrange your mouse actions there, they will react to the meter (that includes all the ShapeN shapes), not to the shape they are under!
- [!Move (#CURRENTCONFIGX#) (#CURRENTCONFIGY#)] caused the jump you saw in your skin. The bang should have done nothing, as it basically moved to the same coordinates (since you didn't add or subtract anything from #CURRENTCONFIGX/Y#), but for some reason it jumped to that location - didn't investigate too much why and where, I just deleted it as it was wrong and served no purpose whatsoever (eclectic tech's skin doesn't need to move like my initial version of the code)
- you copy pasted the Max() formulas into the mouse actions from [BG] without thinking too much what they mean. Thus, you didn't pay attention that there were some Min() formulas in the code I originally posted as well. The purpose of the Max() formulas is to prevent values under 0, and the purpose of the Min() formulas is to prevent values over the current resolution or any other hardcoded value you use as "movement bounds" (be it vertical or horizontal). Like I said, if you don't know something, just ask - knowledge is no place to be "stubborn", you can only be stubborn after you know what you're doing.

Yup, you are right. Quiet a lot of mistakes and I do need to go back and read up more. It's just more fun to do the code and see the results. I'll see if I can find examples to go with the documentation I'm reading to make it all more interesting.

There you go - I told you exactly what should have been said. Fairly and honestly, no hard feelings. These kind of things are to help you progress, because if you only go by taking some code from here and another from there and expect the mix to magically work, it might not behave as you expect it too. On the other hand, if you try to understand (and ask where you don't) things, then the code will "follow your lead" more easily.

Yup, no hard feelings at all ! Glad that you pointed out my mistakes so I can go back and learn from them. Might be another thread some time down the line with a couple dozen questions though !

EDIT: YIncognito pointed out some errors in your code and made some suggestions that I showed you how to implement. I would suggest looking at the changes I made to your [BG] shape meter, and how the hotkey measures are grouped so they can be updated with a single bang. I hope that showing working code helps you with your coding. We all started not knowing how to do much, but with practice and patience, you will accomplish your goals.

Yes he did and it is much appreciated ! So are your rewriting of the code as well ! I be comparing both your codes and hopefully understand it all better as to how it all works together.

Here's my "2-cents"...

Added hotkeys for movement (CTRL+Arrows).
Removed your !Move commands.
Removed the middle mouse and right mouse key. I left the mouse scroll, but think they are not needed since the arrow keys do everything.
Renamed X & Y variables to XPosition and YPosition.
I added middle mouse button to reset to position 150,150.
Added ruler width and height variables, so size can be changed.
Added hotkey variables to simplify changing control keys.
Added indicators for current X & Y positions at the end of the rulers.
Added Hidden test to only show ruler numbers that are within RulerWidth and RulerHeight settings.

Yeah I have phased out the mouse scroll action, the arrows works better. The rest I have to look into a bit more to understand it all better.

Got to admit that those Indicators you added to the end of the X & Y Axis is a brilliant idea !!

You asked for suggestions or pointers... you created a very nice tool!

Since you already have the hotkey plugin, this code can be saved with a new name and tested...

I might have come up with a good idea, but it is you and Yincognito that made it all shine !!

I'm really grateful for both your help and the codes you provided, it sure shows how much I have to learn before I jump into anything similar like this again !!

[Yincognito]

I just played around, seeing what worked and not. I realize though I have to do more reading, although it is a bit easier to understand things when you see the effects of what you doing. [...] Yup, you are right. Quiet a lot of mistakes and I do need to go back and read up more. It's just more fun to do the code and see the results. I'll see if I can find examples to go with the documentation I'm reading to make it all more interesting. [...] Yup, no hard feelings at all ! Glad that you pointed out my mistakes so I can go back and learn from them. Might be another thread some time down the line with a couple dozen questions though !

Just so that it's clear what I meant - I did not say that you should bury yourself in the docs and stop experimenting with the code: I'm all for doing the opposite, actually (only checking the docs when it comes to syntax or what can/cannot be done, for example - otherwise play with the code, as practice is key).

What I meant that if you don't understand what the code does while "playing" with it, ask for an explanation. Ask "why". Sure, saying "thanks" for a ready-made code instead saves time for both you and the one helping you, but understanding why something does what it does saves time (and effort) in the long run, as you'd know what to do (and why you do it) without asking anyone, eventually.