Need help to code a USB Meter - Please

[dfghrngsdkg]

The plugin is the appropriate .dll file, which has to be installed into the c:\Users\xxx\AppData\Roaming\Rainmeter\Plugins\ folder. What you have into the C:\Users\xxx'\Documents\Rainmeter\Skins\@Vault\ folder is a "backup" of both versions (x86 and x64) of the installed plugins. The purpose of copying those into the @Vault folder is to have a copy of both versions, if anytime later you want to re-create the skin installer (https://docs.rainmeter.net/manual/distributing-skins/vault-folder/#VaultPlugins).
When a skin uses the plugin, it doesn't use the plugin from the @Vault folder, but, as said, from c:\Users\xxx\AppData\Roaming\Rainmeter\Plugins\. There sits the used plugins, into one single folder.
Don't move them.

Hey,

Thank you for the information. I won't do that, just thought I copy it to make it permanent but now I know. Btw, is there a way to get the measure and reading when plugging in a Mobile? Because a Mobile is actually a USB-storage too with the Windows-Tray that recognizes it as a such but the UDisk doesn't.

The Code you provided for Show/Hide transfer was the one I was looking for. After transfering it and some modifications made it works for now the way it was envisioned - except that the Header >> [ TRANSFERS] takes a bit to show up and hide (the Drives show up and hide faster), but that's probably a RAM issue(?)

Note: I didn't provided all .inc files as code in here as it would blow the space so I had fitted the relevant parts (meter, stlye, variables) into one single .ini file to make it a) shorter and b) faster to access.

[dfghrngsdkg]

With issue No.1 solved (the Header part) there is only the issue with the spacing left.

Background: Before I decided to post that issue with the spacing here I "toyed" with the Padding option because it appeared logical to me that if I give the Header >> [TRANSFERS] a bit of space below it, it would be the bottom on which each Drive would automatically anchor at when setting their Y-Values to 0R. On the contrary, a Value of Y=0R also defines the space between both Drives when attached, which is causing an unpleasant appearance. Also: When trying to define a bottom space with "Padding", there was something that appeared to me as a "bottom-space", but the Drives somehow refused to anchor at it.

The idea to have a container (if really necessary to go this way) is something I tried to create. Based on the file you, jsmorley had provided it unfortunately lead me to nowhere -because of my skills in coding. Of course I could create a box in the correct proportions, but could't fit the MeterStyleTranser into it. It also seems I have to create a container for each Drive but not understand where to place the code as I have separated .inc files with separated items (meters) in it and not a single meter where everything is packed into (complexity).

My approach was: First to create a container (one for each Drive) stored in the main. ini file with the Drives.inc information placed into it, but that is -even logical to me- probably not the way it has to be. So Option 2 is to store the Container's information directly into the Drive's.inc file but then I face the problem as I described in the paragraph above. So I am running in circles.

The attempt:

box.JPG

For this time I'll provide a part of the whole skin (I am working on 3 version), so that it is easier to understand what I have - instead to go with a single that might lead to confusion. >>

Drives++ _ Testing_v.1.rmskin

[dfghrngsdkg]

The whole idea of this Skin is to make it as flexible as much. Let's say the majority of user usually have a C: and D: Drive (as their main) + USB Drives whereas some have only a C: Drive. So (later in my design) I want to create an hidden D: Meter with [TRANSFERS] recognizing if D: is attached or not and is moving up and down accordingly in its determined distance (spacing) with the USB Meters following the [TRANSFERS]-Header in their determined spaces (distance) too.

[balala]

Btw, is there a way to get the measure and reading when plugging in a Mobile? Because a Mobile is actually a USB-storage too with the Windows-Tray that recognizes it as a such but the UDisk doesn't.

I'm not sure if UDisk doesn't recognizes it. Sorry.

