some1

Thank you Pete for the quick hotfix. I also changed it on our side, so the next update to C172 will remove this issue completely.

Pete, sorry for the late response. I tried your suggestion, but this fix does not work. Anyway, since I learned that simconnect events are not affected by this issue, I will use them to tune radios instead of Panel API.

Unfortunately this is not the case here. A simple three lines of code in the aircraft's c++ gauge like this: trigger_key_event(KEY_COM_RADIO_SWAP, 0); trigger_key_event(KEY_COM_RADIO_WHOLE_INC, 0); trigger_key_event(KEY_COM_RADIO_SWAP, 0); will send the events to FSX in the correct order only if FSUIPC works in the unregistered mode. When I put my FSUIPC key file, then the events get reordered as I described previously. This is reflected in FSUIPC event log. What's interesting, is that when I send events using Simconnect calls instead of C Gauge API, then it works fine.

Hello Pete, during testing of A2A C172 we have found that there is a potential issue with how FSUIPC processes radio events. Basically, the sequence of events like this: NAV1_RADIO_SWAP NAV1_RADIO_WHOLE_DEC NAV1_RADIO_SWAP is transmitted to FSX in this order: NAV1_RADIO_WHOLE_DEC NAV1_RADIO_SWAP NAV1_RADIO_SWAP NAV1 is just an example, it happens with all radios (COM, NAV, ADF). We need to send such sequence because the radios in C172 have an "active entry" function, which allows you to tune the active frequency directly, even though the radio has both active and standby. Because this issue happens only with the full FSUIPC version, I suspect it is a "feature", but I can't find anything in the configuration to turn it off. Can you advise how the FSUIPC should be configured to restore the original events order? best regards Mike Krawczyk A2A Simulations.