Using the SimConnect SDK - A SimVar Request handler (and potential SDK replacement)

[Dragonlaird]

The SDK samples and documentation aren’t really geared towards teaching novice developers how to use the SimConnect DLL/SDK, rather they provide basics for understanding how it could be used and then leave the developer to investigate their own requirements further, using resources such as other examples of code and forums like this.

This thread is trying to shine some light on how you can use the SimConnect SDK to actually submit requests and receive/process responses. The output is a SimConnectHelper that you can use to submit SimVar requests to MSFS 2020 and request the results for you to use in your own applications.

The sample code provided is written in C#, feel free to port this to other languages.

This tutorial is designed to be read/used when referring to the code of the SimConnectHelper project, so we’re not simply copying/pasting huge swathes of code from GitHub into this forum. Snippets of code are provided throughout this tutorial, to provide some reference to the areas of code we’re talking about, to help you find/read the right section as we proceed.

The SimConnect DLL is a very simple interface; it expects your code to tell it exactly what you want it to do and how you want it done.

If you make a typo in your code, or FS isn’t running, or make any other mistake, SimConnect isn’t very forgiving, it simply fails. Nor is it very helpful in pointing you towards the cause of the failure, so you’re likely to spend a lot of time making mistakes and then refining and tweaking your code to fix it, via trial and error.

With the above in mind, I have created a simple helper project, to demonstrate how you could write your own code using SimConnect, or you can simply embed the SimConnectHelper into your own project to use what’s written.

At the time of writing, the project on GitHub allows you to:

1. Connect to MSFS 2020 locally
2. Connect to MSFS 2020 running on a remote PC
3. Disconnect from MSFS 2020
4. Submit a SimVar request
5. Request an updated value
6. Auto-receive latest values using a pre-defined schedule
7. Submit a SimVar value to MSFS 2020
8. Remove/cancel a previous request
9. Disable AI Updates to prevent MSFS 2020 from changing the values you submit

** VERY IMPORTANT** the SimConnect.dll is 64-bit! If you’re planning on creating projects yourself, make sure your project is also configured to compile in 64-bit, otherwise, you will likely receive all manner of errors, not all of which are helpful. Also, if your project intends to use the SimConnect.dll directly, make sure you reference the SimConnect.dll in the right way. If you’re using a development IDE such as Visual Studio, the SimConnect.dll may not automatically copy to your compiled output folder, you may have to force it or do that manually.

The sample code also contains a small test project to demonstrate how the helper is used.

The main class SimConnectHelper provides the actual code you can use in your own projects. It is littered with comments to help you understand what each part of the code is doing, which is particularly helpful for anyone wanting to port the code to another language or to provide guidance via IntelliSense when using it in your own projects.

I have also started creating another project to demonstrate how you can embed the helper into a form.

I plan to add more features to the helper in the future, but hopefully, this will help the budding developers out there get a head start in their coding.

GitHub - Dragonlaird/SimConnectHelper: A static class to simplify...

[Dragonlaird]

So, we’ve explained what we’re doing here, lets dive in to designing what our code should do.

To simplify use of the resulting project, I plan to create it as a static public class, so our consuming code (e.g. a WinForm Application, a Console Application, or Test Project etc) can just access it directly, without having to create a new instance. This means there will only be a single connection created to communicate with MSFS 2020.

I want to create some simplified methods such as:

• Initiate a connection to MSFS 2020
  (both to a local instance of MSFS 2020 or an instance running on a remote PC)
• Submit requests for SimVars
• Request value updates
• Submit values for SimVars, and
• Disconnect from MSFS 2020.

I also intend to add a few useful properties, such as:

• An indicator (bool IsConnected) to see if we’re connected to MSFS 2020
• A property (bool UseFSXcompatibleConnection) to allow backward compatibility with FSX (untested)
• A default frequency (DefaultUpdateFrequency) to fetch values (in case we don’t want to explicitly set it every time we call the method)
• Basic details (public static SimConnectConfig Connection { get; private set; }) of the current/last connection to MSFS 2020 (read-only)
• A collection containing every SimVar we’ve requested (Dictionary<int, SimConnectVariable> Requests)

