RoystonS Posted October 20, 2021 Report Share Posted October 20, 2021 (edited) 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. Edited October 20, 2021 by RoystonS Link to comment Share on other sites More sharing options...
Paul Henty Posted October 21, 2021 Report Share Posted October 21, 2021 This is strange. I can't think of any reason why WPF would be any different than WinForms when calling the DLL. Unfortunately I can't test this here as I don't have MSFS. Have you tried enabling a higher level of logging like DEBUG? It might show something. Paul Link to comment Share on other sites More sharing options...
RoystonS Posted October 21, 2021 Author Report Share Posted October 21, 2021 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? Link to comment Share on other sites More sharing options...
Paul Henty Posted October 21, 2021 Report Share Posted October 21, 2021 Yes it looks like after the restart the WAPI module isn't receiving any SimConnect messages. Can you try setting your variableServices variable to null after you call stop. That way it'll make a new instance and register everything with the WAPIID.DLL again. If that works then it might narrow the problem down to the client side libraries rather than the WASM module or a simconnect. Paul Link to comment Share on other sites More sharing options...
RoystonS Posted October 21, 2021 Author Report Share Posted October 21, 2021 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.) Link to comment Share on other sites More sharing options...
Paul Henty Posted October 22, 2021 Report Share Posted October 22, 2021 The garbage collection is cleaning up the instances of MSFSVariableServices that you nulled, so those errors are to be expected. The failure to connect on a new instance doesn't really give any more information. I notice that the WASM module is now up to 0.5.5. I think it would be worth updating to the latest version. Remember you need to update the FSUIPC_WAPID.DLL and the WASM module running in MSFS. The easiest way to get the new WASM module is to install the latest FSUIPC but it can be installed manually from the WASM Zip file. (http://fsuipc.com) Paul Link to comment Share on other sites More sharing options...
RoystonS Posted October 22, 2021 Author Report Share Posted October 22, 2021 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? Link to comment Share on other sites More sharing options...
Paul Henty Posted October 22, 2021 Report Share Posted October 22, 2021 Quote it looks like that update callbacks don't work once fsuipcw_end() has been called, when used from a WPF app. Yes, that looks to be the problem. From the logs you have posted it looks like the cause of this is the WASMIF module not receiving the simconnect data from the WASM module after end() has been called. The LVARS you get are probably cached from before. I'm guessing the values won't be updated. Quote Does that fit with what FSUIPCClientDLL is doing under the hood? Yes, my DLL relies only on the callbacks so everything is even driven. The mystery is still why this is different in WPF. I'll get month of MSFS so I can test it here and do some debugging and step through Johns DLLs and Libs. I'll report back over the weekend. Paul Link to comment Share on other sites More sharing options...
Paul Henty Posted October 23, 2021 Report Share Posted October 23, 2021 I've tested it here and I see the same behaviour. Interestingly it was also with Winforms. I checked John's client program and it's also doing the same thing, so the problem is somewhere on John's end. I'll report this in the MSFS sub-forum. Paul Link to comment Share on other sites More sharing options...
John Dowson Posted October 24, 2021 Report Share Posted October 24, 2021 The problem was in the WAPI. This has been corrected and updated to version 0.5.5 (the same as the WASM). Please download this version and try with that. John Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now