Script Helper Methods

Post a reply


In an effort to prevent automatic submissions, we require that you complete the following challenge.
Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Script Helper Methods

Re: Script Helper Methods

by winchendonsprings » Sat May 16, 2009 2:03 pm

i cannot get this script to install. you should do a step but step installation how to.
I think this script should be stock with MM.
how often do you end up with a compilation split up by artist instead of album.

EDIT: nevermind I went back and payed closer attention. thanks great script

by judas » Wed Feb 01, 2006 9:17 am

trixmoto wrote: I thinik most script users (who are not script writers) prefer to have a single script file as it is easier for them to install.
Personally, I'm one of those (maybe?) :-) I've always liked the way Apple OS works...just drag and drop ONE file and there you go: program installed, so maybe this is something like that!.

This might be the most stupid thing in scripting terms youve hear but, seeing all you guys can do from a script, would it be hard if you:

1. Write a script assuming there are such libraries (as proposed in this forum)
2. Run a script (possible? no idea here) that just starts the script and then copies the function needed from the library in the right place
3. Post the new script...that's self contained!!

maybe is really hard to do, dont't know...but that would make it easy on you writing the script and wouldn't hurt usability nor ease of use (same thing?) for the common people like me?

if this is not possible to do (the script that copies functions), or is not what youre asking or makes things more complicated, then just ignore this!!!

CHEERS!!!


judas

by psyXonova » Wed Feb 01, 2006 3:57 am

I guess this is something that only one of the developers can answer. I also think that selecting ini based on the file size it is too risky. Perhaps it has something to do with the stored info inside. I have also checked the registry to see if i can come up with something but no luck. So, it must be the system section.

As for your idea Steegy i couldnt agree more with you, i strogly believe that using common vbs as "libraries" will help us all.

by Steegy » Tue Jan 31, 2006 5:22 pm

Then this will be the new code:

Code: Select all

' Returns the path to MediaMonkey's configuration (ini) file or "" if it doesn't exist
Function GetINIPath()

  GetINIPath = ""
  Dim INIPath_MyMusic, INIPath_Program, FSO

  INIPath_MyMusic = SDB.MyMusicPath & "MediaMonkey\MediaMonkey.ini"
  INIPath_Program = SDB.ApplicationPath & "MediaMonkey.ini"
  Set FSO = CreateObject("Scripting.FileSystemObject") 

  If FSO.FileExists(INIPath_MyMusic) Then
    GetINIPath = INIPath_MyMusic
  Else
    If FSO.FileExists(INIPath_Program) Then
       GetINIPath = INIPath_Program
    End If
  End If
   
End Function
Cheers
Steegy

by jiri » Tue Jan 31, 2006 4:36 pm

At first 'My Music\MediaMonkey' folder is checked, then 'Program Files\MediaMonkey' is used.

Jiri

by trixmoto » Tue Jan 31, 2006 4:33 pm

Can a MM developer help us out here please? We're going in circles!

by Teknojnky » Tue Jan 31, 2006 4:01 pm

I beleive it checks the my music folder, as I have had it happen where previously existing profile had a mm ini in the my music folder and it took prioirty over the mm ini in the program folder.

by Steegy » Tue Jan 31, 2006 3:40 pm

OK, I just refreshed my Readme-knowledge:
If you wish to share MediaMonkey's configuration file and or database among multiple users:
i) Move the MediaMonkey.ini file to the \Program Files\MediaMonkey directory.
The comparation of file sizes between different ini files can't be the right way. If you copy MyMusicINI to ProgramINI and then delete your 100 magic nodes, the ProgramINI files would be smaller than the other one. Therefor, the script would "detect" MyMusicINI as larger and would use that one. But that is wrong because MediaMonkey would be using the ProgramINI one.

How does MediaMonkey decide which INI to use? Does it first check the INI in the program folder for the [system] section? And if it doesn't find the [system] section, it uses the one in MyMusic subfolder?

Cheers
Steegy

by trixmoto » Tue Jan 31, 2006 1:28 pm

I don't have a My Music folder, so this wouldn't work for me. I don't even have a MediaMonkey.ini file on my computer. Mine is stored here: "F:\Applications\MediaMonkey\MediaMonkey.ini"

If you create MediaMonkey.ini in the same folder as your MediaMonkey.exe then this one will override the one in your my music folder. Presumably on a key-by-key basis. But I just moved the .ini file and a new one was never created in my music, but the one in the program folder is always updating.

by Steegy » Tue Jan 31, 2006 12:34 pm

Re. Ini file - the real ini file is stored in My Music\MediaMonkey folder, those created in MM folder are created by WinAmp compatible plug-ins (they use MM executable name as the base name for their .ini file and thus there are separate versions for skinned and non-skinned MM).
So what I'm been told about "use the one with the biggest size" and the "shared environment" stuff isn't true? We should only use the SDB.MyMusicPath & "MediaMonkey\MediaMonkey.ini" one then?

