Hi,following on my previous post, I'm making progress on using SimConnect. However I now face another issue. Here is.I open SimConnect, subscribe to 1 event like "Pause", and CallDispatch() on my callback (it is in a gauge, so my callback is automatically called by simconnect and I don't need any polling/event wait system to process the incoming notifications. So far so good.However, once the call to CallDispatch is made, I can no longer make calls to SubscribeToSystemEvent() (and I've not tried other calls).It seems that as soon as you tell SimConnect "start to dispatch messages to my callback", it won't accept dynamically changing what you are subscribing to!?!I'd like to init/open/calldispatch SimConnect when the gauge loads, and from then, whenever I need, subscribe/unsubscribe to events. Have some of you succesfully used SimConnect this way (ala open a pipe, and later tell what to send or not to the pipe), or, is SimConnect locked in the way you have to tell it first what you want to listen to, and only then you tell it ok, now I'm ready to listen and won't hear anything else?!?!

>It seems that as soon as you tell SimConnect "start to>dispatch messages to my callback", it won't accept dynamically>changing what you are subscribing to!?!I've not found that, but then I'm in a DLL not a gauge. I'm wondering if there's some differences in how Simconnect handles gauges, maybe because they can come and go quite a lot during a session unlike DLLs.Like you, I don't poll SimConnect, but the technique I use is having a Message Window and telling SimConnect, in the _Open call, the Window handle and message ID. My dispatcher is then called from the Window procedure.I don't actually subscribe to anything at all until I've received a reply, in my dispatcher, to the Open call. That tells me the SimConnect version number, which I check in order to know which features I can use (e.g. the SimConnect_Text facility wasn't available till SP1).RegardsPete

Indeed it is different. Notes from the documentation explains that in the case of an in-process DLL (a gauge), the callback is automatically called by the internal SimConnect dispatcher when there is an event (an event you have subscribed to). This way, you don't need to pool/event loop, FS does it for you just calling your callback when it is meaningfull.I guess I'll have to raise the question to the other place too, at least to ensure it is a feature (locked) or a bug (should not be locked).thanks for your input!

Jean-Luc-Pete's FSUIPC and your gauge are both handled as in-process DLLs. The difference lies elsewhere and ACES would be well to help out if you continue having this issue...

Thanks Lefteris, I've raised the question now in other places. Do you by any chance have a clue about solving this, or do you think it is indeed a bug of some sort?!

Hi Jean-Luc-I am curious as to why you'd need to subscribe/unsubscribe dynamically, though I remember that in-process code does this well (been a while since I played with that feature).

Hi Lefteris,the idea is simple: in my gauge framework, I already open SimConnect and establish an internal callback to process FW needed events. My framework (exposed in the gauge and panel folder) offers an interface to events in the form of OnEvent (OnDraw(), OnUpdate() etc...) and since I already have a pipe, it would be neat to also offer an OnSimconnect() to the user of the FW, for which he can subscribe to his own events (in addition to the ones already used internally by the FW).This is why I need to be able to subscribe/unsubscribe dynamically AFTER the pipe is open, not before.