Issues with programs started via the EXE.xml method

[ImpoliteGem5317]

Your response seems to be related to another issue I raised, not this one… what has your response got to do with the performance degradation of applications started via the EXE.xml? Why would the general performance of an application (and I am not talking about the data reception rate here) be reduced just because the app has been started by MSFS? Do you do anything with the thread priority levels for such applications?

@Umberto67

Are you able to at least open Simconnect, even if you can’t do anything with it yet ?

Sometimes yes, sometimes not. If I do not receive a response from the open call in a defined period, I close and reconnect. If I receive a response within the required time-limit, I then define my data, request sim events and the user object, and wait for the user object response to be retuned before I request data. Sometimes the user object that is not being returned within the required time-limit, and this is due to another issue I have raised (random simconnect disconnect issue). This can happen regardless of when my app is started, and is not related to the performance degradation I reported here.

@Umberto67

If yes, are you calling the Simconnect Dispatch explicitly, so you are running a main infinite loop?

I use both methods - an explicit call to process the request of the user object, and I then enter an infinite message loop for the main dispatch thread. There are no issues with my message processing.

@Umberto67

If yes, try setting up a Dispatch callback instead, and in your Dispatch, wait for the SIMCONNECT_RECV_ID_OPEN event, and do the rest of your subscription there when the event arrives.

I don’t see how this can change things - my dispatch loop is running and running fast enough to process responses. Why would starting my app manually and having it started via the EXE.xml make a difference here? I do not request any data until the SIMCONNECT_RECV_ID_OPEN event is received.

@Umberto67

After you received the OPEN event, start monitoring the CAMERA STATE variable, and don’t do anything as long its value is 11 ( Waiting ), so you don’t risk trying to call Simconnect during the loading screen, where it might not yet read to respond properly, because is still loading other modules and packages.

I also don’t see how this can help with this issue (which is related to the performance when external apps are started via the EXE.xml method). I do monitor the camera state variable, and use this to trigger the start of many things, but not the data requested. This is all done once the open response has been received.
In theory, I could request this first in a separate data definition, and request the remaining data once the camara state is non-waiting, but I fail to see how this can affect the performance degradation I see. Can you explain please?

Can you not delay the starting of programs from the EXE.xml until these other modules and packages have been loaded correctly to prevent such issues? But this would only help with the second issue I reported here, not the performance degradation issue which I don’t see how can be related to the start-up timing…

Thanks,

John