FXList selection

[Hardy, Stephen-2]

Not a show-stopper, but...

When an application calls FXList::selectItem(x, TRUE) i.e. with "notification", if the item is already selected then no notification gets sent.  This is a problem when the list is initially populated.  If the app wants to invoke the normal processing for the selection, using the above API call, then the behavior is different depending on whether the selected item happens to be the one which is initially selected (e.g. item zero when browse-select mode), or not.

I would argue that FXList should send the SEL_SELECTED message whether or not the item is already selected.

Regards,
SJH


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp]

On Wednesday 16 September 2009, Hardy, Stephen wrote:
> Not a show-stopper, but...
>
> When an application calls FXList::selectItem(x, TRUE) i.e. with "notification", if the item is already selected then no notification gets sent.  This is a problem when the list is initially populated.  If the app wants to invoke the normal processing for the selection, using the above API call, then the behavior is different depending on whether the selected item happens to be the one which is initially selected (e.g. item zero when browse-select mode), or not.
>
> I would argue that FXList should send the SEL_SELECTED message whether or not the item is already selected.

Would it not be possible to pass notify=true when populating the FXList? If notify=true
is passed with insertItem() [or appendItem(), prependItem(), fillItems()], then if
LIST_BROWSESELECT is in effect, the current item also gets selected and issues a callback.

As for issuing callbacks even when there is no change: there could be problems when e.g.
some part of the application repeatedly calls selectItem(), e.g. in a SEL_UPDATE handler,
and something actually happens when the SEL_SELECTED callback is intercepted...




                        - Jeroen

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Hardy, Stephen-2]

Jeroen,

> -----Original Message-----
> From: Jeroen van der Zijp [mailto:jeroen@...]
> Sent: Wednesday, September 16, 2009 10:50 AM
> To: foxgui-users@...
> Cc: Hardy, Stephen
> Subject: Re: [Foxgui-users] FXList selection
>
> On Wednesday 16 September 2009, Hardy, Stephen wrote:
> > Not a show-stopper, but...
> >
> > When an application calls FXList::selectItem(x, TRUE) i.e. with
> "notification", if the item is already selected then no notification
> gets sent.  This is a problem when the list is initially populated.  If
> the app wants to invoke the normal processing for the selection, using
> the above API call, then the behavior is different depending on whether
> the selected item happens to be the one which is initially selected
> (e.g. item zero when browse-select mode), or not.
> >
> > I would argue that FXList should send the SEL_SELECTED message
> whether or not the item is already selected.
>
> Would it not be possible to pass notify=true when populating the
> FXList? If notify=true
> is passed with insertItem() [or appendItem(), prependItem(),
> fillItems()], then if
> LIST_BROWSESELECT is in effect, the current item also gets selected and
> issues a callback.

OK, I could do this.  Luckily it's always item zero which is initially selected (it's a traceback for embeded Python scripts, and I put the innermost error source first).  Some apps might not find it this convenient, though.

>
> As for issuing callbacks even when there is no change: there could be
> problems when e.g.
> some part of the application repeatedly calls selectItem(), e.g. in a
> SEL_UPDATE handler,
> and something actually happens when the SEL_SELECTED callback is
> intercepted...

I think most app writers are careful not to call functions (which they are aware might be expensive) if the function would accomplish nothing.  After all, the selectItem() API does not actually document the fact that it doesn't do anything at all if already selected; this piece of information needs to be gleaned by reading the source.  To me, *not* doing the callback in the case under discussion is more of a programming surprise than if selectItem() did more work than one might expect.

Regards,
SJH



>
>
>
>
> - Jeroen

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp]

On Wednesday 16 September 2009, Hardy, Stephen wrote:

> Jeroen,
>
> > -----Original Message-----
> > From: Jeroen van der Zijp [mailto:jeroen@...]
> > Sent: Wednesday, September 16, 2009 10:50 AM
> > To: foxgui-users@...
> > Cc: Hardy, Stephen
> > Subject: Re: [Foxgui-users] FXList selection
> >
> > On Wednesday 16 September 2009, Hardy, Stephen wrote:
> > > Not a show-stopper, but...
> > >
> > > When an application calls FXList::selectItem(x, TRUE) i.e. with
> > "notification", if the item is already selected then no notification
> > gets sent.  This is a problem when the list is initially populated.  If
> > the app wants to invoke the normal processing for the selection, using
> > the above API call, then the behavior is different depending on whether
> > the selected item happens to be the one which is initially selected
> > (e.g. item zero when browse-select mode), or not.
> > >
> > > I would argue that FXList should send the SEL_SELECTED message
> > whether or not the item is already selected.
> >
> > Would it not be possible to pass notify=true when populating the
> > FXList? If notify=true
> > is passed with insertItem() [or appendItem(), prependItem(),
> > fillItems()], then if
> > LIST_BROWSESELECT is in effect, the current item also gets selected and
> > issues a callback.
>
> OK, I could do this.  Luckily it's always item zero which is initially selected (it's a traceback for embeded Python scripts, and I put the innermost error source first).  Some apps might not find it this convenient, though.