The last item will provide consuming applications a read-only reference list, to find previously submitted requests to prevent duplicate requests, and allow re-use of a previous request, and so-on.

Finally, I will add some event handlers to capture events raised by SimConnect, populate some variables with relevant values (that are meaningful to our consumer), and then raise a new event to pass these values on to the consuming application.

It needs to be done this way, as SimConnect communicates asynchronously. That means, when SimConnect requests an action in MSFS 2020, the results aren’t provided immediately, instead it raises an event (Windows Message) to let us know when SimConnect has something to tell us.

To explain with a simple example:

If we ask SimConnect to connect to MSFS 2020, it doesn’t immediately respond to the request to let us know it has connected, or even to let us know it is attempting to connect.

Instead, it accepts our request to connect, then as a background task, it internally initiates the handshake with MSFS 2020.

When the process is complete, SimConnect raises an event to inform us it has connected.

We listen for and capture this event, so we know it is safe for us to start sending SimVar requests.

We can then set the “IsConnected” property to indicate we are connected to MSFS 2020 and also raise a new event with a value of TRUE (=connected) or FALSE (=disconnected), for the consumer.

This means, our consuming application doesn’t need to sit in a loop, waiting for the IsConnected property to change, it can carry on doing whatever else we want, then as soon as SimConnect establishes a connection, a method within our consuming application is called with a value of TRUE or FALSE, to let us know we can talk to MSFS 2020.

The event handlers will be:

• Connect/Disconnect Event
• Data Received
• Error Occured

So this is the bare minimum needed for the helper to be useful. As the project progresses, I expect to add more methods, properties and maybe even event handlers.

[Dragonlaird]

Now that we’ve designed what we want our code to do, let’s examine how we can achieve it.

We’ve already identified that SimConnect uses the Windows Message feature, to notify clients when there are events to handle. This presents us with some problems.

In .NET, windows forms, etc use this process silently, the required properties and methods are obfuscated to simplify coding for developers, but for this scenario, we actually need to manage these messages ourselves so we can see when SimConnect is trying to communicate something.

Furthermore, we want to create a static class for our helper, which doesn’t support Windows Message processing.

To overcome this, we need to create a class that inherits the bare minimum features of a Windows Form, without all the bells and whistles provided by the full class. After all, we’re never planning to display any windows in this code and we don’t want any extra overhead or code loading, that we’ll never use or need, it will only be used for handling Windows Messages and passing them to our static class (by raising an event that we can consume - we’ll get to that bit later).

To do this, we create a class to inherit the NativeWindow class - which is about as low-level as we can get without writing a lot of replacement code to implement all the necessary methods, properties, event handlers. It doesn’t contain any UI elements, no graphics stuff, just the core, background code we need to handle Windows Messaging.

internal class MessageHandler : NativeWindow

We have done this in the above class, it is our main Windows Message handler. It’s a very small class to listen for any Windows Messages, filtering out any relating to SimConnect and raising an event whenever one is received - that’s it!

Well, that was easy - what next? We need to load this into memory, in a single, separate task (remember, this will be used in our Static class, so we only ever want one instance running), so it runs permanently. We’ll cover this in the next post.

[Dragonlaird]

Now we’re ready to start creating our static helper class.

EDIT: the class below was originally named SimConnectHandler and has since been renamed - any reverences in this discussion to SimConnectHandler should be changed to SimConnectHelper.

public static class SimConnectHelper

Not a very original name, but the above class will contain all the properties and methods we want to expose for our projects to access SimConnect, without needing to understand or work directly with the SimConnect DLL.

Put simply, this is the static class that will provide all the properties, methods and events that we listed, when we designed our project aims above.

Since we’ve already created our Windows Message handler above, it makes sense we should start with instanciating (creating an instance of) that, so we can start listening for any SimConnect messages.

To do this, we’ll create a simple method to create a static instance of our hander, launch it in a separate thread and just leave it running.

