... too many thing altogether ...Roberto Lopez wrote:...
The times are changing... and IMHO the xBase Browse way belongs to the past...
...
REVISION OF GRID/BROWSE
Moderator: Rathinagiri
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: REVISION OF GRID/BROWSE
Viva INTERNATIONAL HMG
- Rathinagiri
- Posts: 5471
- Joined: Tue Jul 29, 2008 6:30 pm
- DBs Used: MariaDB, SQLite, SQLCipher and MySQL
- Location: Sivakasi, India
- Contact:
Re: REVISION OF GRID/BROWSE
Rightly said Master.Roberto Lopez wrote:As I've explained a couple of times already, the last years I'm mainly using NETIO with excellent results. I use remote procedures, so, all the data handling is done in the server.mol wrote:I'm still using dbfs and browse control. I think it should always be updated.
I remember Roberto words, where he turned back from words this control is obsolete.
Great advantage of dbfs is this system is portable.
You can say that sqlite exists, but it hasn't still some types of fields.
Moreover, when I occasionally need to work with local data, I do not use Browse, nor DataGrid.
I use simple grids that are loaded with the required data from dbfs, using constructs like LOCATE FOR... DO WHILE FOUND()... CONTINUE... ENDDO. In some cases, the use of conditional, temporary indexes, is a good technique too.
The grid is automatically updated, after append, delete, and modify operations, or manually (by the user) via a simple [Refresh] button.
IMHO, this is the more efficient and simple way to work, and since the users are habituated to think in 'client/server' way, because the web, there is no problem on that side either.
If I were starting a new GUI library now, I'm pretty sure that I could not include data bound controls in it.
I guess that the only required thing, could be a method, to assign to the grid, a two dimensional array (the recordset) in an efficient, very fast way.
The times are changing... and IMHO the xBase Browse way belongs to the past...
I admit that my decision of tagging browse as obsolete was premature, but, IMHO, sooner or later, that will happen, simply because 'the world' is switching to client/server and because it is a better way to work.
An additional benefit of this approach is the separation between user interface (presentation) and data handling... another 'unavoidable' thing... I can assure you, that this will make your programmer life a lot easier
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: REVISION OF GRID/BROWSE
tnx for the advise mr pablo but when i am using BROWSE it is also similar with the GRID because the DBF records will be stored to the array then display, what if i have 1M of records to display? unlike the DBEDIT functions even how many records do u want to display it will not get slower just because if u want to display 20 records per page, data[20] arrays only you will use. everytime a loop does, the function itself substitute the remaining records to the 20 arrays. even in the SQL i think we can use my suggestion. tnx and more power!Pablo César wrote:What we have to understand is GRID and BROWSE are different controls.
When you said like dbEdit, must be cleared something: an control for exclusive use for DBFs, right ?
Because dbEdit only works with databases and also it's hard to work on to conciliate both: arrays and databases in GRIDs.
Otherwise Joselito (brain), why are you requesting this ?
BROWSE is deprecated (descontinued) in HMG and not implementations have been done over this control.
My suggestion is to work on the BROWSE or with other similar name for only and exclusive use for DBFs and working similar of TBrowseDB of old Clipper but in this time in GUI. I'm not sure if this is posible and also I do not know if it's worth it considering many users are migrating to SQL usage instead DBFs.
- dragancesu
- Posts: 921
- Joined: Mon Jun 24, 2013 11:53 am
- DBs Used: DBF, MySQL, Oracle
- Location: Subotica, Serbia
Re: REVISION OF GRID/BROWSE
There are tables with lots of data, 1M may not be much, but I do not know the situation when all that needs to show, it usually takes show part of the data (a filter), and then it is usually up to 5 screens which is acceptable
maybe I do not know, tell me the situation should show 1M data?
maybe I do not know, tell me the situation should show 1M data?
- luisvasquezcl
- Posts: 1258
- Joined: Thu Jul 31, 2008 3:23 am
- Location: Chile
- Contact:
Re: REVISION OF GRID/BROWSE
Estimados,
Vuelvo a activar este tema ya que aún sigue el problema con el grid.
Les comento que lo uso cargando los datos en array y no conectado a DBF.
Al ir recargando el grid con datos parcializados, que en algunos casos pueden ser 300 lineas, el aumento de memoria es muy grande y se nota ya que comienza a poner lenta la aplicación.
Espero se pueda solucionar este problema.
Saludos cordiales,
Luis Vásquez.
Dear,
I reactivate this issue and that is still the problem with the grid.
I commented that I use loading data array and not connected to DBF.
To go recharging the grid with biased data, which in some cases may be 300 lines, increased memory is very large and it shows as it begins to slowly put the application.
I hope this problem can be solved.
Best regards,
Vuelvo a activar este tema ya que aún sigue el problema con el grid.
Les comento que lo uso cargando los datos en array y no conectado a DBF.
Al ir recargando el grid con datos parcializados, que en algunos casos pueden ser 300 lineas, el aumento de memoria es muy grande y se nota ya que comienza a poner lenta la aplicación.
Espero se pueda solucionar este problema.
Saludos cordiales,
Luis Vásquez.
Dear,
I reactivate this issue and that is still the problem with the grid.
I commented that I use loading data array and not connected to DBF.
To go recharging the grid with biased data, which in some cases may be 300 lines, increased memory is very large and it shows as it begins to slowly put the application.
I hope this problem can be solved.
Best regards,
- luisvasquezcl
- Posts: 1258
- Joined: Thu Jul 31, 2008 3:23 am
- Location: Chile
- Contact:
Re: REVISION OF GRID/BROWSE
Estimados,
estoy probando con grid virtual pero el problema es peor, ya que está aumentando constantemente.
saludos cordiales,
Dear,
I'm testing with virtual grid but the problem is worse because it is constantly increasing.
Best regards,
estoy probando con grid virtual pero el problema es peor, ya que está aumentando constantemente.
saludos cordiales,
Dear,
I'm testing with virtual grid but the problem is worse because it is constantly increasing.
Best regards,
Re: REVISION OF GRID/BROWSE
Hi guys!
I want to refresh this topic and present modified sample 38 of grid. My friend was testing this sample with few version of HMG and got a lot of strange behaviours.
The display content of the grid becomes blank when you divide by 0 (call upper menu -> Divide -> Divide 3/0).
The display also stay blank when you lock LOCK.DBF file eg. by dbu before running this sample.
I'm attaching sample with .dbf files.
Regards, Marek
I want to refresh this topic and present modified sample 38 of grid. My friend was testing this sample with few version of HMG and got a lot of strange behaviours.
The display content of the grid becomes blank when you divide by 0 (call upper menu -> Divide -> Divide 3/0).
The display also stay blank when you lock LOCK.DBF file eg. by dbu before running this sample.
I'm attaching sample with .dbf files.
Regards, Marek
- Attachments
-
- GRID_Problems.ZIP
- (4.97 KiB) Downloaded 328 times
- serge_girard
- Posts: 3167
- Joined: Sun Nov 25, 2012 2:44 pm
- DBs Used: 1 MySQL - MariaDB
2 DBF - Location: Belgium
- Contact:
Re: REVISION OF GRID/BROWSE
Hi Marek,
I try later your demo.
IMHO it is always better to retrieve data (after or before) showing in a grid. In this way you NEVER lock the database.
This is how very large systems on mainframes works and if you work with much records, consider paging. (This is more complicated...)
I use arrays build-up just before DEFINE WINDOWS or after with ADD ITEM {aARRAY, ...} TO GRID... OF ...
Greetings, Serge
I try later your demo.
IMHO it is always better to retrieve data (after or before) showing in a grid. In this way you NEVER lock the database.
This is how very large systems on mainframes works and if you work with much records, consider paging. (This is more complicated...)
I use arrays build-up just before DEFINE WINDOWS or after with ADD ITEM {aARRAY, ...} TO GRID... OF ...
Greetings, Serge
There's nothing you can do that can't be done...
Re: REVISION OF GRID/BROWSE
This is only sample for testing...
Thanks for your interest, Serge!
Thanks for your interest, Serge!
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: REVISION OF GRID/BROWSE
Hi Marekmol wrote:Hi guys!
I want to refresh this topic and present modified sample 38 of grid. My friend was testing this sample with few version of HMG and got a lot of strange behaviours.
The display content of the grid becomes blank when you divide by 0 (call upper menu -> Divide -> Divide 3/0).
The display also stay blank when you lock LOCK.DBF file eg. by dbu before running this sample.
I'm attaching sample with .dbf files.
Regards, Marek
IMHO you need your own error recovery system in order to distinguish error situations from GRID's one.
Please look at attached demo ( slightly modified version of your test demo.prg);
I hope it will give you an idea
Viva HMG
Viva INTERNATIONAL HMG