After transfering it and some modifications made it works for now the way it was envisioned - except that the Header >> [ TRANSFERS] takes a bit to show up and hide (the Drives show up and hide faster), but that's probably a RAM issue(?)

No, that's not a RAM issue. It is caused by the UpdateDivider=2 options added to the [MeasureTotalDrive2] and [MeasureTotalDrive3] measures, within the @Resources\Drive2_USB.inc and @Resources\Drive3_USB.inc files. Remove them.

[balala]

The whole idea of this Skin is to make it as flexible as much. Let's say the majority of user usually have a C: and D: Drive (as their main) + USB Drives whereas some have only a C: Drive. So (later in my design) I want to create an hidden D: Meter with [TRANSFERS] recognizing if D: is attached or not and is moving up and down accordingly in its determined distance (spacing) with the USB Meters following the [TRANSFERS]-Header in their determined spaces (distance) too.

The sections needed to show up the information of the D: drive are missing. I suppose you have to add them first to can fix the issue.
But I see another issue as well: further hard drive partitions might exist as well. E:, F: or whatever else. What's gonna happen in a such case?

[dfghrngsdkg]

"No, that's not a RAM issue. It is caused by the UpdateDivider=2 options added to the [MeasureTotalDrive2] and [MeasureTotalDrive3] measures, within the @Resources\Drive2_USB.inc and @Resources\Drive3_USB.inc files. Remove them."

Hmm, I removed the UpdateDivider=2 options (by disabling) - still the same. For testing I even disabled them on every other [measure] I found in each E: and F: inc. file + later on at the C: Drive.inc. Still the same, with the Drives showing up first and the Header approx. a second right after + vice versa when removing it. However, if it works on your system the way you proposed it, then it might be the problem of my (a) lacking Computer.

"The sections needed to show up the information of the D: drive are missing."

Of course it is. Here I want to only show the concept with its relevant parts - to make you understand what I am doing + me to understand the position part and how it works (aka what to do). The bits of codes you provide will later be added to a D: - Z: Drive. Shortening the File is efficient as it makes no sense to put as many Drives into this skin if the principle can be explained on a static C: and 2 flexible USB-Drives with the relevant codes later be Copy&Pasted. Right now I have the issue with spacing vs. positioning Drives aka if Drive A is removed the next one (Drive B) shall move into Drive A's exact position without to mess up the spacing between these Drives when both are attached.

"But I see another issue as well: further hard drive partitions might exist as well. E:, F: or whatever else. What's gonna happen in a such case?"

I do understand your point. Let me say: First of, I want to focus on the smallest set-up (Design1) which is a static C: and USB 1-3). In Design2 it will have a static C: and D: + USB 1-3. In Design3 the idea is to have a static C:, D:, E: with the latter two are hidden + USB 1-x. The problem is not about adding .inc files to the .ini (simple copy n paste + modification), the main problem might be: If I attach a hidden static D:, E: etc, will it show up in the main section as wanted (above [TRANSFERS]) rather than below in the USB-section.

1st. of all I'd like to solve the spacing/positioning issue. 2. I want the whole Design to be modular and 3. Rainmeter User mainly know how to mod. files to their preferences and to make sure I might include a .txt file a "how to" for folks like myself.

[balala]

Hmm, I removed the UpdateDivider=2 options (by disabling) - still the same. For testing I even disabled them on every other [measure] I found in each E: and F: inc. file + later on at the C: Drive.inc. Still the same, with the Drives showing up first and the Header approx. a second right after + vice versa when removing it. However, if it works on your system the way you proposed it, then it might be the problem of my (a) lacking Computer.

Ok, try to add to both measures [MeasureTotalDrive2] and [MeasureTotalDrive3] within the @Resources\Drive2_USB.inc and @Resources\Drive3_USB.inc files an OnChangeAction=[!UpdateMeasure "MeasureTotalDrive"] option. This way whenever the values of those measures are changing an update of the [MeasureTotalDrive] measure is done.

