[wx-dev] Re: Events sent programmatically

[Vadim Zeitlin]

On Sat, 02 Sep 2006 14:53:59 +0200 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:

FM> >  Yes, but why should you care? It would be wrong if AddPage() sent "page
FM> > added" event but "page changing event" is useful here, especially for
FM> > DeletePage() as you don't really know which page is going to become current
FM> > after the given page is deleted.
FM> however if we leave them, then we would have an exception in wx API: all 
FM> wxcommandevent-derived events would be always sent by the user except 
FM> for wxBookCtrl::Add/DeletePage... OTOH I agree it's useful to know which 
FM> page becomes select after a DeletePage() call; maybe we could make the 
FM> event-free version of DeletePage() return an "int" which is the index of 
FM> the new selected page ?

 This wouldn't as convenient IMHO. We'd also need to add a (public) method
to generate a page changing even then to allow aan easy transition path for
the existing code. So I'd still just leave these methods as they're.

FM> >  Also, DeletePage/RemovePage() can't be used anyhow as in all other places
FM> > there is a clear difference between the two: the former removes and deletes
FM> > the object whilethe latter just removes it. It would be very confusing if
FM> > it changing Delete to Remove did something completely different here.
FM> I've searched the docs and these are the results:
...
FM> So, I'm still for using RemovePage() and, maybe change instead the first 
FM> listed functions to use the Detach syntax which IMO makes much clear 
FM> that they don't delete stuff just detach it.

 I'm sorry but I still don't like it. When I see DeletePage() and
RemovePage() I still have no idea which one sends the event and which one
doesn't and I also still believe that one of them deletes some pointer
while another does not.

FM> I agree - if Select() has to be discarded, then I vote for ChangeSelection()

 At least this provides some sort of a rule... But I don't think we should
deprecate SetSelection() for now, let's have both for the time being.


FM> > FM> > FM> wxTreeCtrl:
FM> > FM> > FM>     Delete => Remove
FM> > FM> > FM>     DeleteAllItems => RemoveAllItems
...
FM> as above - if we leave them then this is an exception to the rule of 
FM> "wxcommandevents" are always sent by the user.

 OTOH if we remove them we need to provide some way to rewrite the existing
code. I'd rather relax the rule and say that wxCommandEvents are not sent
by wx functions if they can also be generated by user (so that you can
always distinguish between programmatic and user-initiated actions) but can
be sent otherwise.

FM> >  To be consistent with my above suggestion, we could use ChangeValue(). Of
FM> > course, if we used SetPage() for wxNotebook, we'd use SetText() here.
FM> I'd vote for ChangeValue() also for wxTextCtrl, then.

 Ok but we should also keep SetValue() for now, it's too widely used to
deprecate it right now.

 Regards,
VZ