/// <summary>
/// If not already connected, will attempt to connect ONCE to MSFS2020
/// </summary>
private static void RunMessagePump()
{
    // Create control to handle windows messages
    if (!FSConnected)
    {
        handler = new MessageHandler();
        handler.CreateHandle();
        ConnectFS(handler);
    }
    messagePumpRunning.Set();
    Application.Run();
}

We’ll call this code every time the client wants to connect to MSFS 2020. Since it will only create a single instance of our handler, we can call it as often as we want. It will only create a new handler if it isn’t already running.

The last line of code Application.Run(); is very important.

Even though our code is already running, we need to call this in the thread creating the instance of our handler, otherwise it won’t hook into the Windows Messaging process correctly. Quite simply, it won’t work without it.

We’ll start the above method in a separate thread, like this:

    messagePump = new Thread(RunMessagePump) { Name = "ManualMessagePump" };
    messagePump.Start();
    messagePumpRunning.WaitOne();

Edit - Due to requirements identified later in this project, the above code is replaced with a separate Task instead of a Thread - This allows us to stop/remove the Message Pump easily. Canceling and removing a Thread is much harder than a Task

That’s basically it. The handler is now loaded into memory and runs silently in the background.

But wait, we did say it provide an event for us to consume - where’s the code for that?

Well, we’re only interested in handling Windows Messages when we’re actually connected to MSFS 2020 - there’s nothing to do until then, so we hook into the event as part of the ConnectFS() method.

We need to call this within the same thread as our handler. Quite simply, if it isn’t in the same thread, they won’t talk to each other.

Since we’ve started talking about connecting to MSFS 2020, that’s the next step we’ll cover, in the next post.

[Dragonlaird]

For those wishing to dive right in with SimConnect directly, the SDK documentation is now available online (thanks for the notification @Steeler2340).

SDK Documentation now online

https://docs.flightsimulator.com/ Finally

[Dragonlaird]

As we mentioned in the post above, we discussed connecting to MSFS 2020 with SImConnect and how we can simplify this.

A little known feature of SimConnect is the ability to connect to MSFS 2020 running on the local PC or on a remote PC via the local network.

It’s a little bit fiddly to achieve the latter, simply due to a lack of knowledge or documentation. It’s made harder by MSFS 2020 itself, as it can be configured to accept connections from a variety of different network sources (via an XML file).

It can connect using TCP/IP v4 (that’s the common dotted network address format like 127.0.0.1), TCP/IP v6 (that’s the long odd-looking network address with colons), or via Named Pipes (look it up).

So how does SimConnect know how to connect to MSFS 2020? It’s a bit old-school using a config file - We can’t pass connection parameters (like an IP address and port), it needs to be defined in a Config file.

Programatically, this isn’t a good approach, so our handler will accept the parameters and create the file for us.

SimConnect looks in several places for this Config file, including the folder it is launched from. This isn’t a great place to put a Config file, as its expected a final application will be installed within the Program Files folder, which is configured to prevent dynamic updates to files as a security feature.

Another location for the Config file is in the user’s AppData folder, which can be found via an Environment Variable, other posts mention saving this Config file in the users Documents folder.

So, we’ll provide a property to allow the path to be set via a property:

/// <summary>
/// Full path and filename to use for saving a Config file
/// </summary>
public static string ConfigFilePath { get; set; } = Path.Combine(Environment.CurrentDirectory, "SimConnect.cfg");

We will also provide a simple Connect method, with a few override options to provide the connection parameters they want to use, then we’ll update the config file for them, start our Message Pump (MessageHandler above) and link our event handlers:

public static void Connect(EndPoint ep)

or

public static void Connect(SimConnectConfig config)

or

public static void Connect()

The last method is very unassuming but it’s a little more sophisticated than it appears.

Remember we mentioned the MSFS 2020 server component uses an XML file to define the types of connection it will allow? The last one finds this XML file (assuming it is running on the same PC), extracts each of the connection parameters then tries them in turn, until one connects.

There is another issue we had to overcome for the last option. It’s not easy to force SimConnect to re-read the Config file, basically it only does this when it’s first launched, so we need to be able to unload and reload the DLL. Therefore, it makes sense we provide a corresponding method to do this for us:

Disconnect()

There are no overrides for this, it simply does what we expect. It stops the Message Pump (MessageHandler discussed above), unlinks any event handlers and disposes any SimConnect.DLL instance we created, leaving everything ready for us to start a new connection.

Next we’ll look at how we can start requesting SimVar values and the different options available for us to fetch updates.

[Dragonlaird]

So now that we can connect to MSFS 2020, we would likely want to start requesting simulation variables (referred to as SimVars) that we can use in a project.

There are a lot of SimVars we can use, we’re not going into those in detail here. If you want to see them all, you can either trawl through the documentation online (see link in a post above) or review the code in the project itself.

namespace SimConnectHelper.Common
{
    public class SimVarUnits
    {
      ...
    }
}

The list may not be 100% complete as it was created a few months ago, but it will get you started. The list is also used in the Form project created within the code repository for testing the helper, presented as a drop-down list, if you just want to see them listed.

Back to talking about SimConnect.

Basically, we need to do a couple of things with SimConnect to fetch a SimVar value.

First, we need to reserve a block of memory within the SimConnect to hold the SimVar and provide us with a reference we can use to request updates or identify the variable we requested.

Secondly, we need to submit the request for the SImVar and tell it the type of units we’re expecting to be returned. Units include meaningful names such as “degrees”, “knots” etc.

The first item above is a bit of overkill for a consuming application, so we’ll hide that bit of code in the methods we provide. The main project won’t care about having to reserve space or manage it, if we handle it for them.

The second item is a bit more interesting. When we request a variable, we’re not actually asking for the value to be returned immediately. It’s more like we’re registering our interest in that variable so that SimConnect knows we’re likely to want the value at some point.

Once we’ve registered “our interest” we then need to accept the new value, when we request it. This is done via an event listener, so each time SimConnect sends a value, we can associate it with the original SimVar we requested and raise an event for the consuming application to receive it.

There are basically 2 ways we can ask SimConnect for a value.

1. Manually, when we specifically ask for the latest update
2. Automatically, when we want the value to be supplied at a specified frequency

These actually use two methods in SimConnect, so we’ll simplify it for the consuming application, they can supply the frequency they want the value updated, with the default frequency (Never) being used to indicate they will manually request updates. Available frequencies are basically the same as those provided by the SimConnect enum, just made available as a public enum on our project so the developer doesn’t need to create references to SimConnect to use them:

public enum SimConnectUpdateFrequency // SIMCONNECT_PERIOD
    {
        Never = 0,
        Once = 1,
        Visual_Frame = 2,
        SIM_Frame = 3,
        Second = 4
    }

Remember we mentioned that SimConnect provides a reference to us, in the first point above? For SImConnect, this is an enum value. Not the best idea since enums should be defined at compile time (this can be overridden but we’ll handle that in our code).

Instead of providing an enum, we’ll just pass back an integer (e.g. a Request ID) to the consuming application as a reference. This means, if the app wants to manually request an update for any SimVar, they can just supply the Request ID and we’ll figure out which SimVar they actually meant.

/// <summary>
/// Request an update for a specific SimVar request
/// </summary>
/// <param name="requestID">ID returned by SendRequest</param>
/// <param name="frequency">SimVar can be requested manually (SimConnectUpdateFrequency.Never) or auto-sent at a pre-defined frequency</param>
public static void GetSimVar(int requestID, SimConnectUpdateFrequency frequency = SimConnectUpdateFrequency.Never)

Although it’s also likely the developer won’t want to manage a collection of requested SimVars and associated Request IDs, so we’ll provide an override, allowing them to just request the SimVar by name and unit (e.g. “INDICATED AIRSPEED”, “knots”).

/// <summary>
/// Request a SimVariable from SimConnect, optionally start capturing values
/// </summary>
/// <param name="request">SimVar to fetch from SimConnect</param>
/// <param name="frequency">How frequently should SimConnect provide an updated value?</param>
/// <returns>A unique ID for the submitted request. Use this to request the next value via FetchValueUpdate</returns>
public static int GetSimVar(SimConnectVariable request, SimConnectUpdateFrequency frequency = SimConnectUpdateFrequency.Never)

