Events sent programmatically

[Francesco Montorsi]

Vadim Zeitlin ha scritto:
> 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.
however if we leave them, then we would have an exception in wx API: all 
wxcommandevent-derived events would be always sent by the user except 
for wxBookCtrl::Add/DeletePage... OTOH I agree it's useful to know which 
page becomes select after a DeletePage() call; maybe we could make the 
event-free version of DeletePage() return an "int" which is the index of 
the new selected page ?


> 
>  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.
I've searched the docs and these are the results:

- wxMenu::Remove() and wxMenuBar::Remove(), wxToolBar::RemoveTool(), 
wxArtProvider::RemoveProvider() as you say remove stuff but don't delete it

- wxWindow::RemoveChild is unclear; however it says user shouldn't need 
to use it at all

- wxSizer::Remove() deletes spacers/sizers not windows but it's 
deprecated for windows exactly for that reason.

- wxMemoryFSHandler::RemoveFile(), wxImageList::Remove*(), 
wx[Obj]Array::Remove() instead detach & remove stuff


So, I'm still for using RemovePage() and, maybe change instead the first 
listed functions to use the Detach syntax which IMO makes much clear 
that they don't delete stuff just detach it.


> 
> 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.
I agree - if Select() has to be discarded, then I vote for ChangeSelection()


> 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.
as above - if we leave them then this is an exception to the rule of 
"wxcommandevents" are always sent by the user.


> 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.
I'd vote for ChangeValue() also for wxTextCtrl, then.

Francesco