I was just playing with a way to simulate the tab direction option as a temporary work-around. If you set a fileglobal to the direction you want to tab ("“vert” or “horz”), you can use this value in a procedure to be called from the code panel of each field. I made a procedure I called .tabbing with this code:
return
tabForward:
if tabDirection="vert"
downrecord
functionvalue info(“fieldname”)
else
right
functionvalue info(“fieldname”)
endif
return
In each field’s code panel I added a call .tabbing line at the end of any existing code. I also made another procedure I called Toggle Tabs with this code to toggle between the two settings:
define tabDirection,"vert"
If tabDirection="vert"
tabDirection="horz"
else
tabDirection="vert"
endif
So, if tabDirection is set to “horz” it will tab as normal from field to field. If it is set to “vert” it will tab from one record down to the next. You can add traps for the end of the file or the last field as needed. Seems to work fine in my limited testing but buyer beware.
I’ll second the “buyer beware” part of this. Changing the record in the tabForward: code is definitely not how it was intended to be used. I’m surprised it doesn’t crash right away.
Did you actually try this at the end of existing code? I don’t think this will work unless it is the only code in the field’s code panel. If the code in the code panel is nothing but one call statement, Panorama treats the called procedure as if it was in the field code panel, and looks for things like tabForward: in that procedure. But if the field code panel has more than one line of code, it only looks for the label in the code in the panel. It doesn’t look in every subroutine called by that code.
Sorry, but this is very unlikely as far as the next update goes. The 10.2 update is already seriously behind schedule. It’s unlikely that I’ll be adding any more cans of worms to the list.
Of course not, I was just playing with what I had at hand. I did issue a warning just in case of something like this popping up. Probably best to keep my experiments to myself in the future.
Probably best to keep my experiments to myself in the future.
Nah, I disagree, keep pushing the envelope. I can always add my thoughts!
And maybe the downrecord is ok here. I’m kind of surprised, but if you say it seems to work… However, probably safer would be to start a timer with the downrecord statement.
For tabbing in the horizontal direction, I don’t think using the right statement is the way to go. Though it’s way more work, I would say the kosher way to do it is to calculate the name of the next field and return it. Then Panorama will take care of advancing to the field you have named. Though maybe it works by happy accident since Panorama is going to move it to the field you have already moved it to.
Really though, the only intended use of this tabForward: routine is to calculate a field name, it is not supposed to have any side effects.
The tidbit about putting these labels in a separate procedure is documented, but it could be very easy to miss. It’s toward the bottom of the page, I’ve quoted the relevant paragraph below.
If you prefer, you can move the field code to a separate named subroutine, and call it from the properties panel. This can be more convienient for editing and debugging, and also allows you to share the same code among multiple forms. If you do this, the code in the properties panel can only contain one statement – the call statement that calls the subroutine. If Panorama sees just this one statement, it will look in the subroutine for any special labels like tabForward: and tabBackward: . If there is more than one statement, the labels must be in the properties panel.
and then just use CTRL-TAB to tab down. You can do it with thumb and forefinger, it becomes second nature quite quickly and it’s actually faster than clicking on a TabDown icon.
Ctrl-Tab was already used by an utility program, but I was able to substitute Ctrl-Option-Tab which is still easily typed. However, I found an odd side effect. Invoking the hot key repeatedly in a “Choices” type field it was copying the Choice of the original record into the subsequent records. Which had previously held different choices. Conceivably I’d set that key combo somewhere else so am getting the anomolous results. But I’m not recalling or finding such at this time.
I played with this more and something is odd invoking it in Choice fields. I made new db with .Initialize procedure having only MIchael’s definehotkeys code and no other code. Quit Keyboard Maestro and whatever programs I thought might be conflicting (CTRL-TAB rather than CTRL-OPT-TAB) can now be the hotkey I’m testing. Made A a Text field and B a Choices one with same values. Repeatedly invoking the hotkey in the text field, without hitting Enter to close the editbox between hotkeys, works as expected. Doing the same in the Choices field, starting on record n, changes the value of records n+2, n+3, etc to whatever the value had been for record n+1. Choice palettes pops up serially for each record after n, but rather than pre-loaded with their previous value they all contain the value from record n+1. Or perhaps more likely, invoking the hotkey with the Choice palette open saves that value to that record then pre-loads it, rather than the next actual value, when the palette reopens one record down.
I’m not sure whether this constitutes a bug or whether it’s a case of Michael’s (shared) interface dreams getting ahead of what PanX’s code presently allows. Perhaps fancier hotkey code could work around this, but not understanding why it isn’t working in choice fields I don’t know how to patch it.
b31 updated the Unimplemented Statements and Functions
help page. Of the 48, black, non-deprecated and still potentially to be implemented entries two were tabdown and info("tabdown"). Jim’s not given up on tabdown!
