LeftMouseDownAction Execute

[Yincognito]

Hello, sorry I didn't answer earlier.
Yes the problem has been solved.
Another problem arose but I didn't have time to deal with it until today.

With the name of a file I created this code to recover its extension:

Code: Select all

[CalculeLNKtoEXTIMG2]
Measure=Plugin
Plugin=FileView3
Path=[MeasureFolderEXTIMG]
Type=FileName
Index=2
IfMatch=.*jpg.*
IfMatchAction=[!SetOption EXT2 String ".jpg"]
IfMatch2=.*jpeg.*
IfMatchAction2=[!SetOption EXT2 String ".jpeg"]
IfMatch3=.*png.*
IfMatchAction3=[!SetOption EXT2 String ".png"]
IfMatchMode=1
DynamicVariables=1

However for some reason that escapes me, "EXT2" is not equal to one of the extensions (.jpg, .jpeg or .png) but to the name of the entire file ...

So:
- you have a typo (syntax mistake) in the Plugin option of the posted measure, I'll let you figure out what that is
- once you correct the typo, it will most likely work, assuming you don't do other things conflicting with the !SetOption in the EXT2 measure
- that being said, the regex patterns used in the IfMatches are kind of loose, some better ones would be, say, \.jpg$ and such, in order to match the occurence of an ".EXTENSION" pattern at the end of the string (in the pattern, \. is a literal . since it's escaped by the preceding \, and $ means the end of the string)
- it is advisable (but not absolutely required, it depends on your needs) to add an [!UpdateMeasure EXT2], and possibly even a [!UpdateMeter *][!Redraw] bang sequence after each !SetOption bang, in order to speed up the process and update to the new values "right now", as opposed to "on the next update" as it is now
- on top of all that, these IfMatches aren't even needed, since one can get the extension by removing or commenting the said IfMatches and simply use the "built-in" way in the FileView plugin, i.e. the FileType option in the target measure, like:

Code: Select all

[EXT2]
Measure=Plugin
Plugin=FileView
Path=[MeasureFolderEXTIMG]
Type=FileType
Index=2

A bit more care with the typos and some quick reading on the FileView page in the manual and the solution would have been within reach. I'm not sure if it happens or not, but folks need not to be scared of reading the manual, after all, you don't have to read the entire page, only what interests you (in this case, the FileType part, which is like 2 lines at most).

[jsmorley]

So:
- that being said, the regex patterns used in the IfMatches are kind of loose, some better ones would be, say, \.jpg$ and such, in order to match the occurence of an ".EXTENSION" pattern at the end of the string (in the pattern, \. is a literal . since it's escaped by the preceding \, and $ means the end of the string)

I agree with this, since in theory you could have a file named MyFile.txt.jpg or some other weird combination, and it is best to look for the "last" instance of a . followed by some characters.

[Yincognito]

I agree with this, since in theory you could have a file named MyFile.txt.jpg or some other weird combination, and it is best to look for the "last" instance of a . followed by some characters.

Yep, that was my line of thought as well.

[Honimoura]

Indeed I did not know the "filetype" which now makes my formula obsolete. But know all the same that even by changing "filename" by "filetype" the formula gives me the type of file (here "jpg") and not what I ask it to enter as value (".jpg") .. .
But thanks for the help.

[jsmorley]

Indeed I did not know the "filetype" which now makes my formula obsolete. But know all the same that even by changing "filename" by "filetype" the formula gives me the type of file (here "jpg") and not what I ask it to enter as value (".jpg") .. .
But thanks for the help.

You could do this:

Code: Select all

[EXT2]
Measure=Plugin
Plugin=FileView
Path=[MeasureFolderEXTIMG]
Type=FileType
Index=2
RegExpSubstitute=1
Substitute="(.*)":".\1"

That will just tack a . on to the beginning of the string.

[Honimoura]

Yes yes, I just wanted to show that the formula was not writing the result ifmatch but just returning the type of the file.

[Yincognito]

Indeed I did not know the "filetype" which now makes my formula obsolete. But know all the same that even by changing "filename" by "filetype" the formula gives me the type of file (here "jpg") and not what I ask it to enter as value (".jpg") .. .
But thanks for the help.

You're right. I actually suspected that you wanted the dot in front of the extension so had some doubts whether to post or not the alternative, but as jsmorley pointed out, adding the dot is trivial anyway. You don't even need a susbstitute in some cases, in fact. It depends on your usage scenario, but you could even add the dot "on the fly" in whatever option you need it. For example:
[!SetOption SomeOtherMeasure ".[EXT2]"] or
[!SetOption SomeFileExtName "[SomeFileName].[EXT2]"] or
in a meter, Text=".[EXT2]" or
also in a meter, Text=".%1" (assuming MeasureName=EXT2 in that meter)
and so on...

Point is (pun intended), it's just a point/dot. Adding it before the extension is not difficult at all. If you think it is, you could very well stick with your IfMatch implementation, which, bar the harmless typo, it works. After that, improving the regex patterns you use is entirely your decision, depending on how "bullet-proof" you want the solution to be.

[Honimoura]

I am still wondering if for you my typo error was the filename instead of filetype or because fileView had a number "3"? Because by rectifying the filename in filetype the ifmatch problem remained the same. And the "fileview3" was not an error but quite voluntary. Because if fileview performs several scans in a row like here (shortcut scan of games, scan of game images, scan of shortcut extensions (url or lnk) and scan of image extension (jpg, jpeg or png)) then this gives the same value has all variables which will be modified for all scans. So I had to copy / paste fileview.dll to create several. In this way, each of the plugins performs its own scan without interfering with the others. Therefore, the two "errors" are not guilty of the dysfunction of the formula previously used ...
The malfunction is no longer disturbing now that another method is used, but is not resolved if you see where it is

[Yincognito]

I am still wondering if for you my typo error was the filename instead of filetype or because fileView had a number "3"? Because by rectifying the filename in filetype the ifmatch problem remained the same. And the "fileview3" was not an error but quite voluntary. Because if fileview performs several scans in a row like here (shortcut scan of games, scan of game images, scan of shortcut extensions (url or lnk) and scan of image extension (jpg, jpeg or png)) then this gives the same value has all variables which will be modified for all scans. So I had to copy / paste fileview.dll to create several. In this way, each of the plugins performs its own scan without interfering with the others. Therefore, the two "errors" are not guilty of the dysfunction of the formula previously used ...
The malfunction is no longer disturbing now that another method is used, but is not resolved if you see where it is

Yeah, I meant the "3" after "FileView" when I was talking about the typo. I didn't know of your replication of the plugin's DLL, that's quite a creative solution you found to separate scans - I'm curious if it has any downsides / disadvantages though. Anyway, in all fairness you should have mentioned the duplication of the DLL, because on my system and test skin, removing the "3" after "FileView" fixed the issue (I post the test skin exactly as it was at the time of testing, bar the username in [MeasureFolderEXTIMG]'s Path option; I used the skin's own name, i.e. Test.ini in the test):

Code: Select all

[Variables]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[MeasureFolderEXTIMG]
Measure=Plugin
Plugin=FileView
Path="C:\Users\[User]\Documents\Rainmeter\Skins\Test"
ShowDotDot=0
ShowFolder=0
Count=3

[CalculeLNKtoEXTIMG2]
Measure=Plugin
Plugin=FileView
Path=[MeasureFolderEXTIMG]
Type=FileName
Index=1
IfMatch=\.jpg$
IfMatchAction=[!SetOption EXT2 String ".jpg"]
;[!UpdateMeasure EXT2]
IfMatch2=\.jpeg$
IfMatchAction2=[!SetOption EXT2 String ".jpeg"]
;[!UpdateMeasure EXT2]
IfMatch3=\.png$
IfMatchAction3=[!SetOption EXT2 String ".png"]
;[!UpdateMeasure EXT2]
IfMatch4=\.ini$
IfMatchAction4=[!SetOption EXT2 String ".ini"]
;[!UpdateMeasure EXT2]
IfMatchMode=1
DynamicVariables=1

[EXT2]
Measure=String
String=

; [EXT2]
; Measure=Plugin
; Plugin=FileView
; Path=[MeasureFolderEXTIMG]
; Type=FileType
; Index=1

---Meters---

[MeterTest]
Meter=STRING
X=0
Y=0
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=EXT2
Text="Test = %1"
DynamicVariables=1

Test.jpg

If you remember, I mentioned in my initial reply that this will work

assuming you don't do other things conflicting with the !SetOption in the EXT2 measure

What I meant by that is you could have had some other process in your measures or meters that interfered with setting that option properly. As usual, such solutions will work in clean codes built from 0, but they might not work from a first attempt in a more complex coding environment (like an already built skin) and need some other tweaks to integrate it all into a working whole.

That's why most of the folks here providing help ask for the complete code when offering a solution, because in some cases it really matters since there are multiple operations going on in a full fledged skin (or skins) and you can't guarantee the provided solution will "fit in" well with the already existing code, especially if you didn't see it before. Me, I don't usually ask for the whole code like the other guys, because I assume that people asking for help will realize that they need to adapt the solution to their specific scenario - after all, it's only natural to be that way.

That being said, you said you used another method to workaround this, and that the "issue" was someplace else entirely. Care to ellaborate on that? Just curious...

EDIT: Thinking about the DLL replication method ... are you sure it was really necessary? I mean, couldn't multiple measures FileView measures (obviously adapted for the desired extension/file/whatever) achieve the same thing? Because I really think the latter method would have been not only easier to implement, but also "safer" and more in line with the already existing capabilities of a Rainmeter plugin (or measure, for that matter)...