REVISION OF GRID/BROWSE

Creative ideas/suggestions for HMG

Moderator: Rathinagiri

User avatar
mol
Posts: 3718
Joined: Thu Sep 11, 2008 5:31 am
Location: Myszków, Poland
Contact:

Re: REVISION OF GRID/BROWSE

Post by mol »

Hi brain!
I was thinking about such a solution: array for record numbers and virtual grid. But, it's hard to realize this idea. It should jump over dbf file to access rows by recno. What about speed?
User avatar
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

Post by Rathinagiri »

mol wrote:You can say that sqlite exists, but it hasn't still some types of fields.
Marek,

Can you please list out those types?
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
User avatar
mol
Posts: 3718
Joined: Thu Sep 11, 2008 5:31 am
Location: Myszków, Poland
Contact:

Re: REVISION OF GRID/BROWSE

Post by mol »

boolean, date - these types need converting to string or integers
EduardoLuis
Posts: 682
Joined: Tue Jun 04, 2013 6:33 pm
Location: Argentina

Re: REVISION OF GRID/BROWSE

Post by EduardoLuis »

Hi Friends:

I think Pablo Cesar propousal is the best way to solve the problem.-
Although i don't think grid is the reason because memory is excceded, with a sample it's possible to search a solution to help you and Mol.-
What becomes trully baffling, is that grid works fine during nearly 8 hours and then memory collapses (cliente reference Mol); this collapse reveals more a hardware or SO conflict rather than been generated by grid.-
With the small sample (as said Pablo Cesar) a solution will be find.-
I think the best solution to avoid memory issues is developing app in lost of minimal independent sub-app.- That is the method i use on my developes (1 principal exe (app) and several (exes app) that closes after been executed freeing memory.- Also to avoid conflicts, i use a PC with minimal hardware (XP Sp3 (64 bits), 512 ram, Pentium IV), so if it works on this hardware will work on any superior (by the way today smallest pc have 2 g ram).-
Although - as somebody said - many have migrate to SQL instead DBF, i agree with Mol that DBF is more efficient managing different types of fields.-
Waiting your small sample, with regards. Eduardo

Hola Amigos:

Creo que la propuesta de Pablo Cesar es le mejor para intentar solucionar el problema.-
Aunque no creo que el control grid sea la causa del colapso de la memoria, con un pequeño ejemplo será posible arribar a una solución para poder ayudarlos (Mol y Luis).-
Lo que resulta ciertamente desconcertante, es que el grid funcione correctamente durante 8 horas y luego colapse la memoria (en el ejemplo referenciado por Mol respecto de uno de sus clientes); en mi opinión ese colapso revela mas un problema de hardware o SO que otro generado por el grid.-
COn un pequeño ejemplo (como cita Pablo Cesar) la solución podrá ser hallada.-
Creo que la mejor solución para impedir conflictos de memoria es desarrollar la aplicación en pequeñas e independientes subaplicaciones.- Ese es el metodo que uso para el desarrollo de aplicaciones (1 ejecutable principal y cientos de sub-ejecutables que al cerrarse liberan la memoria.- Asimismo, para evitar conflictos, uso para mis desarrollos una PC con mínimos requerimientos de hardware (XP SP3 (64 bits), 512 ram, Pentium 4), de manera que si funcionan en este hardware funcionaran tambien en superiors (por cierto hoy las más pequeñas PC cuentan con 2 g ram).-
Aunque - como alguien mencionó - muchos han migrado a SQL en lugar de DBF, estoy de acuerdo con Mol en cuanto a la eficiencia y habilidad de manejo de diferentes tipos de campos que brinda el formato DBF.-
Esperando suban un pequeño ejemplo, con mi consideración los saludo. Eduardo
User avatar
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

Post by Rathinagiri »

mol wrote:boolean, date - these types need converting to string or integers
Yes, it is true that SQLite can accept any data on any column (data saved as characters), it has many data types including boolean. Please see the image:
sqlite.jpg
sqlite.jpg (49.74 KiB) Viewed 5287 times
I am using SQLite for single user systems and MySQL for multi user systems without any memory/data type problem using HMGSQL bridge which can safely transform any type of HMG data into SQL based format.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
User avatar
luisvasquezcl
Posts: 1258
Joined: Thu Jul 31, 2008 3:23 am
Location: Chile
Contact:

Re: REVISION OF GRID/BROWSE

Post by luisvasquezcl »

Hola estimados,
les dejo un demo que reproduce el problema.
Vayan abriendo y cerrando las ventanas y veran que no libera la memoria.
Saludos cordiales,
Luis Vásquez.

Hello dear,
I leave a demo that reproduces the problem.
Go opening and closing windows and you will see that not release the memory.
Best regards,
Luis Vasquez.
Attachments
test6.zip
demo
(1.23 KiB) Downloaded 310 times
User avatar
luisvasquezcl
Posts: 1258
Joined: Thu Jul 31, 2008 3:23 am
Location: Chile
Contact:

Re: REVISION OF GRID/BROWSE

Post by luisvasquezcl »

sistema operativo : Windows 7 - Windows 8
Hmg 3.4.0 patch 1
32 bits.
Best regards,
Luis Vasquez
User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil

REVISION OF GRID/BROWSE

Post by Pablo César »

Hola Luis,

Gracias por disponibilizar tu código/ejemplo.

Realmente, no habia notado eso. Tienen razon, acada vez que se abre el GRID y se cierra la ventana, no libera memoria, al contrario, comienza acumular a cada vez que es abierto el GRID.

Hice algunas pruebas con DataGridClearBuffer1 (removi el DataGridRefresh en mi funcion) y lo adicioné el el evento ON RELEASE de la ventana, pero no hizo ninguna diferencia. :(

Talvez el Dr. Claudio pueda darnos una luz.
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein
User avatar
luisvasquezcl
Posts: 1258
Joined: Thu Jul 31, 2008 3:23 am
Location: Chile
Contact:

Re: REVISION OF GRID/BROWSE

Post by luisvasquezcl »

Excelentes noticias Pablo, ojalá puedan darle solución a este problema y creo que de paso se solucionará el browse.
Vi en el código fuente algunas variables que no sé donde se liberan como por ejemplo:
Linea 62: memVar aTemp
Linea 63: memvar retarray
Linea 64: MEMVAR aRows
creo que su uso es limitado y en muchos casos es posible declararlas dentro del procedimiento/función y no como variables de memoria.
saludos cordiales,
Luis Vasquez
User avatar
Roberto Lopez
HMG Founder
Posts: 4004
Joined: Wed Jul 30, 2008 6:43 pm

Re: REVISION OF GRID/BROWSE

Post by Roberto Lopez »

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

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 :)
Regards/Saludos,

Roberto


(Veritas Filia Temporis)
Post Reply