View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007221 | MMW v4 | Reports/Scripts | public | 2011-01-22 14:45 | 2011-02-13 21:16 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | Windows | OS | 7 | OS Version | - |
| Product Version | 3.2.4 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0007221: Scripting: Add methods for modifying internal MM variables. | ||||
| Description | Scripters 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). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1346 | ||||
|
|
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"). |
|
|
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? |
|
|
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. |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
We will move most of registry variables from registry to INI, see http://www.ventismedia.com/mantis/view.php?id=2439#c22599 |
|
|
Fixed in build 1346: http://www.mediamonkey.com/wiki/index.php/ISDBIniFile::Apply |
|
|
Verified 1348 |