Cheers
Steegy

by Teknojnky » Tue Jan 31, 2006 11:34 am

I wish MM would store all configuration data within its program directory instead of using the windows method of storing them in the user profiles.

Ideally, you could still keep separate user ini files, under a mediamonkey\user folder if so desired.

this would help imensely those who run MM from a shared location, like a network drive or an external drive/mp3 player.

by trixmoto » Tue Jan 31, 2006 10:39 am

Personally I have a long text file with useful methods which I use, but I always copy and paste them into a script if I need them. I thinik most script users (who are not script writers) prefer to have a single script file as it is easier for them to install.

The ini path function is definitely better now as it should always find the main ini file.

by jiri » Tue Jan 31, 2006 10:22 am

Re. Ini file - the real ini file is stored in My Music\MediaMonkey folder, those created in MM folder are created by WinAmp compatible plug-ins (they use MM executable name as the base name for their .ini file and thus there are separate versions for skinned and non-skinned MM).

Re. Script.Include - it wouldn't help much to load only one method from a file, the main tasks (read content of the file and parse the file in order to find the function) would have to be done anyway. The delay won't be terrible, I just wanted to warn scripters to not include several thousands lines of scripts in each script they write.

Jiri

by Steegy » Tue Jan 31, 2006 9:46 am

@Trixmoto and other scripters

Is this better?

Code: Select all

' Returns the path to MediaMonkey's configuration (ini) file or "" if it doesn't exist
Function GetINIPath()

  GetINIPath = ""
  Dim FoundININumber, INIPath_MyMusic, INIPath_Program, FSO

  FoundININumber = 0
  INIPath_MyMusic = SDB.MyMusicPath & "MediaMonkey\MediaMonkey.ini"
  INIPath_Program = SDB.ApplicationPath & "MediaMonkey.ini"
  Set FSO = CreateObject("Scripting.FileSystemObject")

  If FSO.FileExists(INIPath_MyMusic) Then FoundININumber = FoundININumber + 1
  If FSO.FileExists(INIPath_Program) Then FoundININumber = FoundININumber + 2

  Select Case FoundININumber
    Case 1:
      GetINIPath = INIPath_MyMusic
    Case 2:
      GetINIPath = INIPath_Program
    Case 3:
      If FSO.GetFile(INIPath_MyMusic).Size > FSO.GetFile(INIPath_Program).Size Then 
        GetINIPath = INIPath_MyMusic
      Else 
        GetINIPath = INIPath_Program
      End If
  End Select
   
End Function

To the dev's:
Why does MediaMonkey use a different program folder INI configuration file for the skinned and the non-skinned version? Do we need to use both (e.g. in the above function)? The INI filenames are made out of the filename of the MediaMonkey executable. Is there an easy way to get this executable filename (or don't we have to bother and always use "MediaMonkey.ini")?

Cheers
Steegy

by Steegy » Tue Jan 31, 2006 9:07 am

@psyxonova
See a new script SwitchFields http://www.mediamonkey.com/forum/viewtopic.php?t=7920 where I use this. (see imports section + it uses one function written at the end of the file)
This is only a "preview" what means that I wanted to share the idea and invite all scripters to add (and improve) functionality of these helper scripts. I suppose we'd better wait with using this concept extensively, until these helper files are "approved" and contain more useful things.
I think it would be the best if we all use the same helper scripts (e.g. "Utility_General.vbs" and "Utility_SQL.vbs", ...) instead of all having us own (e.g. "HelperScript_Psyxonova.vbs", "TrixmotoHelpers.vbs", "SteegyUtility.vbs", ...) what would cause a lot of problems, instead of making things better, imho.

@jiri
I suppose this Script.Include method does the same thing of what I am doing in my SwitchFields script?
Actually, I had something in my mind so you could let MediaMonkey make references to helper methods.
E.g. if helper script "Utility_General.vbs" contains a function GetIniFile(), then you could use something like
Script.Use "Utility_General.vbs", "GetIniFile"
Then, everytime GetIniFile is used in the program, it would executed the referenced code in the "Utility_General.vbs" file. (instead of including the whole script file as it is now). That would work much faster.
It might even be better if we could use "Gen.GetIniFile" (where "Gen" indicated a class) so there would be less problems with
naming collisions and methods would be easier to recognise. (e.g. SQL.OpenDatabaseConnection("MyDB.mdb") )
Any way, with referenced scripts, it should also be possible for one referenced method to use another (not referenced) method in the same helper file.

This is probably much too difficult to create, but it would be very cool and would make helper scripts useful without extra overhead.

Anyway, thank you very much for responding so fast and to implement this first method! You really are helping scripting for MM a lot (with this, with added menu references, new events, ...) :D

Cheers
Steegy

Top