As we mentioned, the default value of “Never” means the consuming application should request an update at a frequency it chooses, so we can provide further override methods to accept just the Request ID or SimVar name/unit, to force an update.

/// <summary>
/// Request an update for a specific SimVar request (used for GetSimVar(frequency = SIMCONNECT_PERIOD.NEVER))
/// </summary>
/// <param name="requestID">Variable definition requested via GetSimVar</param>
public static void GetSimVar(SimConnectVariable request)

The resulting value will be transmitted back to the consuming application via an event handler:

/// <summary>
/// Called whenever MSFS 2020 transmits requested data about an object (e.g. SimVar result)
/// </summary>
public static EventHandler<SimConnectVariableValue> SimData;

That’s the basics covered for requesting a SimVar, next we’ll cover how to send an update for a SimVar.

[Dragonlaird]

Similar to how we retrieve a SimVar value, setting a SimVar is also a two stage process, reserving a block of memory within SimConnect then assigning values when we want to change it.

Let’s take a peek under the hood.

For reserving the block of memory, we can re-use the same code we developed for fetching SimVar values. This basically tells SimConnect the type of SimVar we’re using followed by the type of data we’re expecting back.

// Submit the SimVar request to SimConnect
simConnect.AddToDataDefinition(simReq.DefID, request.Name, unit, simReq.SimType, 0.0f, SimConnect.SIMCONNECT_UNUSED);

Strangely, SimConnect expects references to SimVars and their expected Data Type to be defined using ENUMs - Normally, when coding an ENUM is a static list of pre-defined values, obviously, we don’t know in advance which SimVars will be used, and we don’t know which values we’d expect back, so why ENUMs?

The first parameter in the method call above is an ENUM.

Luckily ENUM values can be faked at runtime by supplying an integer cast into an ENUM.

The second part is defining the data type we’re expecting this SimVar to return, to identify this correctly, you will need to refer to the documentation, but the method to do this is fairly straightforward:

simConnect.RegisterDataDefineStruct<double>(simReq.DefID);

Change the <double> above to reflect the Data Type you require to be returned.

There is one slightly unusual Data Type, <string> won’t work, even though the value you’re expecting to be returned is a text string (such as for the “Title” SimVar).

Instead, SimConnect will require a struct to be supplied, like this:

simConnect.RegisterDataDefineStruct<SimVarString>(simReq.DefID);

SimVarString is a structure:

internal struct SimVarString
{
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 256)]
    public string Value;
}

This allows SimConnect to populate the Value property of the struct, which you can then reference in the returned value.

The documentation (see link above) relating to which variables can be set is not complete. Many variables have not been updated to indicate if they can be set, some are incorrectly defined as readonly or state they can be set. Others have the wrong units defined.

The basic rule is, if you want to set a specific SimVar value, try it. If it doesn’t work, then it’s likely not settable. Having said that, there are some values that can be set, but not with the units you might expect.

For example, I recently tested 2 SimVars defined as settable, with a unit of BOOL (e.g. TRUE/FALSE). One actually required me to supply the text “TRUE” as the submitted value, the other required me to submit the integer “1”, which SimConnect then returned as “true”.

So, some trial and error is needed when experimenting with editing SimVars.

Once we have defined the SimVar we want to set and the Data Type we expect to be returned, next we’ll pass in the value to set it to. This is achieved with the following:

// Data area reserved, now set the value
simConnect.SetDataOnSimObject((SIMVARDEFINITION)reqId, SimConnect.SIMCONNECT_OBJECT_ID_USER, SIMCONNECT_DATA_SET_FLAG.DEFAULT, simVarValue.Value);

In the code above, reqId is the ENUM value we set in the previous code to reserve the memory block above. simVarValue.Value is an object. This is because it can contain any number of Data Types, so the object base class is used to allow any to be passed.

