[Gambas-user] TableView Problem

Benoit Minisini gambas at ...1...
Mon Nov 7 10:22:27 CET 2005


On Monday 07 November 2005 08:45, Eilert wrote:
> Hi Fernando,
>
> you are right :-) I tried this
>
> > To count the _DATA events, do (similar to) the following.
> >
> > Create a label called Label_Count
> > with TEXT as 0 (zero)
> >
> > The first code line inside the _Data event for the TableView..
> > Label_Count.Text = Label_Count.Text + 1
> >
> > ... now scroll and/or click on your TableView.
> >
> > Watch the count
>
> and it turned out that even dragging another window over a TableView
> will trigger the _DATA event. So, yes, if in code you connect it
> directly to SQL queries, I guess you get into trouble. 

Not strange, as the TableView buffers nothing.

> The only way to 
> make it fast is to buffer the data in an array. Very strange.

But the SQL Result object *is* a buffer, so you don't have to do that. Just 
use the Result object as a buffer.

>
> However, on my machine this doesn't cause much CPU load. So, is this
> discussion somewhat academical? Benoit is not to blame for it, the
> Trolltech guys are. We cannot change this. So what?
>
> > Also, notice how the Label is a static control.
> > Its implementation is opposite to your comment.
>
> Well - my comment was to never let graphical controls store any data for
> you, just display them. The only exception perhaps is with input
> controls like text boxes. You won't have another chance than accepting
> that they keep the original data for the time of user input (though you
> still could catch every keystroke and save it in parallel somewhere else).
>
> During the last years I found that most data you want to display have to
> be processed before displaying, i. e. in case you let the displaying
> control save the data, you will have to re-process the data into the
> saving format afterwards because the user might have changed something
> (except when they're for display only, but this is a rare case here).
> This will make it necessary to write a lot of code reacting to clicks
> and processing/reprocessing data. So the program may become somewhat
> difficult to overview.
>
> I found the advice from the guy (or guys) was good for me and my kind of
> projects. At that time, I had programmed one thing that displayed data
> processing them for display and displaying them in table view (this was
> VB then). After discussing some items with those folks, I began to code
> a new version of the software, and during the talks I got this advice.
> After trying to split my new program into distinct layers of storage,
> processing and display, I found it made it much clearer, so I'm
> following this rule ever since.
>
> Rolf
>

Good advice :-)

Regards,

-- 
Benoit Minisini





More information about the User mailing list