[dfghrngsdkg]

Ok, try to add to both measures [MeasureTotalDrive2] and [MeasureTotalDrive3] within the @Resources\Drive2_USB.inc and @Resources\Drive3_USB.inc files an OnChangeAction=[!UpdateMeasure "MeasureTotalDrive"] option. This way whenever the values of those measures are changing an update of the [MeasureTotalDrive] measure is done.

Works! three questions:

1. Is it now advised to turn back on all "UpdateDivider=2" inclusive the ones I had disabled under [MeasureTotalDrive2/3/etc]?

2. Do I need to add the specific Drive number to each measure like: OnChangeAction=[!UpdateMeasure "MeasureTotalDrive2"] etc? Because the actual wording in each Driver.inc is: "[MeasureTotalDrive2]" , "[MeasureTotalDrive3]", etc.

3.What if -instead to place this code into each Drive.inc- I only add it underneath [MeterTransferStyle] in the main.ini file like: OnChangeAction=[!UpdateMeasure "MeasureTotalDrive2" | "MeasureTotalDrive3"].. something like this?

[balala]

1. Is it now advised to turn back on all "UpdateDivider=2" inclusive the ones I had disabled under [MeasureTotalDrive2/3/etc]?

Try out. I suppose it can be done, however trying it is the best practice.

2. Do I need to at the Drive number to each measure like: OnChangeAction=[!UpdateMeasure "MeasureTotalDrive2"] etc?

If there is / will be more such measures, yes, add it on each of them.

3.What if -instead to place the code into each Drive.inc- I only add it somewhere underneath [MeterTransferStyle] in the main.ini file like: OnChangeAction=[!UpdateMeasure "MeasureTotalDrive2" | "MeasureTotalDrive3"].. something like this?

I don't really understand what you're meaning, but I suppose the question is what to do if the [MeasureTotalDrive2], [MeasureTotalDrive3], ... measures are added to the main file of the skin. Am I right?
I usually am not really happy when there are included files, especially not on forum, where people are asking for help, because it is much harder for me to follow what's going on, on those included files, than if there is only the main file. However it's finally completely up to you what approach do you choose and use.

[dfghrngsdkg]

1. I'll try it. Thought enabling the UpdateDivider might interfere with the newly placed "OnChangeAction=[!UpdateMeasure "MeasureTotalDrive"]"

EDIT to: 1.
I enabled all "UpdateDriver=2", but had to refrain from adding Drive-Numbers to the code: "OnChangeAction=[!UpdateMeasure "MeasureTotalDrive"] because only then it works without delay. So it will now measure all TotalDrives combined and simultaneously (I suppose). Just hope it won't gradient slow down the show/hide if more Drives are added in the future. For now its speed is that of an expected "instantly".


2. I asked as it appeared logical to me and with your confirmation makes it easier for me to be confident in doing so.

3. Sorry, my bad. I thought that if I skip the part of placing the "OnChangeAction=[!UpdateMeasure "MeasureTotalDrive"]" to each .inc file and instead place it into the main .ini file -which works as the connector of all dots by creating something like this:

Code: Select all

[MeasureTotalDrive]
Measure=Calc
Formula=( MeasureTotalDrive2 + MeasureTotalDrive3 )
IfCondition=(#CURRENTSECTION#=0)
IfTrueAction=[!HideMeter "MeterStyleTransfer"][!Redraw]
IfFalseAction=[!ShowMeter "MeterStyleTransfer"][!Redraw]
OnChangeAction=[!UpdateMeasure "MeasureTotalDrive2"][!UpdateMeasure "MeasureTotalDrive3"]

Also: Only if 3. is a legit procedure in coding (confirmed), is it better to write "OneChangeAction=etc" out like I did in the code above or can I shorten it by simply writing: "OnChangeAction=[!UpdateMeasure "MeasureTotalDrive2" | "MeasureTotalDrive3"]