Equation not triggering when tab is used

RAmeeti 2017-04-02 14:58:21 UTC #1

When using Procedure Style Formulas, I have a procedure in the Equation field that does not trigger when I tab out of a field.

ie. I start typing, I hit Tab and the formula does not trigger.
as opposed to...
I start typing, I hit 'Return' or 'Enter' (same key), and the procedure does get evaluated.

Any suggested fix for those times that the user chooses to Tab out?

dave 2017-04-02 17:39:56 UTC #2

I just tried this, and for me, a tab key always triggered the procedure. The field I was tabbing out of was treated as the active field while the procedure ran.

We may need to know what the procedure does in order to determine why it isn't triggered, or why it was but didn't leave any evidence that it had been.

gary 2017-04-02 18:08:37 UTC #3

I can confirm Dave's results in that the tab key always triggered the linked procedure. The only way I could get Robert's behavior is if I filtered a tab key out in the procedure as with:

if info("keycode")=48   // trap the tab key
   stop
Else
    message info("keycode")  // run procedure
endif

RAmeeti 2017-04-02 21:09:15 UTC #4

I love it when we can't agree.

1st field: Site Name
2nd field: Alarm Type
3rd Field: Site Number

Equation Field for «Site Name»: '.LookupSiteNumber'

Procedure '.LookupSiteNumber':

«Site Number» = lookup("Station Stats","Name",«Site Name»,"SiteGVR_ID","",0)
Field «Alarm Type»

If I enter a name in the «Site Name» field, and press tab, no 'Site Number' gets looked up and nothing gets entered into «Site Number» field.

If I enter a name in the «Site Name» field, and press the 'Enter / Return' key on a MacBook Pro 2016, the lookup happens and I get a result in «Site Number».

Robert Ameeti

dave 2017-04-02 21:45:07 UTC #6

I created a database named Station Stats with SiteGVR_ID and Name fields, and a Test database with Site Name, Alarm Type, and Site Number fields, in that order. Procedure was named .LookupSiteNumber, and it had the same two lines of code.

The Return, Enter, and Tab keys, all produced the same result. The site number appeared in the Site Number field, and the Alarm Type field became active.

I have no idea why we are getting different results.

RAmeeti 2017-04-02 22:31:06 UTC #7

Thank you Dave (and Gary) for attempting to duplicate the problem.

As Dave mentioned that he used both the Return, and the Enter keys, this leads me to believe that he is not using a MacBook Pro. I am guessing that that key may be mapped differently on the MacBook Pro. As Jim has recently purchased the same computer, perhaps he will find the key mapping is different.

Unless our resident genius knows how I might determine this on my own. (What say you Dave?)

Robert Ameeti

michael 2017-04-03 02:06:15 UTC #8

You can use info("keycode") to determine what the value of your keystroke was. If you have another Mac, do the same and compare them.

dave 2017-04-03 02:27:54 UTC #9

I'm using an iMac (27-inch, Late 2013).

In a NEW database, I ran the following procedure.

FileGlobal HotKey[*]
HotKey[*] = {Message info("keycode")}

When I pressed the tab key, the message was 48. The enter key was 76, and the return key was 36. Then I closed the database without saving.

You could try the same experiment, and see if you get the same results.

RAmeeti 2017-04-03 03:43:30 UTC #10

Tab was 48. Enter/Return was 36.

dave 2017-04-03 15:13:11 UTC #11

I don't know if it matters. I'll test again when I get a chance. The fields aren't in the order you said they were. In my test, Alarm Type was between Site Name, and Site Number.

dave 2017-04-03 15:19:52 UTC #12

From your video, it looks like tab is triggering the procedure, because the tab key alone would have left you in the Site Number field. To get to Alarm Type, the Field command in your procedure had to have been executed.

RAmeeti 2017-04-03 15:52:52 UTC #13

For greater clarity, I've entered 2 additional records in the Station Stats table. One that has Return and one that has Tab as their looked up values. They each also have their resulting values noting what key was used. Only the Return key's value comes back to the initial table.

Here again is the code:
«Site Number» = lookup("Station Stats","Name",«Site Name»,"SiteGVR_ID","",0)
Field "Alarm Type"

dave 2017-04-03 16:13:13 UTC #14

Try as I might, I can't duplicate your results. I changed the order of the fields to match those in your video. I added Clairvoyance linking. It continues to work just as it should.

RAmeeti 2017-04-03 16:17:58 UTC #15

And for clarity, here is a screen shot of my looked up table for this test.

dave 2017-04-03 16:18:50 UTC #16

For no particular reason, try reversing the order of those statements, and see if that makes a difference.

RAmeeti 2017-04-03 16:30:59 UTC #17

Very interesting. To me, I am imagining that the order of the 2 lines of code shouldn't make a difference in the end result but of course it does!

When using the Tab to proceed after entering a value in the first field, the result is to end up in the 2nd field with Panorama waiting for a user to enter a value in the 'opened' cell. I then entered Tab again, and it proceeded to move to the 3rd cell where upon hitting Return, it entered all values.

When using the Return key, all worked as I believed it should.

While I do accept that the Classic Panorama will not be updated for this sort of thing, I am kind of hoping that finding these items can perhaps thwart Panorama X from pulling them forward.