Trapping/monitoring keys and events in XML

[rcbarend 37]

I know the following: in an XML gauge, the codeMyCode1.....MyCode2....will:- "Trap" keystroke "K" and execute MyCode1- I call this "trapped" , because if an event is assigned to "K", this event is NOT executed (only MyCode1 is).- "Monitor" event "SlewToggle" and if detected, execute MyCode2- I call this "Monitored", because FS not only executes MyCode2 but also the "SlewToggle" event.My questions:1. How do I "trap" an event?I.o.w., in the example I want the MyCode2to execute MyCode2 but NOT execute the "SlewToggle" event itself.So, have it working like the On Key code.Is this possible ? How ?2. How do I "trap" a Shifted/Cntr'd key, like Shift-Control-K, instead of just a plain ASCII key ??MyCode1 doesn't work of course :-)Thanks in advance,Rob Barendregt

[Rocky 128]

Hello Rob,Question 1: the only solution I know is to trigger the opposite event to cancel the effect of the first event. In your example, to trap the slew mode toggle, you would have to cancel it by triggering another slew toggle event. I'm sure you already know this solution.Question 2: No answer in XML.I think you should learn C++, these questions have an answer in C++ ;-)Eric

[rcbarend 37]

Hi Eric,Those are not really the answers I was waiting for ..:-)The reason why I want to "trap" an event, is because I found out that some "unexpected" events in some situations causes FS to crash. (Slew was just an arbitrary example) See the other thread. Hence repeating the toggle command as a way to reverse it is not an option :-)And since "taquilo" (Tom) suggested in that thread that this could be done, I was just wondering HOW ...And about C++: Yes, I know your preference ...:-)Cheers, Rob

[taguilo 33]

Hi Rob,So far I've tested, there is no way to "trap" an event like you want (ie, avoid its execution). In that thread I meaned "trap" what you call "monitor".However, inside an event you can assign the value of the associated A:var to a L:Var and then use this one to control the "output" from there.For example:(L:Flight Controls Press Avail, bool) !if{ (L:Elevator Deflection, percent) 163.83 /-/ * (>K:ELEVATOR_SET) }els{ (A:Elevator Position, percent) (>L:Elevator Deflection, percent) } Will let you move the elevators free as long as you have hyd press.When you have none, it freezes in the last known position.This is a basic example, but indeed very powerful.Regards,Tom

[rcbarend 37]

Hi Tom,That's what I suspected ..But thanks anyway for answering.I know the OnEvent handling can be very powerfull (I allready use that extensively). I was just looking for a way to solve this potential "Afterburner" crashing I mentioned in the other thread.Cheers, Rob

[Rocky 128]

Hello Rob,OK, now I understand, you want to trap the afterburner event that sometimes crashes FS. I saw your other post, and I think it is an FS bug.Now you know that I use C++ only, and the equivalent of the XML "OnEvent" exists. I have been using it a lot, and I have been searching for a solution to trap an event. Sorry to say I didn't find any, and the way to do this in C++ is through some low level Windows functions that traps the keyborad events before FS can "see" them.Eric

[rcbarend 37]

I knew I didn't had to learn C++ to solve this ...LOLWith a little educated guessing, I found the answer to my question: "How to trap Shifted/Controlled keystrokes in XML"I discovered, that instead of using:...FS also accepts...with '90' being the Windows keycode for the 'Z' key.Now, since keycodes are ranging from 0-255, I wondered how MS would internally store the value for shift/control sequences.I took an educated guess, by adding multiples of 256 to the keycode; and behold: IT WORKED !!Iow:- ... traps "Z"- ... traps "Shift-Z"- ... traps "Control-Z"- ... traps "Shift-Control-Z"FYI: A list of all Windows keycodes can o.a. be found in Peter Dowson's FSUIPC Userguide. An extract of that info is attached to this post..Cheers, Rob Barendregt

[Guest Tomcattwo]

Well done, Rob! Congrats and thanks for sharing that. Regards,TC2

[taguilo 33]

Rob,Although I didn't have the need to use so far, this is a point I would have to come across in a more advanced step of my 757 project, so THANK YOU for posting the answer:-)Regards,Tom

[phjvh 0]

Rob,Bedankt!Jan"Beatus Ille Procul Negotiis"

[Rocky 128]

Congratulations, Rob !!I think you will have to teach me XML very soon ;-)Eric

[phjvh 0]

So,And now something to translate:10 19 (C:fs9gps:enteringInput) rng 31 (C:fs9gps:enteringInput) == or(M:Key) chr (>C:fs9gps:IcaoSearchEnterChar) @InitBlinker110 119 (C:fs9gps:enteringInput) rng 131 (C:fs9gps:enteringInput) == or(M:Key) chr (>C:fs9gps:NameSearchEnterChar) @InitBlinker(C:fs9gps:enteringInput)10 19 (C:fs9gps:enteringInput) rng 31 (C:fs9gps:enteringInput) == || if{ -1 (>C:fs9gps:IcaoSearchBackupChar) @InitBlinker quit }110 119 (C:fs9gps:enteringInput) rng 131 (C:fs9gps:enteringInput) == || if{ -1 (>C:fs9gps:NameSearchBackupChar) @InitBlinker quit }Who more?, quit busy with it.Jan"Beatus Ille Procul Negotiis"

[rcbarend 37]

Yikeesssss....I just found out that(unlike 'On Event' monitoring) the 'On Key' trapping only works if the panel window in which the gauge that contains the trap code is defined, is visible !!!I.o.w. the key is NOT trapped when you e.g. switch to SpotPlane view, unless you place the gauge in a permanently visible (i.e. Undocked) window.Although this "feature" could be very handy in some cases, it makes it useless for my application (blocking specific user input under all circumstances).So back to the drawing board ...:-(Rob

[phjvh 0]

Rob,I knew, because the same happens with my FMC/GPS, when it is not visible; so i made a seperate window for it.May be a transparant, always visible window with only code?Jan"Beatus Ille Procul Negotiis"

[rcbarend 37]

Hi Jan,I thought about that too.But how do you make a window that is always visible ???Because when you go to spotplane view (or remove the panel in Cockpit view via the W key), a window will disappear automatically.Rob