Re: [Pythoncard-users] clearing up tab order in resourceEditor

[Kevin A. <al...@se...>]

On Apr 4, 2005, at 12:50 PM, bra...@om... wrote:

>
> I'm still in favor of a separate data structure for tab order. It's=20
> important to be able to take some
> focusable components out of the tab order, just as you can in=20
> 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=20=

> component widget names,
> let's call it tabSeq.
>
> Rules for tabSeq:
>
> =A0 =A0 =A0 =A0 - If a widget isn't in tabSeq, it's not included in =
the tab=20
> order.
> =A0 =A0 =A0 =A0 - If a widget is deleted in Resource Editor, it must =
be=20
> deleted from tabSeq
> =A0 =A0 =A0 =A0 - If a widget is renamed in Resource Editor, it must =
be=20
> renamed in tabSeq
> =A0 =A0 =A0 =A0 - By default, at on_initialize, the focus would start =
at the=20
> first widgets in tabSeq
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (this would reduce need setFocus =
statements in=20
> on_initialize)
> =A0 =A0 =A0 =A0 - Tab order in final background UI is determined by =
tabSeq
>
> The Resource Editor UI to handle this would be a modal dialog box=20
> listing focusable widgets
> of the current background, with checkboxes alongside each item. Any=20
> widget with a
> checkbox is included in the tabSeq. Widgets could be reordered by=20
> using an
> appropriate list reordering UI.
>
> Yes, this is yet another dialog box for Resource Editor, but I don't=20=

> think it would
> need to be implemented in Resource Editor right away. I for one would=20=

> be happy
> to set the values of tabSeq from a script, but hope for a future time=20=

> in which Resource
> Editor handles keeping the resource file in sync with tabSeq, and=20
> providing
> a dialog UI for managing tabSeq.
>

There are a number of issues that this raises, but the short answer is=20=

that I reject this idea. The main reason why is that a subset of the=20
focusable widgets seems like a border case at best and adds=20
complications to the resource file format, framework, and=20
resourceEditor as well as an additional thing that a user needs to=20
learn. That is contrary to the PythonCard 1.0 goals on pretty much=20
every level. At some point, people just have to use wxPython,=20
PythonCard will never duplicate all the functionality of wxPython, etc.

For the cases where you want something like this it should be=20
relatively easy for you to implement yourself either as a subclass of=20
Background or just user code stuck into your main application.

ka