Key On events

[Guest jprintz]

Can anyone think of a reason why the following (a simplified hypothetical) would not work in a gauge?(A:Airspeed indicated, knots) (>L:Var1, number)I've searched through the forum, SDK's, etc., and that seems to be the right syntax. ??

[Guest jprintz]

**********Bill answered this over at the FFDS forum. Thanks Bill! Helpful as always.Just in case anyone has a similar issue in the future, I'm going to post this, so there's a solution with the question and a more direct answer than I found elsewhere. Anyway, the answer is that the whole "keys" section must be below the mouse section, as in the outline below, and not within the main element of the gauge. Why I didn't see this in the SDK I have no idea. Anyway, in case someone has a similar issue in the future:************************* gauge body goes here... mouse stuff key stuff here ************************

[rcbarend 37]

Hi,Oh boy, here we go again with FS versions :-)I assume you are trying this in FSX ??And if so, which version ? (RTM, SP1, SP2 or Accelleration)In FS9, FSX-RTM and FSX-SP1, I haven't been able to find any difference in where you put the Key-OnEvent section.Or between gauges that have / have no MOuse section.But there's another problem you should be aware of; that is, in FSX-RTM and SP1. And that's the following: The OnEvent trapping only works if the view in which the gauge with the OnEvent section is defined, is visible.So e.g.: if you have a gauge with an OnEvent section defined in a VCockpit** in the panel, the OnEvent trapping DOESNOT work when you are in an outside view mode.Again, this is with FSX-RTM and FSX-SP1; I don't know about SP2, but I would be very interrested to know if that problem was solved in SP2.Regards, Rob Barendregt

[taguilo 33]

Hi,As Rob stated, there is no difference in the order Elements, Mouse Areas and Keys sections are placed within a gauge, which seems logical as tags are interpreted by theirs names only.Unfortunately, the off-view trapping issue has not been solved in SP2 :-(Tom

[rcbarend 37]

Hi Tom,:-( indeed !After doing a little testing again, MS DID change something in this area between RTM and SP1.In SP1, if you define such a gauge in a Window** 2D-view, the trapping works both in 2D-view AND VC view. But not the other way around. Go figure ....And to be complete: in FS9 the OnEvent worked perfect, but the OnKey had the same problem as the OnEvent now in FSX.Cheers, Rob

[taguilo 33]

Rob, unfortunately doesn't work in SP2 as you describe.The must be defined in a gauge that is included within the current panel mode -2D or 3D- AND visible. If you put it on VC, only works in that mode; vice versa for 2D and no way to make it work in VIEW modes or external. A partial solution is to make Event trapping only gauges and place them duplicated in both panel modes...I am near to do some tests using a custom DLL to see what happens there.Tom

[rcbarend 37]

Hi Tom,I.o.w.: in SP2 it's same again as in RTM .. Right ?And if I understand you correctly: the "partial solution" doesn't work in external view in SP2 also. Right again ?There is one trick I know of, to have the OnEvent trapping working always. But it's so cumbersome I never used it.And that goes as follows (again: in RTM and SP1, don't know about SP2):Doug Dawson made a freeware gauge, that detects whether a panel window is opened or not (maybe there are other ways to determine that directly as well).Now, if you place the OnEvent code in a gauge without bitmap that is defined in a transparant 2D-window that is constantly being forced "opened" (by opening it when the 2D-window is detected "closed" , eg. after a view change), the OnEvent will always work. In any selected view.I use this trick to have some window Icons permanently visible, a.o. in my my FSX groundhandling and CarrierOperation packages.Works well, but a bit overkill to just have some OnEVent code always working.Cheers, Rob

[n4gix 4,947]

>Hi,>>As Rob stated, there is no difference in the order Elements,>Mouse Areas and Keys sections are placed within a gauge, which>seems logical as tags are interpreted by theirs names only.That may well be true, but explain WHY it didn't work until moved where suggested?Nothing other than the position in the XML script...BTW, originally the OP had this: (A:Airspeed indicated, knots) (>L:Var1, number) which quite obviously will NOT work... ;)

[rcbarend 37]

Hi Bill,Of course you are right: placing the "Keys" section within an "Element" section probably won't work (I never tried that).But the OP didn't say in this thread he was doing that :-)Hence Tom's / my comment...Cheers, Rob

[taguilo 33]

Hey Rob, The idea of keeping a transparent panel with Event gauges always visible seems pretty neat. Fortunately I can code that C gauge by myself, being this an easy solution, but actually I am trying to go a bit farther just by placing the Event trapper on a custom DLL and see whether it can be recognized across the entire panelset. Currently I'm in a struggle to make the DLL register the trapper function, with no sucess so far :-(Tom

[taguilo 33]

Bill, if that was the situation, of course it will never work. is one of the basics tags together with , and . None of these can contain any of the others within its own structure. But the order in which they are placed in a gauge is irrelevant, should work fine with any. Tom

[n4gix 4,947]

>But the order in which they>are placed in a gauge is irrelevant, should work fine with>any. Of course. However, I'm a firm believer in 'following the established recipie' whenever possible, since if nothing else......it is proven to work! ;)It's hard enough as it is having to deal with four very different XML schemas. I will be SO glad when FSvNext introduces a more unified approach via LUA... :-lol

[taguilo 33]

>>But the order in which they>>are placed in a gauge is irrelevant, should work fine with>>any. >>Of course. However, I'm a firm believer in 'following the>established recipie' whenever possible, since if nothing>else...>>...it is proven to work! ;)Yeah, I second that. However, I also like to know when there are other options to choose from in different situations.>>It's hard enough as it is having to deal with four very>different XML schemas. I will be SO glad when FSvNext>introduces a more unified approach via LUA... :-lol Bill, I think you've been playing too much with XML...do like me, stick to C++ and everything will go pefect! :-lol :-lol :-lolTom

[n4gix 4,947]

>>It's hard enough as it is having to deal with four very>>different XML schemas. I will be SO glad when FSvNext>>introduces a more unified approach via LUA... :-lol >>Bill, I think you've been playing too much with XML...do like>me, stick to C++ and everything will go pefect! :-lol :-lol>:-lolThere's no choice in the matter as long as I'm working with 3d modeling...You can't embed C++ in a compiled model... :(I can't even get away from XML when working with C++ gauge coding, as I have to write the gauge to provide a bi-directional interface with the 3d model.