From: <bra...@om...> - 2005-04-04 19:51:52
|
I'm still in favor of a separate data structure for tab order. It's important to be able to take some focusable components out of the tab order, just as you can in FileMaker. This is normally done with rarely used-fields which still need to be focusable by mouseClick. Here's a proposal for handling tab sequence: Every background rsrc gets a new property, which is a simple list of component widget names, let's call it tabSeq. Rules for tabSeq: - If a widget isn't in tabSeq, it's not included in the tab order. - If a widget is deleted in Resource Editor, it must be deleted from tabSeq - If a widget is renamed in Resource Editor, it must be renamed in tabSeq - By default, at on_initialize, the focus would start at the first widgets in tabSeq (this would reduce need setFocus statements in on_initialize) - Tab order in final background UI is determined by tabSeq The Resource Editor UI to handle this would be a modal dialog box listing focusable widgets of the current background, with checkboxes alongside each item. Any widget with a checkbox is included in the tabSeq. Widgets could be reordered by using an appropriate list reordering UI. Yes, this is yet another dialog box for Resource Editor, but I don't think it would need to be implemented in Resource Editor right away. I for one would be happy to set the values of tabSeq from a script, but hope for a future time in which Resource Editor handles keeping the resource file in sync with tabSeq, and providing a dialog UI for managing tabSeq. |