Well, I could also find just as many that would find it convenient:- in browse select mode, one is
always selected, and its the first one if its freshly filled up. I don't thing NOT selecting it
would actually make more sense.

> > As for issuing callbacks even when there is no change: there could be
> > problems when e.g.
> > some part of the application repeatedly calls selectItem(), e.g. in a
> > SEL_UPDATE handler,
> > and something actually happens when the SEL_SELECTED callback is
> > intercepted...
>
> I think most app writers are careful not to call functions (which they are aware might be expensive) if the function would accomplish nothing.  After all, the selectItem() API does not actually document the fact that it doesn't do anything at all if already selected; this piece of information needs to be gleaned by reading the source.  To me, *not* doing the callback in the case under discussion is more of a programming surprise than if selectItem() did more work than one might expect.

It must be mentioned that calling selectItem() has the effect of sending both SEL_SELECTED and SEL_DESELECTED
messages, in case of browse select and single select mode.  It would not be logical to only send
the SEL_SELECTED redundantly but not the SEL_DESELECTED messages.

Note also that deselectItem() on a selected item in browse select mode has no effect; you can not
deselect the one selected item in browse select mode.

So, its not clear to me where you'd allow redundant messages, and where you'd suppress them; once
you go down the path of sending redundant messages, you may end up getting a torrent of them.

The current concept is based on the idea that a listener should be able to keep a consistent state
based on only the messages received.  I'm not convinced its a bad idea.

[Possible minor flaw in FXList: an item currently doesn't get deselected before its deleted; I think
maybe it should be].


                - Jeroen

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Hardy, Stephen-2]

Jeroen,

> -----Original Message-----
> From: Jeroen van der Zijp [mailto:jeroen@...]
> Sent: Wednesday, September 16, 2009 11:45 AM
> To: foxgui-users@...
> Cc: Hardy, Stephen
> Subject: Re: [Foxgui-users] FXList selection
>
> On Wednesday 16 September 2009, Hardy, Stephen wrote:
> > Jeroen,
> >
> > > -----Original Message-----
> > > From: Jeroen van der Zijp [mailto:jeroen@...]
> > > Sent: Wednesday, September 16, 2009 10:50 AM
> > > To: foxgui-users@...
> > > Cc: Hardy, Stephen
> > > Subject: Re: [Foxgui-users] FXList selection
> > >
> > > On Wednesday 16 September 2009, Hardy, Stephen wrote:
> > > > Not a show-stopper, but...
> > > >
> > > > When an application calls FXList::selectItem(x, TRUE) i.e. with
> > > "notification", if the item is already selected then no
> notification
> > > gets sent.  This is a problem when the list is initially populated.
> If
> > > the app wants to invoke the normal processing for the selection,
> using
> > > the above API call, then the behavior is different depending on
> whether
> > > the selected item happens to be the one which is initially selected
> > > (e.g. item zero when browse-select mode), or not.
> > > >
> > > > I would argue that FXList should send the SEL_SELECTED message
> > > whether or not the item is already selected.
> > >
> > > Would it not be possible to pass notify=true when populating the
> > > FXList? If notify=true
> > > is passed with insertItem() [or appendItem(), prependItem(),
> > > fillItems()], then if
> > > LIST_BROWSESELECT is in effect, the current item also gets selected
> and
> > > issues a callback.
> >
> > OK, I could do this.  Luckily it's always item zero which is
> initially selected (it's a traceback for embeded Python scripts, and I
> put the innermost error source first).  Some apps might not find it
> this convenient, though.
>
> Well, I could also find just as many that would find it convenient:- in
> browse select mode, one is
> always selected, and its the first one if its freshly filled up. I
> don't thing NOT selecting it
> would actually make more sense.

Sorry, I didn't express myself clearly: what I meant was that some applications who didn't always want the default (zeroth) item selected, might have to populate the entire list before being able to determine the item to start with (and select).  Their program would have to do different things depending on whether the desired selection turned out to be zero or not.

