Huh? Both sentences sound like they are saying the same thing - doing the same action - except you want to triple-click instead of double-click.
Let’s see … in both cases you are clicking on the PatientID field. In both cases that’s in (on) the patients file. In both cases you want the related record in admissions.
Sorry, except for the triple, instead of double, click, I don’t see the difference.
When I double-click on the PatientID of a record on the ‘patients’ file, it selects the PatientID, allowing me to edit it. Only when I click-out of the patientID field does it take me to the corresponding related record in the related file.
Since double-clicking sets the text editable (which is useful), I thought it would be better if I could triple-click to navigate to the related record.
I think attaching the code to the field this way is not the best idea. The way you’ve set it up, you can’t edit the PatientID field without jumping to the other database. Also, you can’t jump to the related record without editing the field. As for triple clicking - that already does something: it opens the cell for editing and sets an insertion point in the text. Editing and jumping to the related record should be separate user interface items, not combined like this.
I think you would be much better off putting this code in a named procedure, so that you could trigger it from the Action menu. You could assign it a shortcut key if you wanted.
It’s really not a good idea to include this sort of code in the field code. For one thing, if you press the Tab key when you are editing, Panorama will get very confused because it cannot both tab to the next field and switch to another database. In fact, the documentation states that the field code should not do anything that changes the current position within the database, which includes switching to a different field or to a different windows.
Also, Panorama also has a command built in to perform the select related action - just go to the Search menu and choose Select Related In.