Since we’ve defined a memory block in the same way we reserve it for Get’ting a SimVar, the value we submit will be returned as a raised event. Most likely, we want a fire-and-forget solution, where we simply don’t care if MSFS 2020 has implemented the value we sent, we’ll just assume it has.

So, we now know how to set SimVar values. Next we’ll look at how we can ask SimConnect to forget about a SimVar request, as we like to tidy up after ourselves when we don’t need something any more.

[Dragonlaird]

Well, our tutorial is almost over and your own learning has already begun, hopefully, with the basics you need to continue the journey unaided.

Your last topic is how to forget about SimVars, so that SimConnect doesn’t keep capturing values we previously asked for or telling us about them when we’re no longer interested in them.

This is quite straightforward, but there is one important pitfall to be aware of.

If you don’t cancel a request correctly, not only will SimConnect get upset, it will throw all its toys out of the pram and actually cause MSFS 2020 to crash and unload without warning.

Yes, you read that correctly, it can cause MSFS 2020 to crash!

The key thing to remember here is to only cancel a request you have definitely submitted to SimConnect.

Remember we mentioned waaay back when designing our project scope, we would include a read-only collection for previously submitted SimVar requests? Now you know why it’s there - use it every time you want to cancel a request!

So, to cancel a previous request, we need to do a couple of housekeeping routines in our static method:

/// <summary>
/// Allows cancelling of a previously requested variable, if it is no-longer needed
/// </summary>
/// <param name="request">SimVar Request to cancel</param>
public static bool CancelRequest(SimConnectVariable request)

Firstly, we want SimConnect to stop capturing data relating to this request, then secondly we want to remove the SimVar from our collection.

So, to tell SimConnect to forget about a previous request, we only need to do the following:

simConnect.ClearClientDataDefinition((SIMVARDEFINITION)requestId);

In the snippet above, requestId is the ENUM value it was originally created with (remember those?).

This just happens to be the KEY value associated with our previous SimVar request, that we conveniently provided in the collection above. Our method will find it for you and submit it to SimConnect.

The method will return TRUE or FALSE, depending on if it sent the actual request to SimConnect. If you try to forget a SimVar you never asked for or supplied the wrong unit type, it won’t ask SimConnect to forget it.

If you write your own code to use SimConnect directly, remember you can cause MSFS 2020 to crash, if you cancel something you never asked for, to begin with.

Also, avoid using the similar-sounding SimConnect method name ClearDataDefinition(), and especially never use both together - or MSFS 2020 will say, “Hasta la vista, baby” (not literally, it doesn’t actually say anything - ever again - it dies ).

So, there you have it - a whistlestop tour of how to use the fundamental features of SimConnect to talk to MSFS 2020.

You’re welcome to use the SimConnectHelper class we’ve created within your own projects, you can also port the code into other languages if it will help.

Of course, if you find a ported version helpful, others probably will do too, so feel free to share your version on GitHub, it’s good to share

[Dragonlaird]

One point worthy of note when SETting SimVar values. The likelihood is MSFS 2020 will (almost immediately) overwrite any values you supply with its own, calculated values.

This gives the impression that setting variables doesn’t work (it does) because you never see your value reflected in MSFS 2020.

To prevent this this from happening, you will need to disable the relevant built-in process. The code to do this is complex and specific to the type of data you want control. There is no code supplied to do this in this example.

The aim of this tutorial is to get you started in programming with SimConnect, not provide a complete solution for everything.

That said, the official SimConnect docs do provide some insight on how you can automated calculations via:

SimConnect_AIReleaseControl

https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/API_Reference/AI_Object/SimConnect_AIReleaseControl.htm

I may provide a future update to code, to simplify the use of this feature, once I’ve fully read the docs relating to this and identified the corresponding option to re-enable the automated process.

[Dragonlaird]

Quick Update: Project has been updated to you to allow supply your own update frequency in milliseconds.

To ensure backward compatibility, a new override method has been added:

GetSimVar(SimConnectVariable request, int frequencyInMs)

