In my current Project I’ve build a Method to send and subscribe to CommBus Events from an external SimConnect App. That Method consists of three Components communicating with each other: the SimConnect App, a WASM Module and a “JavaScript Module” (since I can only subscribe to CommBusEvents send to JS within JS). So roughly: App<>WASM<>JS.
That is working as expected so far! But there is Drawback: to host/run the JS Code I used a Toolbar Icon. That means the Code runs only as long as the Icon gets not disabled or removed from the Bar. But I need to make sure it is running or else one Component is missing and the App can’t work correctly when subscribed CommBus Events are not received.
Ergo, the Core-Question is: How can I run JS Code in the Background (running on loaded Aircraft - like the WASM Module)?
Right now (in MSFS 2024), to have some .JS code that can always run without being affected by the toolbar or having to run inside an airplane gauge, you should do an EFB app.
Let’s hope we won’t see a proliferation of “fake” EFB apps, existing for the sole purpose of providing a bridge to .JS to some other application, in the same fashion as the already happening proliferation of “fake” WASM modules, existing for the sole purpose of providing a bridge for the all important execute_calculator_code() call, which has even been deemed deprecated without a proper replacement.
I already feared that it is yet another oversight in the SDK sigh
I mean in my Approach it’s not only a “fake” JS Toolbar-Icon/EFB-App, the WASM Module is also “fake” because the CommBus API is incomplete in my View: The JS Code is only needed because the API Calls in WASM can not subscribe to events going from WASM to JS. And the WASM Module is only needed because the API is not exposed for external Applications. So essentially just doing ugly Workarounds for a Problem that would not need to exist (like still calling execute_calculator_code).
Well I guess that I have to live with the Toolbar Problem in 2020, and go down the EFB-Route for 2024.
We had made this toolbar interoperability module for MSFS 2020 to run code in the toolbar… A lot has changed in SU2 so we’ll have to revisit. But the ideal is through the EFB now that’s for sure.
So to get that right, the basic Idea is to force an Error and during the Error-Handling the actual Code is injected into the Root-DOM (the Toolbar itself)? So the Toolbar Icon is still being completely unloaded but that doesn’t matter anymore since the Code lives on in the Toolbar itself.
