Re: Answer dialog: Undocumented feature or risky hack?
On 24/5/01 10:24 am, Scott Raney [EMAIL PROTECTED] wrote: The other option is to add a little AI where the script would detect conflicts like this and do a search for appropriate alternatives. No loss of backward compatibility, but the choices the script makes might not be the same ones the developer would make. Any preferences? And if anyone decides to do this, by all means send us the script. It's unlikely we'll get to this one before 2.4 is released. This is already in Revolution's implementation of the answer dialog (we scripted it to use AI). Kevin Kevin Miller [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited - Power to the Developer! Tel: +44 (0)131 718 4333. Fax: +44 (0)1639 830 707. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Answer dialog: Undocumented feature or risky hack?
Scott Raney [EMAIL PROTECTED] responded regarding the answer dialog creating the same mnemonic for different options as follows: Guess this is a case we hadn't considered. I'll bug report it. Since MetaCard doesn't resolve the conflict when two options start with the same letter, I suppose I need to change my terminology, say replace Complete with Total. I can think of two other ways to deal with this situation, both of which involve enhancing the scripts in the answer dialog (and, yes, you can do this yourself). The first would be to have it accept embedded mnmonic tags like menus do (i.e., the character after a is the mnemonic, and the gets stripped out). The advantage is that the developer has precise control over the mnemmonic. The disadvantage is loss of backward compatibility and maybe a bit of surprise for the new developer who tries to put an in one of the choices (you'd have to put in where you want a single to appear). The other option is to add a little AI where the script would detect conflicts like this and do a search for appropriate alternatives. No loss of backward compatibility, but the choices the script makes might not be the same ones the developer would make. Any preferences? And if anyone decides to do this, by all means send us the script. It's unlikely we'll get to this one before 2.4 is released. Regards, Scott I have a system extension on my Mac that takes the second approach in creating command-key-plus-letter-key keyboard equivalents for Mac OS dialog boxes. It inserts a red underline under one of the letters of the descriptor on each button to indicate what letter is to be used. It does this not only for the standard dialogs such as Print and Save but also for the highly specialized ones such as those unique to PageMaker. It seems to work well, usually taking the first letter. One AI feature is that it appears to always set up Cancel as Command-A even if there would be no conflict with using C. This second approach would be slick, but would be more work for Scott's crew to develop and assure that it doesn't create more problems than it solves. The first (ampersand) approach would be easier to implement, would create fewer if any new problems, and would give MetaCard application developers the ultimate control. Also, there is the question in my mind of how important this matter really is. Do people use keystroke mnemonics enough to warrant the effort to finetune this feature? (I know that even though I have beaucoup keystroke options on my Mac with my system extension, I rarely use them.) In case it is of interest to anyone, the system extension is called QuickTools Dialog Power!, copyrighted by Advanced Software, Inc. in 1992. In spite of its age, it still works with my vintage 1997 version 8.0 Mac OS. (Do you get the idea that I wait until others have worked out the bugs before moving on to the next version of the software I use. :-) ) John Kiltinen Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Answer dialog: Undocumented feature or risky hack?
I have a first question about the behavior of the answer dialog with MetaCard 2.3.2 and a second question about a scripting challenge that led me to the first one. I have on a stack a button which brings up an answer dialog which asks the user to choose among options, A, B, or C (or cancel). In order to accelerate the process, I have been trying to find a way to allow for the user to hold down one of these keys, a, b, or c, while pressing the button thereby bypassing the need for this answer dialog opening. While experimenting with this, I have discovered what is either an undocumented feature of the answer dialog or an interesting hack. When I press the button that has the answer command in its script while holding down the a key, the answer dialog box opens with the button for the choice A highlighted as it would be when pressed. In a fraction of a second, the answer dialog closes and the program takes the action that results from pressing the A button of the answer dialog box. The corresponding thing works with the b and c keys. Upon further experimentation with another answer dialog that offers buttons with the choices Endgame, Complete, and Buttons, I found that a virtual press on these buttons is gotten by pressing the e, c, and b keys respectively. Apparently the first letter of the option is enough. The key can be depressed as the answer dialog is opened or can be pressed after it is open. I've found no mention of this behavior in the MetaCard reference. Is this an undocumented feature, or have I discovered an unintended hack? Now to my second question. The way I was trying to do my own keyboard bypass of the dialog was to have the following keyDown handler in the script for the stack: on keyDown X put X into LetterBox send clearOutBox to me in 2 seconds end keyDown LetterBox is a global variable which the mouseUp handler script of the button in question checks before giving the answer command. If LetterBox contains the right letter, then the script takes the appropriate action rather than bringing up the answer dialog. The clearOutBox handler simply empties the global variable LetterBox. This handler does the job nicely from the stack script. Unfortunately having this handler in the stack script also prevents the user from typing into a field in another part of the stack when this is needed. I moved this handler to the script for the button. It appears that if one sets the autoArm property of the button to true, then the button will accept the keyboard focus and this keyDown handler works fine from the button script while not interfering with entering data into other fields when needed. My question: Is there a better way to do what I am trying to do here. Does anyone see any pitfalls with this approach? (I am nervous because I find nothing in the documentation that this is how autoArm is supposed to work for a button.) John Kiltinen Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
