activex

That resolved the issue (I guess I misread the FSUIPC documentation or don't understand it very well), now I can toggle the hdg mode. To toggle hdg mode, I have to set Lvar to 1 and then reset it back to 0 so I can toggle it next time (I verified this within the sim by looking at the Lvar). But, to get this working properly I had to insert a thread sleep between setting the value and clearing the value, see code below. My question is: Do you know why this is? Out of curiosity, when I set the Lvar with your api call: FSUIPCConnection.WriteLVar("ASCRJ_FCP_HDG", 1); do you add an explicit delay or in your case is the time it takes to make an IPC call sufficient of a delay for it to work? Code re-written to toggle the hdg mode, works all the time now. static void Main(string[] args) { try { FSUIPCConnection.Open(); var offset = new Offset<byte>(0xA000); offset.Value = (byte)1; FSUIPCConnection.Process(); System.Threading.Thread.Sleep(10); offset.Value = 0; FSUIPCConnection.Process(); //FSUIPCConnection.WriteLVar("ASCRJ_FCP_HDG", 1); } catch (Exception ex) { Console.WriteLine($"*** ERROR: {ex}"); } finally { FSUIPCConnection.Close(); } }

Hi Paul, I got temp license for FSUIPC and tried using the "offset to lvar" mapping functionality (via WASM) and it still doesn't work (ie. No exceptions, but nothing happens). Setting the offset 0xA000 to "1" should toggle hdg mode in the CRJ (by Aerosoft). Any ideas? What am I missing?? Interestingly, when I do use the Set Lvar (under WASM in FSUIPC) option and set the ASCRJ_FCP_HDG to 1, it toggles the hdg mode. This also works using your api via FSUIPCConnection.WriteLVar("ASCRJ_FCP_HDG", 1);. I know you may not have the CRJ, but can you try this using FBW airbus and try to toggle one of their lvars? Here's a simple test: FSUIPC7.ini [LvarOffsets.crj] 1=L:ASCRJ_FCP_HDG=UB0xA000 class Program { static void Main(string[] args) { try { FSUIPCConnection.Open(); var offset = new Offset<byte>(0xA000); offset.Value = 1; FSUIPCConnection.Process(); } catch (Exception ex) { Console.WriteLine($"*** ERROR: {ex}"); } finally { FSUIPCConnection.Close(); } } }

So I did some testing on my end and so far so good, 0 crashes 🙂

Thanks Paul. I will test the new version for ya and report back 🙂 Update: It appears Paul's fix, fixed the crashes. I did few quick tests and could not get it to crash. Thanks for looking after this. Thanks for the temp licence. This would be a really convenience thing if I use the registered version since everything is already setup on my end,... All I have to do is map an offset to an Lvar and this setup would literally require 0 coding on my end.

Sorry, should of been more clear: "GoFlightClientApp" is my C# application, I named it that way. Your dll runs within the process named "GoFlightClientApp". I can comment on this exception here that it is Goflight unrelated. My app "GoFlightClientApp" calls api inside FSUIPCClient.dll (by Paul) which in turns uses your "FSUIPC_WAPID dll" to call into your WASM module. If you also look at the exception it says the read violation occurred inside "FSUIPC_WAPID" which runs inside my application's Process address space. Registered means I have to purchase FSUIPC7, correct? If yes, do you have trial license before I make a purchase to try out the lvar functionality. I know you guarantee it to work but I would like to make sure it works with my setup.

Yes, I know, I have verified that my data types match in the ini with the datatype of the offset object (I tried using UB (byte) and SD (int), no luck). I asked John, and he mentioned in his last response that I need a registered version for this functionality (which I don't have). I am waiting for confirmation on this from him. I'll try your suggestions with the Window handle.

Oh, my version of FSUIPC is NOT registered. Is this a requirement?? Please confirm. To obtain a registered version, is that by making a purchase of FSUIPC7? Paul is using this under the hood and provides and object oriented interface. I did see the WAPI because he requires you to d/l the dll and place it along side his dll for run-time loading. John, 1 more thing: When using Paul's api, which uses your FSUIPC_WAPID dll (obtained from FSUIPC-WASMv0.5.2) I get "sometimes" the following exception: Exception thrown at 0x00007FFA8FD7722C (FSUIPC_WAPID.dll) in GoFlightClientApp.exe: 0xC0000005: Access violation reading location 0x00000274C9CC3C78. This is clearly memory read or write violation, a bad ptr? I would like to tell you also, that for window handle passed to WASM I use: var hWindow = System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle; Does WASM really need a window handle or can I just pass some random integer??? Reason why I am asking is because I don't have the luxury to get the window handle inside my dll, in C# forms application that is only available in the running app and that's why I use the call above to get it.

My system is pretty fast, I'll bench mark it. As for using MSFSVariableServices, only issue I have is with the window handle. I am using your library inside my library and I have no access to the Window handle. I could pass it to the library as parameter but some code is structured in a way that I cannot pass it as a parameter. The only option I think I have is: System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle I still have to test this if it will work. Can you abstract away the requirement of window handle? 2) On another note, I tried to use your library with FSUIPC/WASM that allows users to map free offsets to Lvars. This mapping is done in the .ini of FSUIPC like this: [LvarOffsets.crj]1=L:ASCRJ_FCP_HDG=SD0xA000 Then I created an offset (0xA000) of the specific data type and wrote a value into it and called Process function but nothing happened. I could never get it to work. Everything from FSUIPC/WASM is correctly setup/installed. I knew I was writing some memory location because the value was retained after reading it back but the actual lvar was not changed since in the Sim the CRJ lvar was not affected. Any comments on this? 3) When I use the "MSFSVariableServices" class and I perform Start(), Stop() and then Start() again I receive the following, repeating log entry: My log is configured to trace all messages (_lvarSvc.LogLevel = LOGLEVEL.ENABLE_LOG;) Lvars log: [TRACE]: Config data requested... What does that mean? Is this a problem? It only happens if I start/stop/start again the MSFSVariableServices class. 4) I sometimes also receive the following exception when starting MSFSVariableServices , this seems to happen after I close and launch my C# app again (2nd launch). Then goes away, then comes back. Exception thrown at 0x00007FFA8FD7722C (FSUIPC_WAPID.dll) in GoFlightClientApp.exe: 0xC0000005: Access violation reading location 0x00000274C9CC3C78. Here's my initialization code, it resides in ctor of a singleton class inside a DLL. I am using GetCurrentProcess().MainWIndowHandle to obtain the handle. The start(), stop() invocations are in Connect(), Disconnect() wrappers of my singleton class. _LvarsSvc.LogLevel = LOGLEVEL.ENABLE_LOG; _LvarsSvc.OnLogEntryReceived += Lvars_OnLogEntryReceived; _LvarsSvc.OnVariablesReadyChanged += Lvars_VariablesReadyChanged; _LvarsSvc.OnValuesChanged += Lvars_OnValuesChanged; var hWindow = System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle; _LvarsSvc.Init(hWindow); _LvarsSvc.LVARUpdateFrequency = 10; // Get new lvar values 10 times per second (Hz)

He did not really support Lvars/Rvars out of the box, I had to write extra code + setup to do it (passing windows handles, etc). But, as of latest version, after trying to read/write Lvars looks like it is now supported using his standard api calls. He updated his code so that the Lvar Read/Write functions now work without extra setup and coding (the do use your WASM module under the hood). I am switching to his API. I was under the impression when you added WASM module and the setup for Lvars in the ini file it would work automatically work with his api just writing an offset. But looks like that wasn't the case. He's implementation took a different path but now everything seems to be working with his existing api from the FSX days. I have tried this and it did not work ... I can't really make a raw test because I am going through 3rd party library and the FSUIPClient functions Process an offset may do things certain way. Yes it is a object oriented wrapper around the C++ calls but again, without looking at the source code, I can't confirm why it doesn't work. Nevertheless, I'll use his api since it seems to work right now (v3.2.8). I posted on his thread so he can confirm Lvar support is fully supported by his api.

Where can I get "You must use FSUIPC-WASMv0.5.0.zip or a later version." All the links are dead, need help? Okay, found a version here: https://github.com/jldowson/WASMClient/tree/master/WASMClient/FSUIPC_WAPI/lib But when I put this dll with the fsuipcClient.dll in the same folder, it will not load. I have explicit 64bit build, but unsure what is the build of the FSUIPC_WAPI that I downloaded? By trying to load this DLL using depends (is a tool to load windows modules) I get an exception: Error: At least one file was not a 32-bit or 64-bit Windows module. Looks like this DLL is not a valid windows DLL. So the question, where can I get a 64 bit version of this DLL? UPDATE: Do you support Read/Write Lvar in FSUIPCClient v3.2.8 out of the box (with fsuipc version (7.2) having the FSUIPC WASM module installed)??? I noticed that making calls: FSUIPCConnection.WriteLVar/ReadLvar work without explicitly using MSFSVariableServices class. Is this now built-in?

My app is C#, therefore, I have to ensure that datatypes in C# must match datatypes FSUIPC documentation (basically C++ types). In a nutshell, the way I communicate from my C# app to MSFS is using FSUIPCClient C# library written by someone else. So to answer your question, everything goes through the FSUIPCClient C# layer via 2 constructs: You create an object "Offset" of C# datatype (which should match the FSUIPC data type from documentation). You set the objects value and call FSUIPCConnection.Process(). This will take the offsets you have created and do either read or write depending if the value of the offset has changed. I still use the ini file to create the mapping between offset and Lvar but I send the value using my C# app. FSUIPCClient uses FSUIPC to talk to MSFS. I don't use any FSUIPC UI for configuration. Not necessarily, notice that the statement I made talks only about setting the lvar to value="1", ... I just discovered right now, recently, that setting the value to "0" does nothing as I am constantly troubleshooting. Can you explain more what you mean by "Offset Byte ToggleBits control", I just don't understand the part from the documentation. Are you referring to setting specific bits? If yes, why would that matter if a flag is only either 0 or 1. So the bit pattern for byte would be: 0000 0000, 0000 0001. Currently what I am doing in my C#, I have a variable (offset) of type byte and I assign a value of 1 to it. Then I pass that to FSUIPCConnection.Process(). EX: Offset<byte> offset = new Offset<byte>(0xA000); // this is still mapped in the ini file as 1=L:ASCRJ_FCP_HDG=UB0xA000 offset.value =1; FSUIPCConnection.Process();

I tried UB, in C# that's byte (unsigned byte) and I always make sure that type definition of lvar in the ini file matches the type I use to read/write it (in memory). It did not work - it doesn't toggle the CRJ hdg mode. Interestingly, when using the "set Lvar" option in FSUIPC for the Lvar "ASCRJ_FCP_HDG", when you set it to "1", it toggles the function (on/off) but when you set it to "0" it does nothing, neither it turns it "off" when the hdg mode is "on". I am not sure what else I can do test this. I am pretty seasoned programmer, I write software professionally and checked everything, and then doubled checked. Any other suggestions, or logs I can consult?. I was thinking to point my finger at the FSUIPCClient C# library but I don't think that's the case since it works with standard offsets perfectly.

All, Goal: To control toggle hdg mode "on/off" on the CRJ released by Aerosoft using Lvar support in FSUIPC. Currently, I cannot get it to work, and I am not sure why. I did read the SDK docs on using Lvar support before trying this. NOTE: I am using FSUIPCClient for writing/reading the value and the language I am using is C# (on .net framework). This client library and my app works perfectly fine using (read/wriate) standard FSUIPC offsets in MSFS, tested and working. Now, I am trying to use a mapped offset to a dedicated Lvar and it doesn't work. Here's what I have: FSUIPC7.ini entry: [LvarOffsets.crj] 1=L:ASCRJ_FCP_HDG=SD0xA000 To set the hdg mode on, I write a single byte to offset "0xA000" with value 0x01. <= Is this correct, or should I write 0xFF. When I do this, the memory area is changed because I can read the value back with the value I set it to but it has no effect on the CRJ. So far, I tried singed byte and signed integer (in C# that's 4 bytes, DWORD in C++), both did not work. I did do a test by using the Set Lvar WASM function in the FSUIPC and it works. I selected the "ASCRJ_FCP_HDG" Lvar and set it to 1. This toggles the hdg mode on/off. Other questions for anyone: - Is there documentation of the CRJ Lvars, looking for datatypes, whether they are read or write and the values they accept. I know the Lvars but I don't know the rest of information about these and troubleshooting my problem is really difficult. Any help would be helpful. I am sure there's something I am doing wrong or the Lvar support maybe only for C++? But then again, things work in my setup (FSUIPCClient/my c# app) on standard offsets.

No worries, everything got cleared up.

Ahhhhhhhhhhhhhhhhhhhhhhh, Windows guys usually use Excel software ... I don't use ODS and I cannot possibly know every ext, thanks for your clarification. I have to see if I can open this in some online tool, I don't want to install OpenOffice. I wish this would be PDF. Interestingly, I thought you were referring to this file as zip archive and so I opened it as that in Winrar, and was looking inside it for a spreadsheet. Looks likes .obs stores its content in zip archive format using bunch of xml files/folders.

I do not see it, in the attached archive. What is the exact file name in the archive I am looking for? This archive contains folders and xml files only. I did not see any spreadsheets?

I am so confused .... What spreadsheet? The archive doesn't contain any spreadsheets. When you say "spreadsheet", what exactly are you referring to? Can you tell me exactly the file name you referring to or attach that file please? The attached ods file, is that the spreadsheet? If yes, how do I open it??????? I see this file as an archive with bunch of folders and xml files.

That's fine, but what I am trying to say there's no documentation (ie no file) in that archive for documentation of unused (free) offsets.

Sorry, can't find it. Only thing I found by that name is offsetStatus-v0.25 and by looking into archive I can't find any files with offsets or spreadsheet , I just see bunch of xml files. Can you also comment on my 3rd question I added. Here it is: 3) When selecting the data type (size) for the offset, do I use the size as defined by the author of the aircraft or is it sufficient to select a size large enough to store the value and make sure that when I write/read the offset I call the appropriate function for the defined size?

All, 1) What is the range of free offsets (user defined offsets) I can use to map my lvars to user offsets? I don't want to use reserved offsets. 2) When I launch FSUIPC, under add-ons => WASM menu most of the options (List Lvars, List Hvars, ...) are disabled. Only option that's enabled is to enable/disable WASM. What does this mean? Is this functionality only for licensed versions of FSUIPC?? 3) When selecting the data type (size) for the offset, do I use the size as defined by the author of the aircraft or is it sufficient to select a size large enough to store the value and make sure that when I write/read the offset I call the appropriate function for the defined size?

