REALLY IMPORTANT: is anyone interested in HMG4 ?

[concentra]

Since we are at databases.... how do you handle DBFs that change in size ?

I explain: in this moment if you have a VGRID browsing a DBF, if someone changes the records contents, or adds/deletes a record, these changes may not be shown in the grid, until you do a :refresh()

Did you handle this case ? How ? I've some ideas but before writing code I'd like to do some more brain-storming

I don't.
Clipper don't.
As far as I know, FiveWin don't.
Most of the time this is not relevant to me and when it is, I handle with refreshs, but can't remember last time I did such situation.
But if the operator moves around the browse, like doing a page up/down, it reflects changed data.
Rathi's idea of a timer to refresh is interesting but it can be optional and added when the coder needs it.

[l3whmg]

Hi Mauricio

Since we are at databases.... how do you handle DBFs that change in size ?

I explain: in this moment if you have a VGRID browsing a DBF, if someone changes the records contents, or adds/deletes a record, these changes may not be shown in the grid, until you do a :refresh()

I don't.
Clipper don't.

I don't know with BROWSE command, but you can open a table in share mode and use LOCK and UNLOCK to prevent access. So, in this scenario, two different user can add/modify/delete the same record (and you can prevent this problem with LOCK); but, at the same time, they can add different records.

With HMG3 and GRID is the same: you must refresh the table to know what happens. Records are added/deleted/modified (I think) and if you want to change/delete you must lock the record. Maybe a problem when you want to add: I think about UNIQUE key...but you can handle this scenario.

Or I have not understood your doubt.

Cheers

[concentra]

Hi Luigi.

Or I have not understood your doubt.

No doubt.
I got a situation where the database pointer moves between a sequence of commands that didn't move the pointer at all.
And this was caused by the virtualgrid.
And so I opened the database twice as a workaround.
I didn't report this because I am using an old version of HMG4 since I tried to use the new one, got other problems and back to the old and added code from the new one to it.
I didn't had the time to debug the new one since I had a timeline to make the job done.
When I finish it I will return to this in the new one.

[l3whmg]

Hi friends.
Ok Mauricio: I understand.

About a timer, to refresh the grid, I think it's very dangerous.
Remember: the end program knows rows (basically) through the Grid.ItemCount and Grid.Value methods.

Please follow this example.

There are two user and they work on the same table; they use a grid.

At the same time, they see this situation on grid:

Code: Select all

ITEM Description
1    Article1
2    Article2
3    Article3
empty row

Total row (Grid.ItemCount) is 3

User1 wants change row 2 (Grid.Value), but for a while he works on another form to enter data.
End program knows there are 3 rows and the worker has selected row numer 2

At the same time, User2 delete the ITEM 1 and he is more fast (not like me ).
The situation for User2 is now

Code: Select all

ITEM Description
1    Article2
2    Article3
empty row

What happens for User1?
The timer refresh his grid (like User2), but he was watching another form with related Function.
Remember: there were 3 rows and User1 was managing row 2.
He want to update row 2 but he rewrites the Article3 row with data from Article2 and Article3 is disappeared.

IMHO: if you are thinking about a monitoring grid (to see an infinite number of rows, like topics in a forum) can be a good idea, but for managing data (edit/delete) it's very, very dangerous.

To handle in a correct way the timer refresh, all the end programs must be aligned, sincronized with the same data.
In a very simple way, I think a manually refresh is better in this scenario.

Cheers

[mrduck]

You are right, Luigi, VIRTUALGRIDs with shared DBFs are way too complex... I will post a message later to explain

[Roberto Lopez]

In a very simple way, I think a manually refresh is better in this scenario.

What about a method to found if a table was modified from the last refresh?

[bedipritpal]

Hello All

Probably some of you would like to adopt
harbour/contrib/hbxbp/xbpbrowse.prg which
is a TBrowse like implementation, i.e., every record
is visible in real-time. Documentation is available
in Xbase++ help manuals.

You may end up by adopting the code to HMG methodology.

Pritpal Bedi

[mrduck]

Hi Pritpal,
please have a look at these lines:

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...

[mrduck]

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.

[Ricci]

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

But .... just got the information that the graph code must be revised.

HMG3


HMG4