It seems to resolve before anything shows in skin, so that is why i think its a start up error rather than a persistent one - well it does not finish at 0 or empty.
Since you are using a section variable in the Drive option of the FreeDiskSpace measures, it's normal to get a message in the log when you refresh the skin, because on first update these measures have no value set for the Drive options.
To avoid them, disable all FreeDiskSpace measure, by adding a Disabled=1 option to all of them ([mDriveLabel1], [mIndexSize1], [mDriveLabel2], [mIndexSize2] and so on). You have to enable them when the FileVeiw plugin measures get their values. For this add a FinishAction=[!EnableMeasureGroup "Children"] option to the [mPath] parent FileView measure.
I knew (sort of) that using a disabled measure section name, - but my impression blindly enough was to restart those Measures again at the needed time.
CodeCode wrote: ↑November 2nd, 2024, 2:13 am
A new issue has been found.
When folders are open the empty value repeats for every file in the folder, in the log.
I tried the same trick but I don't think I am doing it right.
Any help is appreciated.
It might be the same issue, if the initial one was indeed solved. The thing with the previous solution is that it acts just once, at skin load. Now, I can't recall if the FileView measures get momentarily empty (internally?) between the moment of following a path and the one of getting the new values (i.e. after the skin load), but if so, disabling the FreeDiskSpace measures right before the bang that triggers FileView to follow a new path could fix this "new" issue.
Bottom line, cycle of disabling FreeDiskSpace right before FileView goes to retrieve its data and enabling FreeDiskSpace right after the FileView data is retrieved might need to happen each time a new path is followed, instead of only at skin load time. I might be wrong here, of course, as this assumes you correctly followed the steps mentioned by balala earlier.
Yincognito wrote: ↑November 2nd, 2024, 8:04 am
It might be the same issue, if the initial one was indeed solved. The thing with the previous solution is that it acts just once, at skin load. Now, I can't recall if the FileView measures get momentarily empty (internally?) between the moment of following a path and the one of getting the new values (i.e. after the skin load), but if so, disabling the FreeDiskSpace measures right before the bang that triggers FileView to follow a new path could fix this "new" issue.
Bottom line, cycle of disabling FreeDiskSpace right before FileView goes to retrieve its data and enabling FreeDiskSpace right after the FileView data is retrieved might need to happen each time a new path is followed, instead of only at skin load time. I might be wrong here, of course, as this assumes you correctly followed the steps mentioned by balala earlier.
Ok, I definitely got balala's solution working the way he described - it is for lack of a better word spot on.
I tried IfMatch=0 and IfMatchAction disabling the measures. It didn't seem to work but I might not be using the actual measure calling the FreeDIskSpace output.
There are these measures preceeding the ones balala's method worked on. But it isn't working - so far.:
Not sure if that might be part of the solution since them being disabled before the mPath execures its FinishAction=[!EnableMeasureGroup] or that may be why it isnt working.
I think there may be a substitute option, but I dont know what that would look like.a
I think I am missing out on the correct application of the disabled=1 method.
EDIT: I just tried to accessan ampty folder and the empty error went blockko cycling.
CodeCode wrote: ↑November 2nd, 2024, 8:47 am
Ok, I definitely got balala's solution working the way he described - it is for lack of a better word spot on.
Forget my previous reply above, I was wrong. Didn't check your code, but in a simple one like the below, there's no need to disable the FreeDiskSpace measures, just Substitute any empty string values of the FileView measures with, say, a space or something (see the ElementNameN measures):
That being said, the drive infos will NOT be retrieved as expected if the value of the Drive= option in the FreeDiskSpace measure is more than just "<Drive>:" or "<Drive>:\", so if you want to get that info for any path, you'll need to have additional String measures that remove the part after the first "\" from the values of the FileView measures to leave only the drive letter followed by ":" and pass that to the FreeDiskSpace measures (those String measures will have to be updated when the FileView measures are updated, obviously). Even more so, it doesn't make any sense to do this for every FileView index, doing it for only the FileView parent is enough since those indexes belong to the same path anyway (see the FolderDrive and DriveLabel measures below):
Yincognito wrote: ↑November 2nd, 2024, 9:09 am
Forget my previous reply above, I was wrong. Didn't check your code, but in a simple one like the below, there's no need to disable the FreeDiskSpace measures, just Substitute any empty string values of the FileView measures with, say, a space or something (see the ElementNameN measures):
That being said, the drive infos will NOT be retrieved as expected if the value of the Drive= option in the FreeDiskSpace measure is more than just "<Drive>:" or "<Drive>:\", so if you want to get that info for any path, you'll need to have additional String measures that remove the part after the first "\" from the values of the FileView measures to leave only the drive letter followed by ":" and pass that to the FreeDiskSpace measures (those String measures will have to be updated when the FileView measures are updated, obviously). Even more so, it doesn't make any sense to do this for every FileView index, doing it for only the FileView parent is enough since those indexes belong to the same path anyway (see the FolderDrive and DriveLabel measures below):
Adapting the ideas above to your skin is up to you.
These are intuitive options but working them into the code I have to work with, would either require me to re write the entire skin, or from what I have gotten for result - is not working and the freediskspace empty message just spams forever no matter how many files are in the folder.