WASMClient-Master, accessing Lvars via ID or Name

[Demon]

Hi,

(using WASMclient as template)

1. Is it safe to design an app that uses the Lvar ID as a search key?
2. Or should I search the list for a given Name instead?
3. Is that ID a permanent value, or can it change in the future?

In my case, my app will receive an identifier from a USB device.  That identifier will relate with a given control mapped by me (SimConnect and FSUIPC_WASM).  For the Cesssna 152, the 3 variables that concern me are:

• 051    XMLVAR_YokeHidden1
• 052    XMLVAR_YokeHidden2
• 058    XMLVAR_ADF_Mode

I remember reading a comment but don't remember more than a user asking "if that number in front was going to stay", and you might have alluded that it might be removed.  I just don't remember if that was about this ID, it wasn't what I was searching for and kept scrolling so it's vague.

Currently, the FSUIPC_WASM Gets Lvars by ID or by Name, but the actual Set is done by ID.  I'm still fuzzy on how that ID is assigned.  It appears by sequence.

Thank the Visual Studio gods for a straightforward debugger. 🙂

Robert

[John Dowson]

7 hours ago, Demon said:

Is it safe to design an app that uses the Lvar ID as a search key?

Yes.

7 hours ago, Demon said:

• Or should I search the list for a given Name instead?

You can use either, but using the id is better/faster. The methods that accept an lvar name are provided for convenience - they will just get the id for that name and then call the method that uses the id.

7 hours ago, Demon said:

1. Is that ID a permanent value, or can it change in the future?

It is permanent for the duration of the MSFS session, i.e. until it exits. Lvars are never dropped, so every aircraft loaded will create more lvars. Due to this, not all lvars that are available are actually in-use, and there is no way to determine which are in-use. The id is assigned to an lvar when created, so the id order is the creation order of the lvars.

7 hours ago, Demon said:

In my case, my app will receive an identifier from a USB device.  That identifier will relate with a given control mapped by me (SimConnect and FSUIPC_WASM).  For the Cesssna 152, the 3 variables that concern me are:

• 051    XMLVAR_YokeHidden1
• 052    XMLVAR_YokeHidden2
• 058    XMLVAR_ADF_Mode

I remember reading a comment but don't remember more than a user asking "if that number in front was going to stay", and you might have alluded that it might be removed.  I just don't remember if that was about this ID, it wasn't what I was searching for and kept scrolling so it's vague.

The ids should be hidden from users as they are not really relevant. However, I include them in the WASMClient (and in the FSUIPC log) as they were/are useful to me when tracking down issues. Really they should be hidden from end-users.

7 hours ago, Demon said:

Currently, the FSUIPC_WASM Gets Lvars by ID or by Name, but the actual Set is done by ID.  I'm still fuzzy on how that ID is assigned.  It appears by sequence.

The id is assigned when the lvar is created, so it is a sequence in lvar creation order. If you are interested in specific lvars, you should get the id of those lvars from the names and then use the id. You can also flag those lvars for callback in your registerUpdateCallback using flagLvarForUpdateCallback.

Cheers,

John

[Demon]

Quote

The id is assigned when the lvar is created, so it is a sequence in lvar creation order. If you are interested in specific lvars, you should get the id of those lvars from the names and then use the id. 

Thanks, this is what I wanted confirmation.

I assume any changes in existing IDs by Asobo would mess up a whole bunch of people with custom interfaces.

Robert

[John Dowson]

12 hours ago, Demon said:

I assume any changes in existing IDs by Asobo would mess up a whole bunch of people with custom interfaces.

As I said, the next available id is just allocated on lvar creation. so an lvar could have a different id in a subsequent run of MSFS, but it will not change in the same session, even if you switch aircraft and back again. This is actually a bit of a pain as it means that lvars are never cleared and so the number of available lvars is always increasing, even though many are of no use as they are for previous aircraft loaded.

John