Gauges and module

[coolchris]

Hi Peter. I have the recent version of FSUIPC. The problem is that the heading and course gauges etc will only move in increments of 10 not one. I have tried to alter it in the technical tab, but will not change. I need it for fine movement of the heading etc. Could you let me know what I maybe doing wrong?

Thanks and all the best.

[Pete Dowson]

Hi Peter. I have the recent version of FSUIPC. The problem is that the heading and course gauges etc will only move in increments of 10 not one. I have tried to alter it in the technical tab, but will not change. I need it for fine movement of the heading etc. Could you let me know what I maybe doing wrong?

That's always been a symptom of some complex panels, which send many many controls to FS all the time and cause the FS control acceleration to operate.

FSUIPC cannot actually fix the panels, but enabling the "fix control acceleration" option in the Technical page has so far always managed to defeat the panel bug.

Regards,

Pete

[coolchris]

Thanks for the input. Will now fiddle a bit with the panels in question.

[n4gix]

That's always been a symptom of some complex panels, which send many many controls to FS all the time and cause the FS control acceleration to operate.

Pete, most of those problems are cause by (ehem!) poor gauge programming that constantly triggers an event. Most often, this occurs with XML gauges, since they are so simple that a lot of "non programmers" will give 'em a go... :wink:

The only "troubleshooting method" that seems effective is to disable all VC gauges, then systematically disable (// out) each 2d panel gauge until you've found the one (or more) that are causing the problem...

[Pete Dowson]

Pete, most of those problems are cause by (ehem!) poor gauge programming that constantly triggers an event.

Yes, I know. This sort of things has been going on with assorted panels for some time, and not only in FS2004. I think the 767PIC for FS2002 also had such problems occasionally, but it depended on the speed of your PC.

The "fix control accelerations" option in FSUIPC clears down the internal FS acceleration timer when it sees a control arrive into FS which is different to the previous one. The acceleration should really only occur if there are successive controls for the same thing (as, for instance, incrementing the heading), but Microsoft didn't bother to check for this as, with their methods, such fast different controls arriving wasn't likely to ever occur.

This 'fix' has worked in the past with all such panel problems, but possibly the XML access methods aren't going through the same route, so FSUIPC misses them? For instance, FSUIPC cannot see controls which result from keypresses, only from button presses and calls to the PANELS "trigger key event" routine. Both of those give rise to a WM_COMMAND message to FS's main Window, and FSUIPC intercepts these.

Regards,

Pete

[n4gix]

This 'fix' has worked in the past with all such panel problems, but possibly the XML access methods aren't going through the same route, so FSUIPC misses them? For instance, FSUIPC cannot see controls which result from keypresses, only from button presses and calls to the PANELS "trigger key event" routine. Both of those give rise to a WM_COMMAND message to FS's main Window, and FSUIPC intercepts these.

MS didn't really provide enough information to answer the question. However, it is clear that the sim itself is "parsing" the XML instructions and "translating" them to some other executable form. It's fairly certain that at the end,

KEY_INCREASE_THROTTLE © & INCREASE_THROTTLE (XML)

are both acting on the same internal FS stack, but it's unlikely that parsed XML code is using the PANELS "trigger hey event" routine, as there are too many differences in the list of available commands. There are some XML commands that do not have XML counterparts, and vice-versa.

[ddawson]

The gauges.h file included with the FS9 Panels SDK includes this definition:

typedef (*GAUGE_KEY_EVENT_HANDLER) (ID32 event, UINT32 evdata, PVOID userdata);

Don't know if this would be of any use in FSUIPC or not. I actually used it to create a gauge which detects repeating key events. It just logs everything to a text file. I just checked, and it does intercept commands issued via the keyboard interface.

I am aware of that facility, but up till now I really didn't have a use for it. The use of the keyboard for these things isn't the problem here, it seems it's the way the XML gauges interface to the FS control procedures which seems to be the problem with the acceleration fix.

Does your gauge pick up the calls from XML gauges? If so, it could be a solution.

Regards,

Pete

[Pete Dowson]

However, it is clear that the sim itself is "parsing" the XML instructions and "translating" them to some other executable form.

Hmmm I wonder if they are calling the SIM1 event execution routine directly. I do the same for most of those things I want to be efficient -- the Panels "Trigger Key Event" system is rather inefficient really -- PANELS does decode them but in nearly all cases all does with them then, these days, is forward them on as WM_COMMAND messages to FS98MAIN, and the WM_COMMAND routine in the Window Procedure then calls a routine in SIM1 which decodes them all over again.

In Fs98 the PANELS routine's tables did actually point directly to the GLOBALS values -- and writing those was effective, as SIM1.SIM (as it was) would be monitoring those values and acting on them. This is why FS6IPC was relatively simple compared to the agonies I have to go through in FSUIPC..

FS2000 was a mix of that and the SIM1 calls, but by FS2002 and FS2004 it had almost completely changed, yet the same table decoding is in place in PANELS.DLL.

I suppose I should be grateful as it enabled me to deal with the things I needed to deal with in an evolutionary manner.

Regards,

Pete

[ddawson]

I am aware of that facility, but up till now I really didn't have a use for it. The use of the keyboard for these things isn't the problem here, it seems it's the way the XML gauges interface to the FS control procedures which seems to be the problem with the acceleration fix.

Does your gauge pick up the calls from XML gauges? If so, it could be a solution.

Regards,

Pete

Pete,

Yes it does. It seems to pick up everything. I had to filter out the joystick axes_set commands, as they showed up too.

Doug

[Pete Dowson]

Yes it does. It seems to pick up everything. I had to filter out the joystick axes_set commands, as they showed up too.

Okay. I'll look to see if I can change over the "fix control accelerations" option to work from that PANELS call instead then, though it won't be as easy as doing it from a Gauge. FSUIPC is running all the time, but the panels stuff normally has to be mde and unmade each time a Panel is loaded/unloaded. However, I'll delve into it and see where to place a more permanent hook.

Thanks!

Pete