I have seen this quite consistently on a PowerBook G3 running MacOS 9.1, with a larger external monitor connected as the second monitor (ie no menubar) to the right of the internal main monitor. (It's an odd arrangement; what from the Mac's point of view is the main monitor, the left hand one with the menubar, is physically and ergonomically the secondary monitor - smaller, set further back, and to the side of the monitor that's directly in front of the user. But you can't argue with some people...)
The app is using a one-card stack to edit an item of data from a collection held in memory. There are controls on the card to save or revert changes to the item currently being edited; and various controls to move on to edit another item. If the user makes some changes, and then tries to move on to edit another item without saving the changes, the 'answer' command is used to give the user a choice between saving or discarding the changes to the current item, or cancelling the move to the next. In this setup, the user has the editing stack on her larger screen. When she clicks the control to move to the next item, the answer dialog appears on her smaller screen. This I would suggest is a bug in itself. What makes it worse, however, is that it turns out that in this situation it isn't modal. If the user doesn't notice the answer dialog on her left hand screen, she just perceives that the displayed item hasn't changed - so she may then click the same control again - and it actions! At this point the situation (although not the code) is unstable - if she now spotted the answer dialog and attempted to save changes, it would read the wrong data out of the current card. I'm also very uncertain where the code thread is here. My guess about this situation is that the way MC/Rev handles 'modal' mode, at least on the Mac, is not really using the MacOS modal mechanism, but is just taking some funny action like an invisible window behind the 'modal' stack to try to catch clicks until it is closed, and remembering a code point to return to when that stack is closed. I can see why that can be a sensible approach - but in this situation, whatever the mechanism that is being employed to catch events on stacks behind the 'modal' stack is not working correctly. If there is any problem reproducing this effect, please let me know and I'll dig deeper. It is a bug with potentially quite nasty consequences (ie data loss and corruption). PS to Rev folks: is there any reason the answer (and ask) dialogs shouldn't accept the return/enter key to hit return? Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com | Fax : +44 (0)1273-728866 _______________________________________________ improve-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/improve-revolution
