New handling of script instances

[jiri]

Although it probably won't affect many scripts and their authors, I rather announce a small change introduced in MM 3.1.0.1205: Each script will only have one instance in memory, unlike in previous versions, where it was possible to have several instanced loaded under some conditions. I added some info about it to wiki at http://www.mediamonkey.com/wiki/index.p ... pt_loading , its copy follows below.

Let me know in case of any troubles.

Jiri

Internal mechanism of script loading
Normally, you don't need to know much about internal handling of scripts by MediaMonkey, but sometimes it might be useful to know, when exactly scripts are loaded.

When some function of a script is about to be executed (e.g. OnStartup function of auto-scripts), the script is loaded to memory and executed as necessary. When the execution finishes, the script is again unloaded from memory. However, there is on exception - if you register some event (by calling RegisterEvent function), the script remains still loaded in memory, until all registered events are unregistered, then it's unloaded.

This is good to know when you plan some sharing of variables. While the script is loaded in memory, you can use its global variables, but if you need to persist some values or objects between script sessions, you have to use some other mechanism (ini files, Objects collection, ...).

Note that starting from MediaMonkey 3.1.0.1205, there is always at most one instance of script loaded in memory. In older versions, if a script registered some events and then e.g. Option sheet functions were called back by MediaMonkey, they were processed in another instance of the script. Now they are processed in the already loaded instance, which helps avoid some memory leaks, is easier to handle and is also faster to process.

[MoDementia]

This is great news, I know I have had to write code to get around this issue previously. Hopefully the workarounds still function correctly
Even if they do it will be worth while fixing them to take advantage of this change.

[ZvezdanD]

Well, I suppose this is a great news, but there are some troubles with it, most notably when we developing some script. With old MM versions if I change something in the script when I enter some dialog box it would be executed a new, modified version of the script. Now, I need to restart MediaMonkey whenever I change something in the script to see how changes are reflecting. Jiri, this was one more reason why I used oMenu.OnClickFunc instead of Script.RegisterEvent oMenu, "OnClick", "...".

Maybe you should make an option to disable such new behavior, or at least to enable old way with multiple instances in a Debug version of MM.

[jiri]

I can see that it makes testing harder, but making the behaviour option would probably cause more bad than good. Maybe there could be added some way how to easily force MM to reload all loaded scripts, so that it isn't necessary to restart it for this purpose. I'm not sure, how to do this though - maybe to add a COM method for this and a script author could install a script, that would add toolbar button calling this method - i.e. script refresh in memory would need just one mouse click.

Jiri

[Teknojnky]

I like that idea.

From Jiri's original post, it seems that you can have a method un-register all events to unload the script from memory, then you could manually run the init/startup method to re-register after making changes.

[ZvezdanD]

Actually, I don't want to execute OnStartup again, nor to unregister and register event handlers again. For example, with old MM versions when I change something in the script within dialog procedure, it is enough to enter into this dialog and to see changes made on it. Also, when I change something in the node code (Magic Nodes), it is enough to collapse/expand main branch to see changes on its sub-nodes. But, if I unregister all event handlers, all nodes are disappearing even if I want just to change something into dialog procedure, not into node procedure.

Well, never mind. I will stay with 3.0 for script development.

[jiri]

I will stay with 3.0 for script development.

That would be a pity, I think. What I proposed in my previous post would perfectly solve your problem, wouldn't it?

Jiri

[ZvezdanD]

What I proposed in my previous post would perfectly solve your problem, wouldn't it?

I am not sure. I don't know what you mean by "reload all loaded scripts" and "script refresh in memory", but if this means that OnStartup is executed and all event handlers are unregistered/registered again, than I cannot use it. Here is just one example from Magic Nodes - I have dialog box where I can create/delete custom nodes; if I want to make some small change on this dialog, e.g. to move some control to another place and to see how it will look with that modification, if I choose unregister all events all my previously created nodes will disappear which I don't want. I know this happens since I tried it when have been finding my way to resolve memory leaks. Well, maybe I could solve this with some complicated code, but it is easier for me to continue development with an older MM version.

However, if your newly introduced method could reload just some parts of the script, without execution of OnStartup and unregistering all event handlers, then I'd be glad to use it.

[jiri]

It would only cause that all global variable of the script would be lost (i.e. re-initialized). However, as I think about it, it probably isn't the best idea, it wouldn't help that much and possibly rather cause problems. So, let's rather leave it as is, unless we find some better solution...

Jiri

[Big_Berny]

Yes, would be very nice if this could be changed in the next build again. I just installed 1207 and wanted to work on optionsheets which is a real pain like this... Downgraded to 1204 for now.

[Bex]

Yes, to implement something which solves this would be very nice since developing scripts is now really time consuming.

[Teknojnky]

I was doing some testing and yea, this new behavior is very difficult for script development and testing changes.

[Bex]

What about to implement a new "property" SDB.DevelopingMode(True/False) which sets the script to a Developing Mode. In that mode all Subs/Functions should be reread from the script file when executed thus making a restart unnecessary.
If SDB.DevelopingMode=True then some sorts of warning should pop up on starting the script which would prevent users from using it if a developer forgets to set SDB.DevelopingMode=False.

Is that possible to implement?

[Teknojnky]

A DevMode that would disable all script caching would be great.

I have to veto the warning pop up tho, pop up dialogs are just extremely annoying and that would almost as bad as having to constantly re-start MM in the first place.

Ideally the devmode property should be on a per script basis, but a global devmode would be sufficient as well.

[Bex]

1. It would only pop-up once per restart. Something like:

Code: Select all

Script "Vbs filename goes here" is in Developing Mode. If that is unexpected, Do Not use the script and please notify the script author!

But is there another way to alert the normal user that he is using a script that is in developing mode, if the developer misses to change the property?

2. Yes that was what I meant. E.g the developer just adds SDB.DevelopingMode=True in the top of the script to make it behave differently.