[wx-dev] Re: Events sent programmatically

[Vadim Zeitlin]

On Sat, 02 Sep 2006 13:28:08 +0200 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:

FM> Vadim Zeitlin ha scritto:
FM> > On Thu, 31 Aug 2006 19:29:03 +0200 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:
FM> > 
FM> > FM> So, in conclusion, can I make a patch which adds the following 
FM> > FM> event-free functions:
FM> > FM> 
FM> > FM> wxBookCtrl-derived:
FM> > FM>     AddPage => AppendPage
FM> > FM>     DeletePage => RemovePage
FM> > 
FM> >  I don't think we need the variants of these functions which don't send
FM> > events because there is no ambiguity here: the user can never directly add
FM> > nor remove notebook pages, so this is always done programmatically.
FM> not sure to understand what you mean: AddPage sends "page changing 
FM> events" (like DeletePage) thus in your OnPageChanged() event handler you 
FM> still cannot know if the event was generated programmatically or not...

 Yes, but why should you care? It would be wrong if AddPage() sent "page
added" event but "page changing event" is useful here, especially for
DeletePage() as you don't really know which page is going to become current
after the given page is deleted.

 Also, DeletePage/RemovePage() can't be used anyhow as in all other places
there is a clear difference between the two: the former removes and deletes
the object whilethe latter just removes it. It would be very confusing if
it changing Delete to Remove did something completely different here.

FM> > FM>     SetSelection => Select
FM> > 
FM> >  The problem here is that we already have both SetSelection() and Select()
FM> > for various multi-item controls (wxListBox, wxChoice, ...) and there the
FM> > difference between them is that the former only works for single-selection
FM> > controls and the latter also works for multi-selection ones. Here the
FM> > difference is something completely unrelated.
FM> I know but since wxbookctrl-based controls cannot have multiple 
FM> selections and don't derive from wxControlWithItems, I still would use 
FM> Select() as name.

 I didn't mean to say that you can't use Select() here because of
compilation ambiguity. I wanted to say that the users would find it very
confusing and I still believe so.

FM> Otherwise which name could we use (which makes SetSelection deprecable
FM> in future) ?

 I see 2 orthogonal suggestions: ChangeSelection() or SetPage(). I.e.
either we change the verb or the noun. In any case, we need a clear rule,
e.g. "Set sends events, Change does not" or "Set generic property sends
events, but set specific property does not". Unfortunately, neither of
these really generalizes well to other controls but we have no public
Change() methods AFAIK so it seems like adding ChangeSelection() would be
the least confusing thing to do.

FM> > FM> wxTreeCtrl:
FM> > FM>     Delete => Remove
FM> > FM>     DeleteAllItems => RemoveAllItems
FM> > 
FM> >  Again, I don't think we need those: the corresponding events are only
FM> > generated by the program, never by user.
FM> this time I agree - it's obvious that the events were programmatically 
FM> generated. In this case however, if we want to make API coherent we 
FM> should remove the EVT_TREE_DELETE_ITEM event completely, shouldn't we ?

 On the one hand, I'm tempted to agree. OTOH it really does no harm and
it's going to be difficult to explain to people having code using it why
did we decide to break it all of a sudden.

FM> >  OTOH I think the single most annoying method from the event [not] sending
FM> > perspective is wxTextCtrl::SetValue(), it's really the only one for which
FM> > I'd like to have a "silent" or "event-less" version.
FM> right!
FM> I missed it from my list of guilty functions. We could make a 
FM> wxTextCtrl::SetText event-free function

 To be consistent with my above suggestion, we could use ChangeValue(). Of
course, if we used SetPage() for wxNotebook, we'd use SetText() here.

 Regards,
VZ