View Issue Details

IDProjectCategoryView StatusLast Update
0007221MMW v4Reports/Scriptspublic2011-02-13 21:16
Reporterjiri Assigned To 
PriorityurgentSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
PlatformWindowsOS7OS Version-
Product Version3.2.4 
Target Version4.0Fixed in Version4.0 
Summary0007221: Scripting: Add methods for modifying internal MM variables.
DescriptionScripters sometimes want to modify some internal MM variables. We could create a lot of COM properties for them, but that would probably be a lot of work, but there seems to be an easier solution: Introduce two methods, GetINIFileContent and SetINIFileContent. These methods would read/write in-memory strings containing values that we have internally in MM ini file. Specifically:

1. GetINIFileContent would return a string containing the whole content of MM.ini file (based on actual values in memory).
2. SetINIFileContent( newvalues as String) would update variables based on given new values. It could contain just partial ini file, for example:

[CustomFields]
Fld1Name=New name

Note that for correct functionality after such changes it would be necessary to refresh many things internally. We can try to do at least some, for example at least a refresh of content of track lists (for example in case user would like to update Summary field mask).
TagsNo tags attached.
Fixed in build1346

Relationships

related to 0007220 closedLudek Limited Summary mask length 

Activities

zvezdan

2011-01-22 16:59

updater   ~0022536

I am not sure that understand your suggestion. We already have the SDBIniFile object which allows us to read and write some keys from .ini file, even the entire sections using the Keys property.

Using some new method which will return whole .ini file as one string you are actually making usage harder for scripters since they would need to parse such string to be able to read and change some specific key/variable. I think such task is better to be done in the program itself.

However, we need a possibility to tell the program that .ini file is changed and that it should update its internal variables and refresh its display in the tracklist and NP based on some specific key value(s) in .ini file. For example, you could add a method to update a variable related to Some_Ini_Key using: RefreshIniVariable("Some_Ini_Section", "Some_Ini_Key").

Ludek

2011-01-24 14:13

developer   ~0022556

Last edited: 2011-01-24 14:15

I tend to Zvezdan that adding something like
ISDBIniFile::RefreshIniVariable("Some_Ini_Section", "Some_Ini_Key")
would be better.

The question is whether RefreshIniVariable is the best name, maybe something like
ReLoadIniVariable or ApplyIniVariable would be better?

Ludek

2011-01-24 16:59

developer   ~0022558

Last edited: 2011-01-24 17:06

Thinking about it and looking at http://www.mediamonkey.com/wiki/index.php/SDBIniFile
there probably isn't a need for the RefreshIniVariable method

We could just add ISDBIniFile::Apply method that would be similar to ISDBIniFile::Flush, but unlike Flush it would also apply the changes internally in MM.

The only problem is that user might change something in MediaMonkey and therefore we should save the actual state at first when creating ISDBIniFile instance in order to get the most current data.

jiri

2011-01-25 13:06

administrator   ~0022609

There are certainly several way of how to implement it. My original suggestion treats properly any possible issues with conflicts of values in ini and in memory.

Similar solution that would work as well is to add methods like:
SaveOptionsToIni() and LoadOptionsFromIni(). In order to prevent conflicts, a scripter would call SaveOptionsToIni(), update values in the ini and call LoadOptionsFromIni(). Note that I wouldn't like to support of refreshing of only particular variables, but rather only the whole ini. The reason is that it would mean more work (with more possible bugs).

zvezdan

2011-01-25 13:42

updater   ~0022617

OK, we don't need to refresh some particular variable, but as I see it Ludek's last suggestion with Apply method means that all variables are updated at once.

However, I need to repeat that you should make scripting API as easier as possible for scripters, not for you developers. In my opinion you already made to much trouble introducing the Flush method. I think that scripters should not worry about such things as when application should update .ini file (Flush) or its internal variables (Apply) - this is something which the application should do behind the scene.

jiri

2011-01-25 14:25

administrator   ~0022618

Well, as for Flush(), this methods is by no means mandatory, it's there just for an additional security of saving Options even in case of crash (of MM, system or whatever). I can't imagine any other reasonable solution (we don't want to save ini file after any single change).

re. Apply() - well, we could try to do without it (i.e. update everything on the background automatically), I'm just afraid that in some cases scripters might want to modify two variables that are related in some way (some UI setting?) and a refresh of MM after the first change would trigger undesired effects before the second change would even occur. For that reason, I think that an additional method is a preferred solution.

zvezdan

2011-01-25 15:15

updater   ~0022619

I don't mind of using Apply method, but I don't like to use some method to read/write all .ini file from/to string and to parse it just to be able to read/write some particular variable and to inform MM about its modification. For me it is more naturally to use one or more existing SDB.IniFile.StringValue methods to store values to the .ini file and after that to use some new Apply method.

RE. Flush(), I am not using that method at all. I didn't try lately, but here is my earlier observation about it. I remember you are saying somewhere in the Forum if we directly use SDB.IniFile.StringValue methods that values are stored immediately in the .ini file, but if we use some temporary object variable e.g. Set oIniFile = SDB.IniFile and after that oIniFile.StringValue, such changes are written to the .ini file only after Flush or on the application's regular end. OK, because of that I am using SDB.IniFile.StringValue syntax, but here is another problem. There are some scripts from another author which has line: Set oIniFile = SDB.IniFile on the global level, i.e. outside of any function/subroutine. Because of that script and that line, my scripts are not saving values to the .ini file immediately, but only on the application ends. Could you explain why is that?

zvezdan

2011-01-25 16:12

updater   ~0022621

Is there any chance that you add Apply method to the SDBRegistry object as well? You see, I need a possibility to modify tracklist layout for specific nodes (visibility and order of particular columns). There are values in the registry representing columns, but using SDBRegistry methods to change them, nothing is happening. I suggested Columns/Column object to be able to modify tracklist layout (http://www.ventismedia.com/mantis/view.php?id=6722), but I suppose that I could do the same thing if you implement SDBRegistry::Apply.

Ludek

2011-01-25 16:38

developer   ~0022622

Last edited: 2011-01-25 16:39

We will move most of registry variables from registry to INI, see http://www.ventismedia.com/mantis/view.php?id=2439#c22599

Ludek

2011-01-28 15:04

developer   ~0022685

Fixed in build 1346: http://www.mediamonkey.com/wiki/index.php/ISDBIniFile::Apply

peke

2011-02-13 21:16

developer   ~0023045

Verified 1348