lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] switch census view to use wxDataViewCtrl


From: Vadim Zeitlin
Subject: Re: [lmi] switch census view to use wxDataViewCtrl
Date: Fri, 12 Aug 2011 16:00:27 +0200

On Thu, 11 Aug 2011 12:54:17 +0000 Greg Chicares <address@hidden> wrote:

GC> I have two questions:
GC> 
GC> (1) To ascertain whether the selection is nonempty, I did:
GC> 
GC>     wxDataViewItemArray selection;
GC>     unsigned int n_sel_items = list_window_->GetSelections(selection);
GC>     e.Enable(0 < n_sel_items);
GC> 
GC> Is there a better way? It seems wasteful to populate a wxDataViewItemArray
GC> that isn't used.

 Yes, indeed, and there are additional inefficiencies in both the MSW and
GTK versions too (MSW one passes the array of selections by value and GTK
one calls extra GTK functions for each selected item). I already noticed
the absence of HasSelections() or GetSelectedItemsCount() in wxDVC and
thought about adding it but didn't find time to do this before. If it can
be useful to LMI it would be a sufficient motivation for me to finally do
it...

GC> (2) Concerning this code that predates these latest changes...
GC> 
GC> void CensusView::UponUpdateSingleItemActions(wxUpdateUIEvent& e)
GC> {
GC>     bool const is_single_sel = list_window_->GetSelection().IsOk();
GC>     e.Enable(is_single_sel);
GC> }
GC> 
GC> ...I observe that enablement occurs iff exactly one cell is selected
GC> (which is good), but I don't understand why. The documentation seems to
GC> say that this code would detect whether one or more cells is selected:
GC> 
GC> 
http://docs.wxwidgets.org/trunk/classwx_data_view_ctrl.html#71cd6bc33658d944c65062f789a82f19
GC> | virtual wxDataViewItem wxDataViewCtrl::GetSelection() const [virtual]
GC> | Returns first selected item or an invalid item if none is selected.
GC> 
GC> If two cells are selected, shouldn't that return the first one, which
GC> should pass the IsOK() test?

 The problem is that the real code behaviour is not the documented one in
the generic version (used by wxMSW), even though it does behave like this
in wxGTK. We need to resolve this one way or the other and I actually think
that the documented behaviour is pretty useless and that we should change
wxGTK to behave in the same way the generic version does (and update the
documentation). I've posted a suggestion to do this on wx-dev:

        http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/132014

and will change it like this if there are no (or not too many) objections.
I'll post here again when it's done or if we decide not to do it -- in
which case the code above would need to be changed as then I'd change the
generic version to behave as documented.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]