Issue with OnAfterFolderChange Script

Help & Support
1

I have a problem with the following script. It shows a toolbar when entering folders containg MP3 files and closes the toolbar when entering a folder without MP3 files. When the toolbar is currently shown and I enter a folder containing more than 4 subfolders and no MP3 files (e.g. C:\ or /programfiles) the toolbar stays open. Is there something wrong with my code or is it a bug?

Option Explicit

Function OnInit(initData)
	initData.name = "PlayerTest"
	initData.default_enable = true
End Function

Function OnAfterFolderChange(afterFolderChangeData)
	Dim cmd
	Set cmd = DOpus.Create.Command
    Dim test
    For Each test in afterFolderChangeData.tab.files
		If (test.ext = ".mp3") Then
	        cmd.RunCommand "Toolbar NAME=PlayerTest STATE=center"
	        Exit Function
        End If
    Next
    	cmd.RunCommand "Toolbar NAME=PlayerTest CLOSE"
End Function
2

You need cmd.SetSourceTab afterFolderChangeData.tab to tell the command object you have created which lister/folder tab it is working on, otherwise it may pick a different one and try to open or close the toolbar in that.

3

Problem solved!
After deactivating other scripts I could track down the issue to a conflict with one of tbone's scripts: Event: OverrideFormats (..or viewmodes on folder change)

4

This is probably because of OverrideFormats using the NOSCRIPT switch for the Go command.
You can leave OverrideFormats active, if you make sure it does not override the view or format for the folders containing your mp3 files, as Go NOSCRIPT will not be used in this case and your specific OnAfterFolderChange script should be triggered as expected.

I guess the NOSCRIPT switch was meant to prevent loops in the event-chain, unfortunately it does break other script addins.
So what about passing an script/event-specific identifier to the Go command, which is accessible in the resulting event-object? That way each script can determine if an OnAfterFolderChange (or similar) event was triggered by itself and quit without re-doing what has been done already.

The NOSCRIPT switch is kind of an emergeny brake, too much for most situations as it also disables events, that can still be fired without doing any harm. Kundals toolbar switcher is a nice example and some addins of mine are too. Currently they try to work around that limitation by calling a maintained list of script-commands after handling the event, which just wrap what is actually to be done in the event-handler of the script-addin they belong to.

The DoubleClick event also has problems if multiple addins make use of it, so maybe it's worth thinking about tearing down these barriers?
Thoughts welcome.. o)