wxGrid or wxDataViewCtrl?
Fulvio Senore
so on...), currently written in VB5.
Since it will take a rather long time I have decided to use version 2.9.
At the moment I am evaluating the basic design choices and I have a
question for more experienced people.
I will use a grid for two basic purposes:
1) read-only list of customers, invoices and similar. This is to let the
user choose an item from the list and edit it.
2) read write grid used to enter, for example, the rows of an invoice.
Having the ability to place a drop-down combo in the cells of a column
would be useful.
I have made some experiment with wxDataViewCtrl, and I have also looked
at the wxGrid demo. It looks like the two controls are designed for
rather similar tasks, so I don't know which one would be better for my
purposes.
Which are the differences between wxDataViewCtrl and wxGrid, and what
control would you recommend for my two basic needs (maybe even different
ones for purpose 1 and 2)?
Thanks in advance
Fulvio Senore
Vadim Zeitlin
FS> Which are the differences between wxDataViewCtrl and wxGrid,
The basic difference is that wxDataViewCtrl is a native control under GTK
and OS X and so is (a) limited in what it can do (e.g. some wxGrid features
such as overflowing cells just can't be implemented in it) but (b) looks
and feels more natively and, potentially, is also less buggy.
Another important difference is that wxDataViewCtrl supports trees and not
only lists while wxGrid does not (and never will).
FS> and what control would you recommend for my two basic needs (maybe even
FS> different ones for purpose 1 and 2)?
It's difficult to say. I'd try wxDataViewCtrl if you don't need any
esoteric features which only wxGrid has (or might be modified to have in
the future) as it should look better.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Fulvio Senore
Vadim Zeitlin ha scritto:
> On Tue, 22 Dec 2009 16:42:39 +0100 Fulvio Senore <mai...@fsoft.it> wrote:
>
> FS> Which are the differences between wxDataViewCtrl and wxGrid,
>
> The basic difference is that wxDataViewCtrl is a native control under GTK
> and OS X and so is (a) limited in what it can do (e.g. some wxGrid features
> such as overflowing cells just can't be implemented in it) but (b) looks
> and feels more natively and, potentially, is also less buggy.
>
> Another important difference is that wxDataViewCtrl supports trees and not
> only lists while wxGrid does not (and never will).
>
> FS> and what control would you recommend for my two basic needs (maybe even
> FS> different ones for purpose 1 and 2)?
>
> It's difficult to say. I'd try wxDataViewCtrl if you don't need any
> esoteric features which only wxGrid has (or might be modified to have in
> the future) as it should look better.
>
Thank you for the explanation, I will try wxDataViewCtrl.
So it comes the next question.
Since the grid will show data from a database the result set could be
very large. It does not make sense to load all the result set in the
grid before showing it: the database could return thousands of rows but
the user would probably scroll down only a few times before realizing
that he must enter more restrictive search criteria.
For this reason the best solution would be using a virtual mode: the
grid shows only the needed rows and asks for the others only when (and
if) the user scrolls down.
The 2.9 documentation says that wxDataViewCtrl cannot work in virtual
mode under OS X, for a Carbon limitation. Does this mean that under OS X
the control will always load all the rows before showing them? Will the
Cocoa port also have this limitation or not?
I do not know anything about Carbon, but I wonder how can it forbid
having the control working in virtual mode.
As you can imagine having to load all the data rows before showing them
is a waste of time, bandwidth, server resources and common sense.
Thanks in advance.
Fulvio
Kenneth Porter
<mai...@fsoft.it> wrote:
> Since the grid will show data from a database the result set could be
> very large. It does not make sense to load all the result set in the
> grid before showing it: the database could return thousands of rows but
> the user would probably scroll down only a few times before realizing
> that he must enter more restrictive search criteria.
It might be instructive to look at how phpMySQL handles this issue. IIRC,
it uses a LIMIT clause to restrict the displayed records and there are page
controls that let you move forward and backward in the results. You can set
the number of results per page at any time.
I suggest doing lookups in a service thread so that you can keep the UI
responsive even with a slow network/server and large queries.
Wanadoo Hartwig
Yes, you need to load all the rows first. It does not matter whether
you are using Carbon or Cocoa. The native implementation does not
support "virtual data".
Hartwig
>
>
>
>
>
>
> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before
> posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users
Fulvio Senore
Kenneth Porter ha scritto:
Thank you for the suggestion, but I'd rather use a grid with scrolling
capabilities. I think that it should be more natural for end users who
simply expect a single (possibly long) list of rows.
My idea is to start a query and read a few rows to fill the grid,
without closing the query. If the user scrolls down read some more rows
to show them in the grid, and so on. I plan to keep the read lines in
memory in case the user scrolls up.
Query response will be fast in my typical usage: the database can start
sending rows almost immediately.
Fulvio
Fulvio Senore
>
>> The 2.9 documentation says that wxDataViewCtrl cannot work in virtual
>> mode under OS X, for a Carbon limitation. Does this mean that under
>> OS X
>> the control will always load all the rows before showing them? Will
>> the
>> Cocoa port also have this limitation or not?
>> I do not know anything about Carbon, but I wonder how can it forbid
>> having the control working in virtual mode.
>>
>> As you can imagine having to load all the data rows before showing
>> them
>> is a waste of time, bandwidth, server resources and common sense.
>>
>> Thanks in advance.
>>
>> Fulvio
>>
>>
>
> Yes, you need to load all the rows first. It does not matter whether
> you are using Carbon or Cocoa. The native implementation does not
> support "virtual data".
>
> Hartwig
>
Thank you for that info. This means that I will have to look for some
workaround, otherwise I will have to use wxGrid.
Do you know if the same limitation holds for wxListCtrl in report mode,
under OS X? The documentation says that it has a virtual mode and it
does not write about OS X limitations.
Fulvio
Vadim Zeitlin
WH> Yes, you need to load all the rows first. It does not matter whether
WH> you are using Carbon or Cocoa. The native implementation does not
WH> support "virtual data".
I've never really understood why couldn't this work in Carbon version (you
did explain it a couple of times but I just couldn't grok it) but I'm
certain that Cocoa does support virtual lists just fine natively and if the
current implementation in wx doesn't support it, it's clearly a bug which
must be fixed.
Stefan Csomor
> I've never really understood why couldn't this work in Carbon version (you
> did explain it a couple of times but I just couldn't grok it) but I'm
> certain that Cocoa does support virtual lists just fine natively and if the
> current implementation in wx doesn't support it, it's clearly a bug which
> must be fixed.
Cocoa has a nice and simple NSTableDataSource protocol, which in minimum
only need numberOfRowsInTableView: and
tableView:objectValueForTableColumn:row implemented which fit the virtual
idea nicely, but looking at dataview I think there's currently always a
NSOutlineView used (hierarchical data), which needs a
NSOutlineViewDataSource which obviously needs more 'real' data to work
correctly
just my 0.02$
Stefan
Wanadoo Hartwig
Am 22.12.2009 um 23:12 schrieb Vadim Zeitlin:
> On Tue, 22 Dec 2009 21:01:17 +0100 Wanadoo Hartwig <hartwig....@wanadoo.nl
> > wrote:
>
> WH> Yes, you need to load all the rows first. It does not matter
> whether
> WH> you are using Carbon or Cocoa. The native implementation does not
> WH> support "virtual data".
>
> I've never really understood why couldn't this work in Carbon
> version (you
> did explain it a couple of times but I just couldn't grok it) but I'm
> certain that Cocoa does support virtual lists just fine natively and
> if the
> current implementation in wx doesn't support it, it's clearly a bug
> which
> must be fixed.
>
From where do you have the knowledge that Cocoa supports it?
Actually, it is better with respect to data management than Carbon, it
should support it anyway but ...
The native data view control (it does not matter whether it is Carbon
or Cocoa) does the ordering and scrollbar adjustments by itself.
Therefore, it needs at least the information how many items are in the
data view control. And both native controls do that by adding items to
the control (not by purely setting the number of the items in the
control).
The difference between the Carbon and the Cocoa version is how the
controls get the data.
Carbon:
Carbon basically asks the data for all the "column" data for the
sortable column first (there is always some kind of sortable column).
Therefore, at leat these information have to be supported always.
After Carbon did the ordering it asks for the complete records (line
data) for all visible items. If the control is scrolled the remaining
data is fetched.
This fetched data may become invalid when the user scrolls the data
out of the visible range.
So, this is the process:
- native control asks column data of the sortable column (really the
data and not an ID and not the number of data sets)
- native control does the sorting (via a callback function)
- native control determines which records are visible
- asks for all column data for the visible records
- in case of user interaction the not (yet) loaded data may be asked
by the native control
- already provided data may become invalid and may have to be reloaded
after user interaction
Cocoa:
Cocoa has methods to ask for the number of children for each parent
(starting from the root). After having received these information it
is asking to supply the data.
So, theoretically it implements a virtual control (it is asking for
the number of items first and can therefore decide which data it loads
or not). The only problem is that there is nowhere defined when and if
the native control is asking for the data. This is the crucial part:
you do not have a guarantee! Chances are good though...
Therefore, I implemented the Cocoa part as follows:
- if the native control is asking for the number of children of each
parent these data are provided; in parallel the IDs of all items
(children and parents) are stored internally (for quicker retrieval
and to implement the sorting function efficiently). And storing the
IDs only for huge data sets is still using a fairly small amount of
memory. This is done via the wxDataViewModel::GetChildren method. This
returns the children's IDs.
- if the native control asks for the data the data has to be loaded
(I do not know when this happens; this is not documented).
- if there are columns that have to be sorted the sorting is done on
the internally stored IDs only! An internal sorting function calls for
each ID pair of a certain children level the wxDataViewModel::Compare
method. It is up to you to do with it what you want. If you have
already pre-sorted IDs you may always return 0 in
wxDataViewModel::Compare method and the IDs should not be resorted.
This is the process for Cocoa:
- native control ask for the number of children for the root (and
eventually recursively for the number of children of the root's
children)
- IDs of the supplied children's IDs are stored internally (IDs are
sorted with respect to the sortable columns by using
wxDataViewModel::Compare)
- data is loaded
- resorting of the data triggered by the user forces a complete re-
load of the data (beginning with the first step again); your
application is informed by an wxEvent about this so that you can
change the supply of IDs using wxDataViewModel::GetChildren
Summary:
While you do not have a chance with Carbon to have a virtual dataview
control the chances are good that it works with Cocoa. But there is no
guarantee from Apple.
So, my previous statement ("Cocoa does not support a dataview using
virtual data") was probably too strong. There is just no guarantee
that it works (with the native implementation of OS X 10.5 it does; I
did not check with 10.6).
Attention: by implementing a dataview with virtual data as described
here you can use only one model with one control! Normally, the same
model can be used for several controls.
Hartwig
Wanadoo Hartwig
Actually it does not need much more data but Apple just does not give
you a hint when the real data has to be provided!
See my previous reply.
Hartwig
> just my 0.02$
>
> Stefan
Vadim Zeitlin
WH> From where do you have the knowledge that Cocoa supports it?
From reading Apple documentation... See the excerpts below.
WH> The native data view control (it does not matter whether it is Carbon
WH> or Cocoa) does the ordering and scrollbar adjustments by itself.
WH> Therefore, it needs at least the information how many items are in the
WH> data view control.
Obviously, yes. Of course, a model already provides this information.
WH> And both native controls do that by adding items to the control (not
WH> by purely setting the number of the items in the control).
I don't think this is correct for Cocoa.
WH> Cocoa:
WH>
WH> Cocoa has methods to ask for the number of children for each parent
WH> (starting from the root). After having received these information it
WH> is asking to supply the data.
This is exactly how I think it behaves too and is just what we need to
implement a true virtual control. And, just to be completely sure, here is
an excerpt from
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/TableView/Tasks/UsingTableDataSource.html#//apple_ref/doc/uid/20000117
Unlike most controls, an NSTableView object does not store or cache
the data it displays. Instead, it gets all of its data from an
object called a data source that you provide. Your data source
object can store records in any way you choose, as long as it is
able to identify those records by integer index. It must also
implement methods to provide the following information:
* How many records are in the data source (numberOfRowsInTableView
method)
* What is the value of a specific record
(tableView:objectValueForTableColumn:row: method)
If your table supports the editing of records, you must also
provide a tableView:setObjectValue:forTableColumn:row: method for
changing the value of an attribute.
Of course, we're using NSOutlineView and not NSTableView but see also
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/OutlineView/Articles/UsingOutlineDataSource.html#//apple_ref/doc/uid/20000725
Your data source object can store records in any way you choose,
but it must be able to identify them by their position in the
hierarchy through the NSOutlineViewDataSource protocol. The data
source must minimally implement the data access methods
(outlineView:child:ofItem:, outlineView:isItemExpandable:,
outlineView:numberOfChildrenOfItem:, and
outlineView:objectValueForTableColumn:byItem:). To specify the root
item in any of these methods, nil is sent as the method's item
argument. If you want to allow the user to edit items, you must
also implement a method for changing the value of an attribute
(outlineView:setObject:forTableColumn:byItem:).
WH> So, theoretically it implements a virtual control (it is asking for
WH> the number of items first and can therefore decide which data it loads
WH> or not). The only problem is that there is nowhere defined when and if
WH> the native control is asking for the data. This is the crucial part:
WH> you do not have a guarantee! Chances are good though...
Sorry, this is where I'm stopping understanding you again. What exactly
does this mean? What guarantee do we need? Why does it matter when is it
asking for it? It obviously does it when it needs to display it but why
should we care about this at all?
I'm afraid -- sorry if I'm wrong but this is the only explanation I see
for the mismatch in our communication -- that there is some
misunderstanding about what does "virtual control" mean. Just to be clear,
"virtual" means that *all* data access, which obviously includes sorting,
searching &c, is done via the model only and that the data is never stored
anywhere else. It's only accessed on demand using the model methods. It's
really very, very simple, actually much simpler than implementing
non-virtual control and I have an impression that you're trying to do
something vastly more complicated which tries to combine virtual access to
the data with sorting implemented independently of the model. This,
obviously, can't work and would explain why did you fail to implement it.
Of course, the good news is that we don't need it in the first place.
WH> Therefore, I implemented the Cocoa part as follows:
WH>
WH> - if the native control is asking for the number of children of each
WH> parent these data are provided; in parallel the IDs of all items
WH> (children and parents) are stored internally (for quicker retrieval
WH> and to implement the sorting function efficiently).
This is completely wrong, sorry. You must not store anything at all in the
virtual control case and you most definitely must not do any sorting in the
control itself.
WH> And storing the IDs only for huge data sets is still using a fairly
WH> small amount of memory.
Fairly small part of a potentially infinite amount is still more than you
can afford. It would be a folly to try to store the ids of all the items in
a database table with a couple of hundreds of millions of items, forget
about memory -- think just about the time needed to retrieve them all (and
now think that the database of such size is usually remote, so you need to
transfer them all via network first). Once again, you *never* must store
anything inside the control itself.
WH> This is done via the wxDataViewModel::GetChildren method. This
WH> returns the children's IDs.
WH> - if the native control asks for the data the data has to be loaded
WH> (I do not know when this happens; this is not documented).
This has absolutely no importance. Whenever the native control needs data,
it asks the model. The model gets the data in whatever way it does it, you
shouldn't care about this.
WH> - if there are columns that have to be sorted the sorting is done on
WH> the internally stored IDs only!
This has to change. The model must be notified about the change of the
sort order, and it will simply provide data to you according to the new
order (e.g. it will rerun the query against the database with the new
"ORDER BY" clause).
WH> This is the process for Cocoa:
WH>
WH> - native control ask for the number of children for the root (and
WH> eventually recursively for the number of children of the root's
WH> children)
Good.
WH> - IDs of the supplied children's IDs are stored internally (IDs are
WH> sorted with respect to the sortable columns by using
WH> wxDataViewModel::Compare)
Bad.
WH> - data is loaded
Irrelevant, it may be loaded or not, it doesn't change anything either
way.
WH> - resorting of the data triggered by the user forces a complete re-
WH> load of the data
Extremely bad.
WH> Summary:
WH>
WH> While you do not have a chance with Carbon to have a virtual dataview
WH> control the chances are good that it works with Cocoa. But there is no
WH> guarantee from Apple.
Sorry, I still don't understand at all the problem you have. What
guarantee do you need and why? NSOutlineView clearly supports exactly what
we need to implement a fully virtual control. The problem is in wxDVC
handling of sorting which, if I understood you correctly, is simply
inappropriate for virtual controls.
WH> So, my previous statement ("Cocoa does not support a dataview using
WH> virtual data") was probably too strong. There is just no guarantee
WH> that it works (with the native implementation of OS X 10.5 it does; I
WH> did not check with 10.6).
I see no reason to doubt that it does work under 10.6, why do you think it
shouldn't work there?
WH> Attention: by implementing a dataview with virtual data as described
WH> here you can use only one model with one control! Normally, the same
WH> model can be used for several controls.
When you do sorting inside the model (as you must do with virtual
controls) it indeed becomes impossible to share it among different views.
This is hardly as important as allowing to have virtual controls in the
first place.
Stefan Csomor
>> Cocoa has a nice and simple NSTableDataSource protocol, which in
>> minimum
>> only need numberOfRowsInTableView: and
>> tableView:objectValueForTableColumn:row implemented which fit the
>> virtual
>> idea nicely, but looking at dataview I think there's currently
>> always a
>> NSOutlineView used (hierarchical data), which needs a
>> NSOutlineViewDataSource which obviously needs more 'real' data to work
>> correctly
>>
>
> Actually it does not need much more data but Apple just does not give
> you a hint when the real data has to be provided!
NSOutlineViewDataSource works on items (type id) while NSTableDataSource
works on row number, so outline view is conceptually very close to the
DataBrowser, when you indicate the number of childen,
outlineView:child:ofItem is called for each of them, regardless whether
they're visible or not
for the correct layout NSTableView only needs the rowcount, and then asks
only for data for the visible lines (addressed via rownumber)
I've just made sure these facts are still correct by comparing the outline
view sample with a modified version that uses a tableview
Best,
STefan
Wanadoo Hartwig
Yes, that it is how it is described but actually it seems to be that
NSOutlineViewData is buffering internally (example: jump from the
beginning to the end and back; the data is not (always) reloaded). How
much is buffered, when ... I do not know.
This is basically the reason I said that we cannot implement a pure
virtual control.
Besides storing the model's IDs the current Cocoa implementation is in
this sense "virtual".
> WH> Therefore, I implemented the Cocoa part as follows:
> WH>
> WH> - if the native control is asking for the number of children
> of each
> WH> parent these data are provided; in parallel the IDs of all items
> WH> (children and parents) are stored internally (for quicker
> retrieval
> WH> and to implement the sorting function efficiently).
>
> This is completely wrong, sorry. You must not store anything at all
> in the
> virtual control case and you most definitely must not do any sorting
> in the
> control itself.
>
I have never mentioned that the sorting (function) itself is
implemented in the control. The IDs are stored and the sorting is done
via wxDataViewModel::Compare method.
> WH> And storing the IDs only for huge data sets is still using a
> fairly
> WH> small amount of memory.
>
> Fairly small part of a potentially infinite amount is still more
> than you
> can afford. It would be a folly to try to store the ids of all the
> items in
> a database table with a couple of hundreds of millions of items,
> forget
> about memory -- think just about the time needed to retrieve them
> all (and
> now think that the database of such size is usually remote, so you
> need to
> transfer them all via network first). Once again, you *never* must
> store
> anything inside the control itself.
>
With the current implementation of wxDataViewModel and
wxDataViewControl there is no alternative. Especially not when you
allow a "one model - several controls" approach. And this is something
I really do not want to miss.
> WH> This is done via the wxDataViewModel::GetChildren method. This
> WH> returns the children's IDs.
> WH> - if the native control asks for the data the data has to be
> loaded
> WH> (I do not know when this happens; this is not documented).
>
> This has absolutely no importance. Whenever the native control needs
> data,
> it asks the model. The model gets the data in whatever way it does
> it, you
> shouldn't care about this.
>
I do not care. But I cannot guarantee that the native control is not
loading all the data although it is not necessary.
> WH> - if there are columns that have to be sorted the sorting is
> done on
> WH> the internally stored IDs only!
>
> This has to change. The model must be notified about the change of the
> sort order, and it will simply provide data to you according to the
> new
> order (e.g. it will rerun the query against the database with the new
> "ORDER BY" clause).
>
Then, you have to rewrite the wxDataViewModel first. It does not work
like this.
1) Sorting is done by the wxDataViewModel::Compare method and by
nothing else. The model itself does not do any sorting.
2) wxDataViewModel::GetChildren does not guarantee that the children
are sorted. Even this function MUST NOT guarantee that the children
are sorted because otherwise you cannot use the same model for two or
more controls (the two controls might use the same data but the data
can be sorted differently in the two controls).
3) Furthermore, there is NO guarantee that two calls after each other
of wxDataViewModel::GetChildren are returning the children in the same
order even if the model is not changed (actually SQL without an 'ORDER
BY' statement also does not guarantee it).
So, the current wxWidget model - control concept is based on the fact
that the control is asking for data from the model (with or without
buffering the data is irrelevant) and that the control is responsible
for sorting the data via the wxDataViewModel::Compare function.
>
> WH> This is the process for Cocoa:
> WH>
> WH> - native control ask for the number of children for the root
> (and
> WH> eventually recursively for the number of children of the root's
> WH> children)
>
> Good.
>
> WH> - IDs of the supplied children's IDs are stored internally
> (IDs are
> WH> sorted with respect to the sortable columns by using
> WH> wxDataViewModel::Compare)
>
> Bad.
>
See above. There is currently no viable alternative.
> WH> - data is loaded
>
> Irrelevant, it may be loaded or not, it doesn't change anything either
> way.
>
> WH> - resorting of the data triggered by the user forces a
> complete re-
> WH> load of the data
>
> Extremely bad.
That's the only way in Cocoa. Cocoa is notified of a change by telling
Cocoa that an item of a parent has changed. But you cannot tell Cocoa
which item changed. Therefore, the parent's children have to be
updated. In the current implementation the IDs of the parent are
reloaded (not the rest of the data) and re-sorted.
>
>
> WH> Summary:
> WH>
> WH> While you do not have a chance with Carbon to have a virtual
> dataview
> WH> control the chances are good that it works with Cocoa. But there
> is no
> WH> guarantee from Apple.
>
> Sorry, I still don't understand at all the problem you have. What
> guarantee do you need and why? NSOutlineView clearly supports
> exactly what
> we need to implement a fully virtual control. The problem is in wxDVC
> handling of sorting which, if I understood you correctly, is simply
> inappropriate for virtual controls.
>
Yes, you got it. The current model - control concept (wxDVC) does not
work for virtual controls.
> WH> So, my previous statement ("Cocoa does not support a dataview
> using
> WH> virtual data") was probably too strong. There is just no guarantee
> WH> that it works (with the native implementation of OS X 10.5 it
> does; I
> WH> did not check with 10.6).
>
> I see no reason to doubt that it does work under 10.6, why do you
> think it
> shouldn't work there?
>
As long as there is no documentation I do not make any assumption
whether it has been changed or not. As long as it is not documented
Apple can do what they want and we cannot make any assumptions.
Though I believe that nothing has changed.
> WH> Attention: by implementing a dataview with virtual data as
> described
> WH> here you can use only one model with one control! Normally, the
> same
> WH> model can be used for several controls.
>
> When you do sorting inside the model (as you must do with virtual
> controls) it indeed becomes impossible to share it among different
> views.
> This is hardly as important as allowing to have virtual controls in
> the
> first place.
>
The general model - control approach (wxDVC) does not limit the usage
of one model for one control. The general case is one model for
several controls. Therefore, the model MUST NOT sort the data
internally (see above)! Or you have to change the wxDataViewModel
concept.
> Regards,
> VZ
>
> --
> TT-Solutions: wxWidgets consultancy and technical support
> http://www.tt-solutions.com/
So, if you implement wxDataViewVirtualModel and
wxDataViewVirtualControl compliant to virtual models only and the
restriction one model for one control the implementation in Cocoa of
"virtual data" as defined by you above is not problem at all.
Actually, wxDataViewVirtualControl could inherit wxDataViewControl and
only a few lines have to be changed.
Hartwig