GPS/Nav speed question

[zip]

Hello Pete,

An issue rages on with the Captain Sim 707 and FSNavigator, in that to use an external heading source, the 707 (Version 1.1), requires GPS Navigation mode to be on, and FSNavigator in a classic turn of Murphy's Law, turns GPS mode off (and forces it off) the moment you engage the "set heading and hold course" mode.

This inherent conflict had me make my GPS/NAV switch on atngau 1.3.6 sticky, in that it checks to see if the mode is off, and turns it back on if it's supposed to be on (undoing FSNav's logic).

This on/off cycle is interesting, inefficient and a poor man's way of fixing a couple of wrongs, so two questions while we wait for this problem to be addressed:

1) is FSUIPC's offset 0x132C faster than a send key event in FS?

2) any better ideas on possibly preempting the GPS/NAV off call so this becomes entirely unecessary?

Cheers,

Etienne

[Pete Dowson]

1) is FSUIPC's offset 0x132C faster than a send key event in FS?

It will be faster by by-passing PANELS.DLL and the sending of the control via Windows message queue (that's all PANELS.DLL does with the key events). FSUIPC writes directly to the switch location in the simulation engine.

Of course, you have to offset that against the call, via a SendMessage, you need to make to FSUIPC. I doubt you'd be able to measure the difference really, and it won't matter in any case unless it's a frequent event.

2) any better ideas on possibly preempting the GPS/NAV off call so this becomes entirely unecessary?

Not really. You could try intercepting the control -- you'd need to subclass FS's FS98MAIN window and trap the WM_COMMAND with that control number. Not sure what you'd do with it though.

Regards,

Pete

[zip]

Thanks for the answer, I'm going to experiment some more.

Speaking of subclassing, there is no listener "event" callback from FSUIPC is there (this to trap FSUIPC writes)?

[Pete Dowson]

Speaking of subclassing, there is no listener "event" callback from FSUIPC is there (this to trap FSUIPC writes)?

No, sorry. Why?

Pete

[zip]

This was just an idea you gave me when you talked about subclassing.

One of the reasons to subclass is to filter or trap events and preventing them from being forwarded. This is a standard way to filter messages in Windows that we don't want to propagate.

For example, in the situation above with the GPS/NAV circuit, it would be nice to be able to trap the GPS/NAV mode toggle request sent by FSNav to FSUIPC (assumption: FSNav uses FSUIPC) and preventing it from occuring via a filter. Of course, there may be a way to do just this as Eric Marciano just found out how to use the register_key_event() handler without having FS crash.

This is similar to your new offset to prevent flap or gear movement, but would apply to non-continuous event types (such as circuits on/off).

Makes sense?

[Pete Dowson]

This was just an idea you gave me when you talked about subclassing.

One of the reasons to subclass is to filter or trap events and preventing them from being forwarded. This is a standard way to filter messages in Windows that we don't want to propagate.

I understand that, of course, but:

For example, in the situation above with the GPS/NAV circuit, it would be nice to be able to trap the GPS/NAV mode toggle request sent by FSNav to FSUIPC (assumption: FSNav uses FSUIPC) and preventing it from occuring via a filter.

FSNav does not use nor depend upon FSUIPC. It never has. In fact it isn't likely that anything internal to FS would use FSUIPC for such a simple thing as operating a switch available to all via FS controls or Key Events.

Pete