Page 1 of 1

Propose for an incompatible change to virtualgrid

Posted: Tue Dec 13, 2011 4:25 pm
by mrduck
in HMG4 we have GRID and VIRTUALGRID (and browse, but virtualgrid should be used)

GRID: based on QTableWidget, you need to load cell values into it, since the values are handled by hbQt directly. Internally it uses QTableWidgetItem for strings and a proper widget in editing. To retrieve data you need to check the cell values.

VIRTUALGRID: based on QTableView, it uses callbacks to display cell values/colors/styles etc. It actually works on DBF and arrays. The callback function answer to Qt reading data from DBF or array. The difference is that DBF is "live", data is stored on the "live" database and it may be opened in shared mode and someone else can change it (with a bit of sync with the program). On arrays, instead, we work on a clone.

My proposal is to change a single line of code

From:

Code: Select all

   ::aItems := aClone( aValue )
to:

Code: Select all

   ::aItems := aValue
In this way VIRTUALGRID works on the same array you passed as a parameter and you don't need to retrieve data from the virtualgrid but you can just access the array !

This is a incompatible change since you may now load different virtualgrid using one array, you won't be able to do this after this change !

What do you think ?

Re: Propose for an incompatible change to virtualgrid

Posted: Tue Dec 13, 2011 5:00 pm
by Rathinagiri
Francesco,

Can you explain the advantages of this feature?

Re: Propose for an incompatible change to virtualgrid

Posted: Tue Dec 13, 2011 5:35 pm
by mrduck
rathinagiri wrote:Francesco,

Can you explain the advantages of this feature?
.

You have the changes directly in the array without the need to retrieve them from the virtualgrid.

It is also to have common behaviour between DBF and arrays: in both cases of virtualgrid the underlying "model" (it's the Qt name for the data source) is directly modified.

Re: Propose for an incompatible change to virtualgrid

Posted: Tue Dec 13, 2011 8:10 pm
by l3whmg
Hi to everyone.
I think it can be very beneficial. At this moment, I do not know a contraindication.
Cheers

Re: Propose for an incompatible change to virtualgrid

Posted: Tue Dec 13, 2011 9:00 pm
by apais
What about changing VIRTUALGRID's name to SyncedGRID ?
It seems a more intuitive name for the proposed new functionality.

Regards
Angel

Re: Propose for an incompatible change to virtualgrid

Posted: Tue Dec 13, 2011 9:37 pm
by mrduck
apais wrote: It seems a more intuitive name for the proposed new functionality.
I think this is the functionality that it should always have had....

Re: Propose for an incompatible change to virtualgrid

Posted: Tue Dec 13, 2011 9:57 pm
by apais
ConnectedGRID, OnLineGRID ??

Virtual means nothing to me, Am I alone ?

Re: Propose for an incompatible change to virtualgrid

Posted: Wed Dec 14, 2011 10:45 am
by dhaine_adp
Hi,

I think we can have them both unless we would like to drop the support for virtual. What about if we associate the virtual with the call. When virtual grid is on, it will do an ACLONE() when it is off, it will work on the actual array as you outline it. Just a question?

Regards,

Danny

Re: Propose for an incompatible change to virtualgrid

Posted: Wed Dec 14, 2011 11:35 am
by mrduck
@Angel

It's not the name that is important now, but the idea to have something that directly modifies the underlying data, be it an array or a DBF.

I had a test program with two identical virtualgrids. I loaded them with one array. With the aClone() each virtualgrid was indipendent and at the end I had to load back values from each virtualgrid.

Removing the aClone, a change in one virtualgrid was automatically applied (when refresh occurred) to the other, since the data model (in qt language) is the same. It is the same effect if you used a DBF for the data source...

This proposal is to have the same behaviour !

Of course I had to create 2 arrays and load each virtualgrids with one of them.


@Danny
as you can read in the first post, they are based on 2 different Qt objects and it would be complex to join the source code... something can still be done and I'll do as soon as I can, and after we may change the virtualgrid name...


There is still work to be done on these objects and I'll be happy if you can help writing some proof-of-concept code, perhaps porting some forms from your hmg3 programs. In this way we will have hmg4 compliant source code to use as a real demo, and check hmg3 compatibility layer.

Francesco

Re: Propose for an incompatible change to virtualgrid

Posted: Wed Dec 14, 2011 11:43 am
by apais
Hi Francesco

Maybe I was incapable of explaining myself.
My previous answer was an implicit endorsement to the idea of a "connected" grid (it should allways been like that).
Just leaving virtualgrid as it is now for compatibility and creating a new command with a new name for this one

Best Regards
Angel