>
> > > As for issuing callbacks even when there is no change: there could
> be
> > > problems when e.g.
> > > some part of the application repeatedly calls selectItem(), e.g. in
> a
> > > SEL_UPDATE handler,
> > > and something actually happens when the SEL_SELECTED callback is
> > > intercepted...
> >
> > I think most app writers are careful not to call functions (which
> they are aware might be expensive) if the function would accomplish
> nothing.  After all, the selectItem() API does not actually document
> the fact that it doesn't do anything at all if already selected; this
> piece of information needs to be gleaned by reading the source.  To me,
> *not* doing the callback in the case under discussion is more of a
> programming surprise than if selectItem() did more work than one might
> expect.
>
> It must be mentioned that calling selectItem() has the effect of
> sending both SEL_SELECTED and SEL_DESELECTED
> messages, in case of browse select and single select mode.  It would
> not be logical to only send
> the SEL_SELECTED redundantly but not the SEL_DESELECTED messages.

With 20-20 hindsight, it may have been better to have something like a SEL_SELECTION_CHANGED message, which provided the "from" and "to" item numbers in the message.  Either could be '-1' to indicate a null selection.  This makes sense, because the select and de-select are so closely coupled in practice that most apps would want to deal with this in a single callback.  It would also make sense to have 'from==to' which would indicate that the app is re-selecting the same item (programatically, not as a result of the user interaction with the gui).

Anyway, all this is not to suggest you should make any changes, but it does indicate that some of the API functions need more than the one-liner docstring, at least if the intention is to avoid surprising neophyte programmers like me.  I'd be the first to volunteer to add doc if only there was an easy way to get it incorporated in the distro.

Regards,
SJH

>
> Note also that deselectItem() on a selected item in browse select mode
> has no effect; you can not
> deselect the one selected item in browse select mode.
>
> So, its not clear to me where you'd allow redundant messages, and where
> you'd suppress them; once
> you go down the path of sending redundant messages, you may end up
> getting a torrent of them.
>
> The current concept is based on the idea that a listener should be able
> to keep a consistent state
> based on only the messages received.  I'm not convinced its a bad idea.
>
> [Possible minor flaw in FXList: an item currently doesn't get
> deselected before its deleted; I think
> maybe it should be].
>
>
> - Jeroen

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp]

On Wednesday 16 September 2009, Hardy, Stephen wrote:
> Jeroen,


> Sorry, I didn't express myself clearly: what I meant was that some applications who didn't always want the default (zeroth) item selected, might have to populate the entire list before being able to determine the item to start with (and select).  Their program would have to do different things depending on whether the desired selection turned out to be zero or not.

I see.

Anyway, the widget merely tries to maintain the invariant (in the case of browse-select,
that means making sure exactly one item is selected at all times, unless the widget is
empty).

> > > > As for issuing callbacks even when there is no change: there could
> > be
> > > > problems when e.g.
> > > > some part of the application repeatedly calls selectItem(), e.g. in
> > a
> > > > SEL_UPDATE handler,
> > > > and something actually happens when the SEL_SELECTED callback is
> > > > intercepted...
> > >
> > > I think most app writers are careful not to call functions (which
> > they are aware might be expensive) if the function would accomplish
> > nothing.  After all, the selectItem() API does not actually document
> > the fact that it doesn't do anything at all if already selected; this
> > piece of information needs to be gleaned by reading the source.  To me,
> > *not* doing the callback in the case under discussion is more of a
> > programming surprise than if selectItem() did more work than one might
> > expect.
> >
> > It must be mentioned that calling selectItem() has the effect of
> > sending both SEL_SELECTED and SEL_DESELECTED
> > messages, in case of browse select and single select mode.  It would
> > not be logical to only send
> > the SEL_SELECTED redundantly but not the SEL_DESELECTED messages.
>
> With 20-20 hindsight, it may have been better to have something like a SEL_SELECTION_CHANGED message, which provided the "from" and "to" item numbers in the message.  Either could be '-1' to indicate a null selection.  This makes sense, because the select and de-select are so closely coupled in practice that most apps would want to deal with this in a single callback.  It would also make sense to have 'from==to' which would indicate that the app is re-selecting the same item (programatically, not as a result of the user interaction with the gui).

Please note that SEL_SELECTED means an item becomes selected (highlighted) or not.  SEL_CHANGED is a change in the
current item.

> Anyway, all this is not to suggest you should make any changes, but it does indicate that some of the API functions need more than the one-liner docstring, at least if the intention is to avoid surprising neophyte programmers like me.  I'd be the first to volunteer to add doc if only there was an easy way to get it incorporated in the distro.

No argument; some of the finer points may need to have more info in the doc-strings.


                - Jeroen

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users