RoystonS

Yes, I noticed there was a new 0.5.5 WAPID yesterday and grabbed it. Interestingly, despite changing both the FSUIPC_WAPID.DLL and the WASM module (and double and triple-checking both), I get the startup output: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.4 (WASM version 0.5.5) Doesn't improve things any, I'm afraid. I still get exactly the same behaviour as before. However, I have managed to discover a little more by writing my own absolutely minimal FSUIPC_WAPID interop to see what's going on. The behaviour is a little odd, and I suspect it points to an issue with FSUIPC_WAPID.DLL: I modified my tiny 'Connect' + 'Disconnect' app so that instead of calling FSUIPCClient it calls FSUIPC_WAPID directly. I made two different variants: 1. Connect() calls fsuipcw_init(), fsuipcw_start() and fsuipcw_getLvarList(). Disconnect() calls fsuipcw_end(). No calls to fsuipcw_registerUpdateCallback(). If I Connect() + Disconnect() three times, I get: Connect Disconnect Connect LVars delivered Disconnect Connect LVars delivered Disconnect That is, I do get my lvars if I explicitly ask for them, but not immediately. That makes sense. 2. Connect() calls fsuipcw_init(), fsuipcw_start() and registers a fsuipcw_registerUpdateCallback which calls fsuipcw_getLvarList(). Disconnect() calls fsuipcw_end(). If I Connect() + Disconnect() three times, I get: Connect LVars delivered Disconnect Connect Disconnect Connect Disconnect This is exactly the same behaviour as I see when going through FSUIPCClientDLL. If, before I do the first fsuipcw_end() call, I change aircrafts, I do get further update callbacks and I get the revised LVars for the new aircraft. After calling fsuipcw_end() once, all of that stops. No more update callbacks. Now, with the massive caveat that I really don't know what I'm doing with the FSUIPC_WAPID API at all, it looks like that update callbacks don't work once fsuipcw_end() has been called, when used from a WPF app. Does that fit with what FSUIPCClientDLL is doing under the hood?

