@willblackhurst Finally got a chance to finish this up. Got it working as an abstraction and added a few other features for both save and open dialogs. Also has the nice side effect that each instance remembers where in the file system it was when last used so decreases some of the headaches of [openpanel] and [savepanel]. Think I got all the bugs out. Requires [hcs/sys_gui] and a recent enough version of pd to have [file splitname].
spanel_opanel.zip

@KMETE [file patchpath]

@KMETE I did not implement the file playing, just the random file stuff but I think this should do you assuming you are using a somewhat recent pd. Added a toggle to delete the file from the list if you want it to never play the file a second time, wasn't sure if you wanted to avoid repeats or avoid ever playing a file twice.
rnd-file.pd

@rph-r You sure it doesn't store like the original? Just redownloaded it and it seems to work for me. The right inlet is just a [send] which sends to all the internal [list store]s right inlets, while that send is also used for the internal logic that internal logic is quite simple and I can not think of a situation where it would fail. Check again and if it still fails redownload to make sure nothing corrupted, if it still fails upload a patch demonstrating the failure so I can fix it.

@rph-r Forgot that [list store] was a much simpler object in 0.51, https://forum.pdpatchrepo.info/topic/14432/equivalent-of-list-store-insert-delete-pre-pd-0-52/2 is an abstraction that implements the methods added to [list store] in 0.52. Always forget about this.

Edit: You could also use [text] or [array] instead of [list store]

@willblackhurst Actually we can do it without a plugin.
sp-abs.pd

But dealing with tcl's nested lists in pd is a pain because of the lack of curly braces. This may not be a problem if you are not worried about have a drop down list of file types to choose from and can set the type before opening the panel. Would be easier to deal with as a plugin. [list [list pd [list .pd]]] in the set message can be edited for type or types, [list [list audio [list .wav .aiff]]] would just give you .wav and .aiff types. Not quite an abstraction despite what the name suggests, I realized that formatting the lists would be a pain and decided not to bother, will make a plugin version later.

@willblackhurst From what I can see the [savepanel] and [openpanel] objects never call the tcl variable for the filetypes and just ignores the Files of Types menu completely so even if you use [hcs/sys_gui] to set the variable to what you want it never updates them. Would require editing pd's source to make it work. This seems like a good feature request and worth filing an issue for on the pd git. You could make a custom [openpanel] [savepanel] with a gui plugin without much effort if a plugin is OK for your project. I think I saw in the next release of pd abstractions will be able to load plugins which would make this method work well even with projects you intend to share. Don't have time to throw together a demo of plugin now but it is mostly just copying the code from pd-gui.tcl and using [hcs/sys_gui] in an abstraction to run the new proc and send to a send in the abstraction. I can throw something together later or tomorrow if need be, but you can probably figure it out without much effort.

@rph-r I am not sure what other change you are talking about, everything works exactly as I would expect it, the only wrong behavior I see is the stuff associated with [r $1-type] that I mentioned. [savestate] came with 0.49 and you just use the send and receives of the the UI elements to make your list for it, use a [pack] and [unpack] with an extra element which is only used for [savestate] to bang.

You can also use [list store] instead of [pack] with a [set n $1( between each receive and [list store] with n replaced by the appropriate index value, this can be a good way to go when the number of parameters you need to save gets high.

@rph-r It works exactly as expected, watch the symbol boxes when you switch either of the first two channels, they switch on both channels when you change either and so does the internal state of both [pd filters] but not the vradio since it is not connected to [r $1-type] and its own send/receive symbols are $0-from_type and $0-to_type. There is no reason these would bog down [savestate], can't say why it was causing problems for you without seeing how you implemented it, I regularly store far greater amounts of data in [savestate] without issue.

@rph-r If your subpatches don't need a [savestate] to hold their data between sessions then the subpatch as an abstraction shouldn't need [savestate], just use the abstraction exactly like you want to use the subpatch. But [savestate] can load a good amount of data before it bogs things down, I think you have some issue in your patch/abstraction which is causing [savestate] to seem heavy and also making it seem like subpatch arguments are working. Can you upload your patch?