Cardinal code for osdialog_file()

[gregh3285]

Has anyone put work into creating a version of osdialog_file() that fits into the Cardinal architecture? I've tried updating JW-Modules and alefsbits to newer versions require osdialog_file() that Cardinal does not provide. I'd investigate but want to be respectful of work already underway.

[falkTX]

the osdialog_file is intentionally not provided, because it is a blocking API.
Cardinal uses async dialogs instead, code from modules that use file browsers needs to be patched for such async setup.

[dromer]

You can see an example of how to port this to work with Cardinal async dialogs here: sebastien-bouffier/Bidoo@v2...CardinalModules:Bidoo:cardinal

[gregh3285]

Thanks @falkTX and @dromer for the quick responses. I'm trying my hand at getting JW-Modules' Grains working with the design pattern @dromer suggests.

[gregh3285]

After a bit of learning, I've got JW-Module's Grains running. And, I can save and load wave files with async_dialog_filebrowser. Some more work to do on other module. Hopefully by the end of the week I'll have tested and be ready to submit a PR to JW-Module with my updates.

[dromer]

Please also PR to Cardinal once that is merged, as we are about 11 months behind at the moment :)

[gregh3285]

You kind of have to turn code inside out to move actions into lambda callbacks. Updating SampleGrid involved some refactoring for sure. But, I have a draft that runs. I need to carefully review it and test the modules in VCV Rack.

[dromer]

Not really, just create a separate function. I think You slightly overcomplicated the refactor ;)

[gregh3285]

Yeah, the challenge is that the result of a file selected in dialog box is then used for subsequent code. My assumption (perhaps incorrectly) is that the lambda function acts like a callback. My further assumption is that the lambda function will get called once the dialog box closes. But, because the dialog box run asynchronously, you're not going to have the path info when async_dialog_filebrowser returns. So, anything that uses that path info after the call to async_dialog_filebrowser needs to be pulled into the lambda function to avoid race conditions (that being path used in the main code before the dialog box closes with the updated path).

Concretely, in the example below, I would need to move update_some_attribute_or_take_action(path) into the lambda, right?

   ...
   async_dialog_filebrowser(false, NULL, NULL, "Replace sample", [this](char* path) {
									randomLoadHandler(module, cell, path);
								});
   ...
   update_some_attribute_or_take_action (path);
   ...

The knock on effects of this can create some challenges when the caller to the function having the dialog box also uses the path (either stored in an object or returned explicitly from the called function). In this instance you need to go to that caller function, and figure out the how to pull functionality from the caller function into the lambda.

Thanks for you patience. Learning.

[gregh3285]

For better or worse, the pull request is now out there!