When I set it to null after calling .Stop() it still doesn't connect after the first time. However, after connecting and disconnecting a couple of times the app throws this error: A callback was made on a garbage collected delegate of type 'fsuipcClient!FSUIPC.WAPI+LogCallback::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called. Not really sure that's related to running under WPF though. Does this help any? (Btw, if it's relevant at all, in my real application (what I'm using here is just a tiny app to repro the problem) I do use SimConnect directly myself, and that connects and reconnects happily, across multiple starts and stops of the sim. So I don't think there's any fundamental issue with using SimConnect with WPF.)

Hi Paul, Here's the output with DEBUG logging, again for doing Connect+Disconnect x 2. (Btw, setting the log level only seems to take effect if done after calling .Init?) [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.4 (WASM version 0.5.4) [INFO]: Connected to MSFS [DEBUG]: Config Data 0: name=FSUIPC_HTBM0, size=1960, type=1 [DEBUG]: Config Data 1: name=FSUIPC_VNAME7, size=8176, type=0 [DEBUG]: Config Data 2: name=FSUIPC_VNAME8, size=8176, type=0 [DEBUG]: Config Data 3: name=FSUIPC_VNAME9, size=8176, type=0 [DEBUG]: Config Data 4: name=FSUIPC_VNAME10, size=8176, type=0 [DEBUG]: Config Data 5: name=FSUIPC_VNAME11, size=8176, type=0 [DEBUG]: Config Data 6: name=FSUIPC_VNAME12, size=784, type=0 [DEBUG]: Config Data 7: name=FSUIPC_lvalues0, size=8192, type=2 [DEBUG]: Config Data 8: name=FSUIPC_lvalues1, size=8192, type=2 [DEBUG]: CDA name FSUIPC_HTBM0 mapped to ID 4 [requestId=16] [DEBUG]: Client data area created with id=4 (size=1960) [requestID=17] [DEBUG]: Client data definition added with id=4 (size=1960) [DEBUG]: CDA 'FSUIPC_HTBM0 with id=4 and definitionId=4 requested [DEBUG]: CDA name FSUIPC_VNAME7 mapped to ID 5 [requestId=20] [DEBUG]: Client data area created with id=5 (size=8176) [requestID=21] [DEBUG]: Client data definition added with id=5 (size=8176) [DEBUG]: CDA 'FSUIPC_VNAME7 with id=5 and definitionId=5 requested [DEBUG]: CDA name FSUIPC_VNAME8 mapped to ID 6 [requestId=24] [DEBUG]: Client data area created with id=6 (size=8176) [requestID=25] [DEBUG]: Client data definition added with id=6 (size=8176) [DEBUG]: CDA 'FSUIPC_VNAME8 with id=6 and definitionId=6 requested [DEBUG]: CDA name FSUIPC_VNAME9 mapped to ID 7 [requestId=28] [DEBUG]: Client data area created with id=7 (size=8176) [requestID=29] [DEBUG]: Client data definition added with id=7 (size=8176) [DEBUG]: CDA 'FSUIPC_VNAME9 with id=7 and definitionId=7 requested [DEBUG]: CDA name FSUIPC_VNAME10 mapped to ID 8 [requestId=32] [DEBUG]: Client data area created with id=8 (size=8176) [requestID=33] [DEBUG]: Client data definition added with id=8 (size=8176) [DEBUG]: CDA 'FSUIPC_VNAME10 with id=8 and definitionId=8 requested [DEBUG]: CDA name FSUIPC_VNAME11 mapped to ID 9 [requestId=36] [DEBUG]: Client data area created with id=9 (size=8176) [requestID=37] [DEBUG]: Client data definition added with id=9 (size=8176) [DEBUG]: CDA 'FSUIPC_VNAME11 with id=9 and definitionId=9 requested [DEBUG]: CDA name FSUIPC_VNAME12 mapped to ID 10 [requestId=40] [DEBUG]: Client data area created with id=10 (size=784) [requestID=41] [DEBUG]: Client data definition added with id=10 (size=784) [DEBUG]: CDA 'FSUIPC_VNAME12 with id=10 and definitionId=10 requested [DEBUG]: CDA name FSUIPC_lvalues0 mapped to ID 11 [requestId=44] [DEBUG]: Client data area created with id=11 (size=8192) [requestID=45] [DEBUG]: Client data definition added with id=11 (size=8192) [DEBUG]: CDA 'FSUIPC_lvalues0 with id=11 and definitionId=11 requested [DEBUG]: CDA name FSUIPC_lvalues1 mapped to ID 12 [requestId=48] [DEBUG]: Client data area created with id=12 (size=8192) [requestID=49] [DEBUG]: Client data definition added with id=12 (size=8192) [DEBUG]: CDA 'FSUIPC_lvalues1 with id=12 and definitionId=12 requested [DEBUG]: EVENT_HVARS_RECEIVED: dwObjectID=0, dwDefineID=4, dwDefineCount=1, dwentrynumber=1, dwoutof=1 [DEBUG]: EVENT_LVARS_RECEIVED: dwObjectID=0, dwDefineID=5, dwDefineCount=1, dwentrynumber=1, dwoutof=1 [DEBUG]: EVENT_LVARS_RECEIVED: dwObjectID=0, dwDefineID=6, dwDefineCount=1, dwentrynumber=1, dwoutof=1 [DEBUG]: EVENT_LVARS_RECEIVED: dwObjectID=0, dwDefineID=7, dwDefineCount=1, dwentrynumber=1, dwoutof=1 [DEBUG]: EVENT_LVARS_RECEIVED: dwObjectID=0, dwDefineID=8, dwDefineCount=1, dwentrynumber=1, dwoutof=1 [DEBUG]: EVENT_LVARS_RECEIVED: dwObjectID=0, dwDefineID=9, dwDefineCount=1, dwentrynumber=1, dwoutof=1 [DEBUG]: EVENT_LVARS_RECEIVED: dwObjectID=0, dwDefineID=10, dwDefineCount=1, dwentrynumber=1, dwoutof=1 OnVariableListChanged called. LVars visible in MSFSVariableServices: 744 [DEBUG]: Flagging lvar for callback: id=563 [DEBUG]: Flagging lvar for callback: id=575 [DEBUG]: Flagging lvar for callback: id=712 [DEBUG]: Flagging lvar for callback: id=714 [DEBUG]: Flagging lvar for callback: id=718 [DEBUG]: Flagging lvar for callback: id=724 [DEBUG]: Flagging lvar for callback: id=726 [DEBUG]: Flagging lvar for callback: id=735 [DEBUG]: Flagging lvar for callback: id=736 [DEBUG]: Flagging lvar for callback: id=742 [DEBUG]: Flagging lvar for callback: id=743 [DEBUG]: Flagging lvar for callback: id=715 [DEBUG]: Flagging lvar for callback: id=715 [DEBUG]: Flagging lvar for callback: id=715 [DEBUG]: Flagging lvar for callback: id=715 [DEBUG]: Flagging lvar for callback: id=715 [DEBUG]: Flagging lvar for callback: id=715 [DEBUG]: Flagging lvar for callback: id=715 [INFO]: SimConnect_Close done [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.4 (WASM version 0.5.4) [INFO]: Connected to MSFS [INFO]: SimConnect_Close done It doesn't even seem to get config data back. So I've also tried it with TRACE level. Lots more noise, obviously. It starts with: [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.4 (WASM version 0.5.4) [INFO]: Connected to MSFS [TRACE]: Config data requested... [TRACE]: SIMCONNECT_RECV_ID_CLIENT_DATA received: EVENT_CONFIG_RECEIVED [DEBUG]: Config Data 0: name=FSUIPC_HTBM0, size=1960, type=1 [DEBUG]: Config Data 1: name=FSUIPC_VNAME7, size=8176, type=0 [DEBUG]: Config Data 2: name=FSUIPC_VNAME8, size=8176, type=0 then, skipping ahead: [DEBUG]: Client data area created with id=12 (size=8192) [requestID=49] [DEBUG]: Client data definition added with id=12 (size=8192) [DEBUG]: CDA 'FSUIPC_lvalues1 with id=12 and definitionId=12 requested [TRACE]: Config data updates requested. [DEBUG]: EVENT_HVARS_RECEIVED: dwObjectID=0, dwDefineID=4, dwDefineCount=1, dwentrynumber=1, dwoutof=1 [TRACE]: HVAR Data: ID=000, name='H:AS3000_MFD_SOFTKEYS_1' [TRACE]: HVAR Data: ID=001, name='H:AS3000_MFD_SOFTKEYS_10' [TRACE]: HVAR Data: ID=002, name='H:AS3000_MFD_SOFTKEYS_11' and finally the log around the disconnect + reconnect: [TRACE]: Lvar value: ID=741, value=0.000000 [TRACE]: Lvar value: ID=742, value=1.000000 [TRACE]: Lvar value: ID=743, value=1.000000 [INFO]: SimConnect_Close done [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.4 (WASM version 0.5.4) [INFO]: Connected to MSFS [TRACE]: Config data requested... [TRACE]: Config data requested... [TRACE]: Config data requested... So, whatever config data is being requested isn't getting any replies?

Hi there, I've got MSFSVariableServices from FSUIPCClient.dll working happily, fetching lvars and notifying of lvar change events, with MSFS 2020. It's a lovely API. BUT, when I attempt to use it in a WPF application I can only Start() the MSFSVariableServices once. If I Stop() it and attempt a second Start() I end up with a services object that connects but never provides any lvars. The equivalent code in a Windows Forms application works just fine. Here's a minuscule WPF app that demonstrates the problem: https://github.com/RoystonS/FSUIPCRestartIssue The main code file is here: https://github.com/RoystonS/FSUIPCRestartIssue/blob/main/MainWindow.xaml.cs This is a tiny app with a 'Connect' and a 'Disconnect' button that basically do the same thing as the 'Start MSFSVariableServices' and 'Stop' buttons in the MSFSVariableServices Example Code application. The app calls '.Start()' when the 'Connect' button is clicked, '.Stop()' when the 'Disconnect' button is clicked, and has an OnVariableListChanged listener which dumps lvar information to the debug output. Running the app (with MSFS 2020 running) and clicking 'Connect', 'Disconnect', 'Connect' and 'Disconnect' sends the following to the debugger console: [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.4 (WASM version 0.5.4) [INFO]: Connected to MSFS OnVariableListChanged called. LVars visible in MSFSVariableServices: 349 [INFO]: SimConnect_Close done [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.4 (WASM version 0.5.4) [INFO]: Connected to MSFS [INFO]: SimConnect_Close done What this is showing is that after the first connection I receive a set of lvars via the OnVariableListChanged callback. After disconnecting and reconnecting, I receive no lvars. I have tried explicitly calling .Reload() but it doesn't help. I'm using FSUIPCClientDLL 3.2.10 and FSUIPC_WAPID.dll 0.5.4. When it's connected the first time it's all working absolutely fine. It's just on subsequent reconnects that things go awry.

Yes, the AFC_Bridge from Aerosoft works but can _only_ access simvars, so it's not possible to get the master warning/caution lights to work as they're lvar only. It's also very slow, with 1s fixed updates, and its configuration is very clunky. (I've written all the details up here if anybody wants them: https://github.com/RoystonS/honeycomb/blob/main/bravo-lights.md) I'm on MSFS with FSUIPC7. I'm trying to provide something fairly straightforward for non-developers to use without having to edit LUA code (hence preferring simvars to offset+type+size). Ok, will check the offset status spreadsheet, and I might have a look at making direct SimConnect calls to read the A: variables. Thanks!

Thanks. Ok, so to read those values I need to know both the offset and the datatype (e.g. 8-byte float, 2-byte int)? Is there any way to look that information up based on, say, an 'A:' simvar name? I'm basically trying to provide a simple way to control the lights on a Honeycomb Bravo. The standard Bravo software supports A: simvar names but not lvars so I was hoping to improve on that. I'm able to read lvars successfully through FSUIPC and the .NET wrapper but using offset+datatype instead of name for 'A:' variables is a bit less user-friendly.

Hi there, I'm just getting started with this library. Is it possible to read an 'A:' variable (e.g. "A:ELECTRICAL MAIN BUS VOLTAGE, volts" directly by name, or must I always use numeric offsets (e.g. 0x2840)?