How will we know when Lvars support is added to FSUIPC? Is there a specific post where you release announcements about new features?

I understand, ... ,- I chose it because it was easier to get started with it ... it is also very easy to send FS controls using FSUIPCClient library. SimConnect is probably what I will be using in the near future since the docs/examples probably improved (now that the Asobo SDK team is quite large).

We'll we have support for for 8.33kHz radios?

I am new to FSUIPC, just giving you feedback, the documentation needs improvement - Coming from a software engineer that's been working in the industry for almost 20 years. I decided to use completely different offset (0x2B00 - Gyro compass heading (magnetic)) that doesn't require corrections as stated previously. Absolutely, ... like using BCDs to store data. Tbh, if this would be my product, I would put a façade overtop of these binary values so that offset reads only return either ints or floats (wherever possible) which represent logical values in the sim (I would also default to an adopted units, ex feet vs meters). If you worry about backwards compatibility then create a new range of pseudo offsets for commonly used offsets. Everything would be consistent and easy to work with. Xplane SDK is a good example of this. On another note, we'll need offsets for 8.33kHz radios for MSFS2020, I'll create a separate post. Hopefully, this will not be a BCD number.

I missed it on the (0x2A0) simply because it is mixed with the rest of the information. That's on me. On the other hand for offset 0x580 I understand that the range is 0-359 that doesn't make the data type automatically unsigned. I've been using many APIs for long time and typically engineers use just a "signed" int for storing all sorts of unsigned values because ints are fast/efficient on current CPU/memory architecture. I think, a better explanation would be the fact that 65,536 can only be stored in unsigned short but even so you sometimes can miss that. I am always for explicit/clear documentation since there's no assumptions and everyone comes from different programming backgrounds. I decided to use 0x2B00 offset since I don't have to do any calculations. Thanks for your reply. I will continue testing FSUIPC7, it is coming along quite nicely.