Created a new branch to allow disabling AI for SimVar Updates. Not sure if this will be automatic (when Setting a SimVar) or optional (requiring you to decide if it should be disabled), probably the latter by adding an optional boolean parameter to the existing method, like this:

public static int SetSimVar(SimConnectVariableValue simVarValue, bool disableAI = false)

This ensures backward compatibility with existing code, where it will not disable AI, but allow you to easily modify existing code to add this parameter if you wish to dsable it.

[MarkRWatney]

Thanks for posting this change to your demo code, Dragon!

Sometime this weekend I will see if I can compile it. That looks very promising!

[novreis]

Hi Dragonlaird, I wish I had found this earlier but I still have one issue with string variable return.
For instance, when I want the GPS WP NEXT ID your program returns a number. Is that you want or I am missing something? Thks

[Dragonlaird]

GPS WP NEXT ID is defined as a string SimVar, however, we have no control over the value assigned to it by MSFS 2020, as it’s read-only.

If it contains a number, then that’s the value it has been assigned.

Strings are a little strange in SimConnect, as it doesn’t natively work with an undefined string length, to work around this, the helper uses a Struct (SimVarString) to assign a string value, then converts it back to a native string when the value is populated.

You could confirm that a string does get returned as a string value by requesting TITLE, this should return the name of the current aircraft you are flying.

[novreis]

thks, I will try that. I develop my stuff at C# but I am far from being an expert. As I use to say I am a “programmer by googling”. Too old to learn right programming but I manage to do things

[Dragonlaird]

Nobody is born a programmer, most of us “old-school” developers all started the same way, asking for help, using Google and reviewing how others have achieved a similar result.

As for being too old - there’s no such thing! I’ve been programming for over 40 years and every day is a school day, it’s exciting to learn new stuff and when “the penny drops” regarding a fix for a problem or understanding something that’s been baffling you, the feeling you get is near euphoric.

So never be afraid to try something new - if you break it, then you manage to figure out how it broke or what you did wrong, you’ve learnt something, and trust me, you won’t make that mistake again - “learning by mistake(s)” is (in my opinion) the best teacher.

[ZenMusic2]

thanks, I’m about to compile this and try it out … Do you know , could you add a WASM module to work with the C# ? That’s the only missing link for me.

[Dragonlaird]

Not tried building any WASM modules yet, I’ve seen plenty of threads in here relating to it, even relating to combining SimConnect SimVars within WASM - but not really checked anything out in detail yet.

As the helper is written using .NET Core, which is the most portable version of .NET (e.g. can be used to write code for Linux, Mac etc), then I suspect it’s possible to use this in other environments too.

[novreis]

hi Dragon, thks for your kind words but in fact I am a 68 years old (I am economist but the last 15 years of my carreer was as CIO, not a programmer) and of course I am learning everyday but the OOP or what you cal it I don’t understand well. Interfaces, delegates, etc are things I don’t know and seriously I don’t care. But I know to use Visual Studio debugger and I got what I wanted with your code but it will be quite difficult to integrate your code at my application.
What I did was quite simple! I changed the default to simvarstring and “voila” my next point id is a string now.
default:
simConnect.RegisterDataDefineStruct<“SimVarString”>(simReq.DefID); // We’ll presume default values being requested are numeric
break;
Hope someone can benefit with this.
Note - the " " must be deleted at “SimVarString” because this FS Editor deletes this string !!!???
I also forced unit “variable length string” like you have at Title.
Thks

[Dragonlaird]

Hi @novreis,

I see the problem, it’s due to the SimVar definition not being populated (the SimVarUnits class contains the list of all SimVars and was generated from the SimConnect documentation several months ago).

The documentation used to contain Units & Data Types for some SimVars, for this particular SimVar, the Data Type was not populated, hence it was defaulting to a numeric value (which is what the documentation at the time specified was the default).

I see the documentation has since been updated (quite recently) to fill in many of the blanks, I’ll regenerate the SimVarUnits class to update it.

In the meantime, I’ll patch the master repository of the project to check if the Units are declared as a string, and default the Data Type to string for those, that should fix the problem until I modify the list of SimVar definitions.