I will be looking into it after few hours.mrduck wrote: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...Code: Select all
METHOD XbpBrowse:manageCommitData( qWidget ) LOCAL cTxt := hbqt_promotWidget( qWidget, "QLineEdit" ):text()
REALLY IMPORTANT: is anyone interested in HMG4 ?
Moderator: Rathinagiri
- bedipritpal
- Posts: 122
- Joined: Thu Sep 02, 2010 10:47 pm
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
enjoy hbIDEing... Pritpal Bedi
- bedipritpal
- Posts: 122
- Joined: Thu Sep 02, 2010 10:47 pm
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
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
- bedipritpal
- Posts: 122
- Joined: Thu Sep 02, 2010 10:47 pm
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
It is working absolutely fine.bedipritpal wrote:I will be looking into it after few hours.
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
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
Hi Pritpal.
I tested hbide and it works correctly. But in my code I got VALTYPE( cData ) = "P"...:
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
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()
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
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
Yes, I saw. You use OrdKeyC o u nt()bedipritpal wrote: If you study carefully, no record count is performed.
What about a 100.000 record table with a SET FILTER that extracts just a few records ? Not that is a common case...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.
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 ?And what shared access you are taking about ?
It is RDD's responsibility to handle, not XbpBrowse's.
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.....
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
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 )
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 )
Angel Pais
Web Apps consultant/architect/developer.
Web Apps consultant/architect/developer.
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
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....
Thanks
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....
Ok, I understand.apais wrote:Same problems existed in clipper's tbrowse
Filtering and concurrent editing is programmers responsibility
Thanks
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
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.Ricci wrote:1st Child window with graphic and GRID. Everything works well.
But .... just got the information that the graph code must be revised.
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...
- Rathinagiri
- Posts: 5471
- Joined: Tue Jul 29, 2008 6:30 pm
- DBs Used: MariaDB, SQLite, SQLCipher and MySQL
- Location: Sivakasi, India
- Contact:
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
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.
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.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
South or North HMG is worth.
...the possibilities are endless.
Re: REALLY IMPORTANT: is anyone interested in HMG4 ?
Hi Rathinagiri.
I will investigate As Soon As Possible. I'm working with Francesco about window* management.
Cheers
I will investigate As Soon As Possible. I'm working with Francesco about window* management.
Cheers
Luigi from Italy
www.L3W.it
www.L3W.it