REALLY IMPORTANT: is anyone interested in HMG4 ?

Moderator: Rathinagiri

User avatar
bedipritpal
Posts: 122
Joined: Thu Sep 02, 2010 10:47 pm

Re: REALLY IMPORTANT: is anyone interested in HMG4 ?

Post by bedipritpal » Fri Sep 30, 2011 7:22 pm

mrduck wrote:

Code: Select all

METHOD XbpBrowse:manageCommitData( qWidget )
   LOCAL cTxt    := hbqt_promotWidget( qWidget, "QLineEdit" ):text()
It seems to me that hbqt_promotWidget is not working anymore... it used to work but when we changed the class subsystem it stopped to work...
I will be looking into it after few hours.
enjoy hbIDEing... Pritpal Bedi

User avatar
bedipritpal
Posts: 122
Joined: Thu Sep 02, 2010 10:47 pm

Post by bedipritpal » Fri Sep 30, 2011 7:26 pm

mrduck wrote:Pritpal,
your proposal is interesting.

I did a look at the code and I see that xbpbrowse is really complete: it has footers, and locked columns at left and right. In order to handle all this, it goes to a lower level, directly handling keyboard, mouse etc... nice code....

I also see there is a cache system and in some conditions there is the model reset, to refresh all the grid. For example in page-up and page-down.
But as far as I know, a reset forces a new record count and in some cases it may be "heavy"...

I could also not locale if there is handling of SHARED dbf... it seems to me that there is no protection...

Thanks for pointing to that code, it may give us some ideas.

If you study carefully, no record count is performed.
The record count is the number of rows visible in the window
at any given time. It simulates exactly TBrowse functionality
and the basic building blocks are copied from tbrowse.prg itself.
It has no overhead whatsoever. Table containing millinions of records
can be browsed instantly.

And what shared access you are taking about ?
It is RDD's responsibility to handle, not XbpBrowse's.
enjoy hbIDEing... Pritpal Bedi

User avatar
bedipritpal
Posts: 122
Joined: Thu Sep 02, 2010 10:47 pm

Post by bedipritpal » Fri Sep 30, 2011 7:33 pm

bedipritpal wrote:I will be looking into it after few hours.
It is working absolutely fine.
What problem did you had ?

To test:
1. Open hbIDE
2. Click om ideDBU icon
3. Open table harbour/tests/test.dbf
4. On any cell start typing and press enter
5. New value is there in the table
enjoy hbIDEing... Pritpal Bedi

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Fri Sep 30, 2011 10:33 pm

Hi Pritpal.

I tested hbide and it works correctly. But in my code I got VALTYPE( cData ) = "P"...:

Code: Select all

   cData := hbqt_promotWidget( pWidget, "QLineEdit" ):text()
this evening, after hours spent in the last days looking on problems on prg code, I went to check my current hbqt code... I have a private repository where I store all my tests from the period when we changed the hbQt internals... there are tests that have been remmed, branches that need further study or to be adapted to current hbQt internals...

I don't know why back in time I added an execQWidget also in qtCORE\hbqt_init.cpp. I did when we still used the function hbqt_create_object.... then we switched to hbqt_create_objectGC but merging with official svn changed all references to *GC but one... guess which one ?

So, it is quite harmless to have a duplicate callback definition (they are static so no problem for duplicate names) but the registering of the callbacks is initiated by a c++ equivalent of a INIT PROCEDURE... so in hbide the linker placed segments in a way that first were registered the callbacks from qtgui and so the correct function was registered (the one using *GC function)... in my code, the other callback was first registered... and .... BOOM...

Now I removed that duplicate definition and, VOILA', it is correctly working !


Thanks

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Sat Oct 01, 2011 9:54 am

bedipritpal wrote: If you study carefully, no record count is performed.
Yes, I saw. You use OrdKeyC o u nt()
The record count is the number of rows visible in the window
at any given time. It simulates exactly TBrowse functionality
and the basic building blocks are copied from tbrowse.prg itself.
It has no overhead whatsoever. Table containing millinions of records
can be browsed instantly.
What about a 100.000 record table with a SET FILTER that extracts just a few records ? Not that is a common case...
And what shared access you are taking about ?
It is RDD's responsibility to handle, not XbpBrowse's.
I saw that there is rlock()/unlock code... this is a first step protection. But what happens if someone else changes the data before you ?
Two user browse the same file, the same record and the same field. There is the value 7 inside. One needs to add 2, the other needs to add 8. The total shoul be 17. But they both start editing when both have 7 as value, so one writes 9, the other 15, and the last one wins... it seem to me that there is no rlock at editing start but just at the moment you write the data, and there is no check that the underlaying data was changed by someone else.....

User avatar
apais
Posts: 274
Joined: Fri Aug 01, 2008 6:03 pm
Location: uruguay
Has thanked: 33 times
Been thanked: 21 times
Contact:

Post by apais » Sat Oct 01, 2011 9:05 pm

Same problems existed in clipper's tbrowse
Filtering and concurrent editing is programmers responsibility

I think a command layer around Pritpal's xbpBrowse() would be an excelente aditiion to HMQTG (Harbour Mini QT Qui ) ;)

Regards
Angel

"Excelence is the main enemy of well done things" (translated popular saying )

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Sat Oct 01, 2011 9:47 pm

Angel,
xbpBrowse is really a nice piece of code and has superior features respect of VIRTUALGRID. It can lock columns at the left and right, and can have footers, for example... it has code for a full browse, I mean, it does a lot of work that Qt does in VIRTUALGRID.

xbpBrowse is tied to xbp framework. I think it would be easily portable to HMG4 but I don't know if it will be compatible with HMG3 commands... Of course it may be an alternative browse system....
apais wrote:Same problems existed in clipper's tbrowse
Filtering and concurrent editing is programmers responsibility
Ok, I understand.

Thanks

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Sat Oct 01, 2011 10:12 pm

Ricci wrote:1st Child window with graphic and GRID. Everything works well.

But .... just got the information that the graph code must be revised. :(
The code is working well, no doubt, but as you have discovered we moved all the DATA members to be PROTECTED, to avoid unnecessary and dangerous direct access to them. Not every part of HMG4 code has been tested against this change... and graph was one of them, no testing done.

Now you requested to remove the PROTECTED to a couple of data members... I don't agree, no internat data should be exposed directly... so we need to add a SETGET method for that 2 DATA members...

While we will look at this, you can do the change in your local repo... better yet would be to correct graph.prg code... :-)

User avatar
Rathinagiri
Posts: 5210
Joined: Tue Jul 29, 2008 6:30 pm
DBs Used: MariaDB, SQLite, SQLCipher and MySQL
Location: Sivakasi, India
Has thanked: 155 times
Been thanked: 144 times
Contact:

Post by Rathinagiri » Wed Oct 12, 2011 2:24 pm

Hi,

Today, I have tried to compile my latest dbf<-->sqlite exporter in HMG 4 and I could not compile with progressbar control. I don't know why. :(

I could get the code compiled with -w0 and commenting out progressbar.

Here is the whole project.
dbf2sqlite.zip
(32.37 KiB) Downloaded 114 times
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

User avatar
l3whmg
Posts: 694
Joined: Mon Feb 23, 2009 8:46 pm
Location: Italy
Contact:

Post by l3whmg » Wed Oct 12, 2011 5:12 pm

Hi Rathinagiri.
I will investigate As Soon As Possible. I'm working with Francesco about window* management.
Cheers
Luigi from Italy
www.L3W.it

Post Reply