GRIDSETORDER()

Source code related resources

Moderator: Rathinagiri

User avatar
AdrianSB
Posts: 17
Joined: Thu Feb 26, 2009 7:38 pm
Location: Argentina - Quilmes

GRIDSETORDER()

Post by AdrianSB »

Hola a todos!!

Como no pude encontrar una función con la lógica de DBSETORDER() que pueda ser incluida en la definición de un control GRID, generé una muy básica que es de utilidad para usos comunes.

Me gustaría saber si existen funciones de este tipo ya que preferiría utilizar las del lenguaje para asegurar compatibilidad y rendimiento :?: . De no ser así, me gustaría que evalúen la posibilidad de su inclusión en la HFCL (Hmg Forum Component Library), con las mejoras que ustedes crean convenientes.

Les hago llegar un ejemplo de su uso:

En el cógido de ejemplo SAMPLES\GRID_7 incluido en la distribución Harbour MiniGUI 2.0.020 (2006.06.27) efectué los siguientes cambios:

01) En la definición del control GRID incluí los llamados a la función GRIDSETORDER() de la siguiente manera

ONHEADCLICK { {||GRIDSETORDER(1)},{||GRIDSETORDER(2)},{||GRIDSETORDER(3)} }

02) Al final del archivo incluí la referencia a la librería que contiene la función GRIDSETORDER()

#Include "setord.prg"

Saludos!!

GOOGLE TRANSLATION

Hello everybody!

As I could not find a function with the logic of DBSETORDER () that can be included in the definition of a grid control, it generates a very basic which is useful for common uses.

I wonder if there are features of this type and would prefer to use the language to ensure compatibility and performance::. If not, I would like to evaluate the possibility of inclusion in the HFCL (HMG Forum Component Library), with the improvements you see fit.

I extend an example of its use:

In the sample taken SAMPLES \ GRID_7 included in the distribution Harbor Mini 2.0.020 (2006.06.27) make the following changes:

01) In the definition of control contained the GRID function call GRIDSETORDER () as follows

ONHEADCLICK ((| | GRIDSETORDER (1 )},{|| GRIDSETORDER (2 )},{|| GRIDSETORDER (3)))

02) At the end of the file included the reference to the library that contains the function GRIDSETORDER ()

# Include "setord.prg"

Greetings!
Attachments
GRIDSETORDER.ZIP
(2.93 KiB) Downloaded 846 times
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: GRIDSETORDER()

Post by Rathinagiri »

Thanks a lot AdrianSB.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
User avatar
esgici
Posts: 4543
Joined: Wed Jul 30, 2008 9:17 pm
DBs Used: DBF
Location: iskenderun / Turkiye
Contact:

Re: GRIDSETORDER()

Post by esgici »

Hi Adrian

Good work, thanks for sharing :)

Regards

--

Esgici
Viva INTERNATIONAL HMG :D
User avatar
AdrianSB
Posts: 17
Joined: Thu Feb 26, 2009 7:38 pm
Location: Argentina - Quilmes

Re: GRIDSETORDER()

Post by AdrianSB »

Hola rathinagiri !! Hola Esgici !!

Gracias por sus respuestas

Incorporé la validación de tipos de dato pero aún faltan otras cosas. De todas formas creo que puede ser de utilidad ya que con ese método se logra el reordenamiento concatenado de todas las colmnas ( COL1+COL2+COL3+COLn :!: ).

La lógica de la función se basa en generar una cadena con separadores de campo a partir de cada item del GRID y almacenarlas en elementos de un único array. Luego de hacer un ordenamiento con aSort() se recuperan los valores y sus tipo para la actualización del GRID.

Al colocar el campo de la columna seleccionada en primer lugar y luego concatenar el resto de los campos según el orden en que fueron definidos, se logra el efecto de múltiple ordenamiento de las columnas :!: .

Para finalizar la función, necesitaría que alguien me indique ¿ Cómo obtener el SET DATE FORMAT activo ? o mejor que ello, ¿ Una función nativa que recupere una fecha desde una cadena dTos() "AAAAMMDD" ?

Les hago llegar un nuevo ejemplo del uso de la función para uncaso de campos de diferentes tipos de datos:

En el cógido de ejemplo SAMPLES\GRID_15 incluido en la distribución Harbour MiniGUI 2.0.020 (2006.06.27) efectué los siguientes cambios:

01) Al inicio de la función main()

SET DATE TO BRITISH ( por ahora obligatorio )

02) En la definición del control GRID incluí los llamados a la función GRIDSETORDER() de la siguiente manera

ON HEADCLICK { {||GRIDSETORDER(1)},{||GRIDSETORDER(2)}, ;
{||GRIDSETORDER(3)},{||GRIDSETORDER(4)}, ;
{||GRIDSETORDER(5)} } ;

03) Al final del archivo incluí la referencia a la librería que contiene la función GRIDSETORDER()

#Include "setord.prg"

Saludos!!

GOOGLE TRANSLATION

Rathinagiri Hello! Esgici Hello!

Thanks for your answers

Joined the validation of data types, but still missing other things. Anyway I think that may be useful as this method is achieved with the rearrangement of all concatenated colmnas (col1 + col2 + col3 + Colne::).

The logic of the function is based on generating a string with field separators from each item of the grid and store items in a single array. After making an order with asort () values are recovered and their rate for updating the grid.

By placing the field of the selected column first, then concatenate the remainder of the fields in the order in which they were defined, it achieves the effect of multiple sorting columns:!:.

To end the function, need someone to tell me How to get the SET DATE FORMAT active? or better than this, a native function to retrieve a date from a string dTos () "YYYYMMDD"?

I extend a further example of the role of Uncas in fields of different types of data:

In the sample taken SAMPLES \ GRID_15 included in the distribution Harbor Mini 2.0.020 (2006.06.27) make the following changes:

01) At the beginning of the function main ()

SET DATE TO BRITISH (now mandatory)

02) In the definition of control contained the GRID function call GRIDSETORDER () as follows

ON HEADCLICK ((| | GRIDSETORDER (1 )},{|| GRIDSETORDER (2));
(| | GRIDSETORDER (3 )},{|| GRIDSETORDER (4));
(| | GRIDSETORDER (5)));

03) At the end of the file included the reference to the library that contains the function GRIDSETORDER ()

# Include "setord.prg"

Greetings!
Attachments
GRIDSETORDER2.ZIP
(3.44 KiB) Downloaded 623 times
User avatar
luisvasquezcl
Posts: 1258
Joined: Thu Jul 31, 2008 3:23 am
Location: Chile
Contact:

Re: GRIDSETORDER()

Post by luisvasquezcl »

Gracias Adrian,
muy buen aporte y muy útil además.
Saludos
Luis Vasquez.
User avatar
Vanguarda
Posts: 543
Joined: Wed Feb 11, 2009 10:56 am
Location: Americana - SP
Contact:

Re: GRIDSETORDER()

Post by Vanguarda »

hi friend AdrianSB,

i think this function is very nice and usefull.

Thanks a lot for sharing with us.

with best regards,
--
Paulo Sérgio Durço (Vanguarda)


http://hmglights.wordpress.com/
User avatar
fchirico
Posts: 324
Joined: Sat Aug 23, 2008 11:27 pm
Location: Argentina

Re: GRIDSETORDER()

Post by fchirico »

AdrianSB wrote:Hola rathinagiri !! Hola Esgici !!

{||GRIDSETORDER(3)},{||GRIDSETORDER(4)}, ;
{||GRIDSETORDER(5)} } ;

Saludos!!
Gracias Adria!

Seguramente la estemos usando.

Saludos, Fernando Chirico.
Saludos, Fernando Chirico.
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: GRIDSETORDER()

Post by Rathinagiri »

Hi,

To include this very much useful function in HFCL, please give a help/doc for this feature.

Thanks a lot.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
User avatar
AdrianSB
Posts: 17
Joined: Thu Feb 26, 2009 7:38 pm
Location: Argentina - Quilmes

Re: GRIDSETORDER()

Post by AdrianSB »

Hola Luis !!, Hola Paulo !!, Hola Fernando !!

Gracias por sus opiniones. Estoy felíz de poder aportar algo que sea de utilidad para todos !!

Las funciones que publiqué son pruebas preliminares QUE NO DEBEN SER INCLUIDAS EN SUS PROYECTOS. ( LA PRIMERA SOLO PROCESA CAMPOS TIPO TEXTO Y LA SEGUNDA SOLO PROCESA CAMPOS QUE NO SON TIPO TEXTO )

Les hago llegar una nueva versión de la función que, en este caso, sí pueden evaluar en sus proyectos. Esta versión procesa todos los tipos de datos e incluso interpreta datos de tipo caracter en formato fecha. ( Ej: "20/05/09"(C) es procesado de igual forma que 20/05/09(D) )
Simplifiqué la lógica del procesamiento disminuyendo a la mitad el tiempo de proceso por la eliminación de la doble conversión de datos. Ahora sólo se convierten los datos para la generación del array de contenidos a ordenar, mientras que los datos ordenados son recuperados de un array temporal con los datos originales del GRID. Esto fue posible por la integración del número de item dentro del contenido a ordenar.

Las limitaciones de esta versión son:

01) NO DEBE SER UN VIRTUAL GRID ( Se produce un error de ejecución ya que no sé como validar si un GRID es VIRTUAL :cry: )
02) TODAS LAS COLUMNAS DEL GRID DEBEN SER DEL TIPO "C/D/N/L" ( de no ser así, el proceso no se ejecuta ya que no tengo mas ganas de trabajar :x )
03) EL FORMATO DE DATOS DEL TIPO FECHA DEBE SER "BRITISH/FRENCH/JAPAN/AMERICAN" ( de no ser así, las columnas de tipo caracter que posean formato de fecha serán procesadas sin conversión de tipo y quedarán mal ordenadas ya que nunca aprendí a obtener los valores de las variables de entorno de Clipper :oops: )
04) DEBE SER EVALUADO EL RENDIMIENTO DEL PROCESO EN CADA TIPO DE INTERFAZ EN LA QUE SERA UTILIZADO ( Al aumentar la cantidad de registros, cae brutamente!! :o ) SI TRABAJAN CON MUCHOS REGISTROS PODRIAN UTILIZAR UN BROWSE CON INDICES SOBRE LA TABLA DE ORIGEN ¿ NO ? :roll:
05) LA FUNCION CONCATENA TODOS LOS CAMPOS DEL GRID Y NO ES POSIBLE PERSONALIZAR LOS CRITERIOS DE ORDENAMIENTO ( Pero estoy trabajando en la función GRIDCREATEINDEX() ) ;)
06) DEBEN DEPOSITAR EN MI CUENTA BANCARIA UN ABONO DIARIO POR SU USO :lol:

Respecto de esta actualización y de las futuras, quisiera comentarles que van ser efectuadas en archivos separados para independizar las funciones relacionadas con procesos de ordenamiento de contenidos del control GRID ( grid_ord.prg ), de las funciones complementarias utilizables en procesamiento de cadenas ( str_func.prg ). De esta forma intento separar las capas INTERFAZ<->PROCESOS<->PERSISTENCIA para facilitar el análisis de la posible inclusión de las diferentes funciones en las HFCL.

Saludos !!

GOOGLE TRANSLATION

Hola Luis!, Paulo Hello!, Hola Fernando!

Thanks for your opinions. I am happy to contribute something useful for everyone!

The functions that are published preliminary evidence that should not be included in their projects. (FIRST SOLO PROCESA FIELDS AND SECOND TYPE TEXT ONLY PROCESA AREAS THAT ARE NOT TYPE TEXT)

I extend a new version of the function, in this case, they can evaluate their projects. This version processes all types of data and interpretation of data type character in a date. (Eg "20/05/09" (C) is processed similarly to 20/05/09 (D))
Simplify the logic of processing halved the processing time by eliminating double data conversion. Now only becomes data for generating the array of content to sort, while the sorted data are retrieved from a temporary array with the original data of the GRID. This was possible by integrating the number of items within the content to order.

The limitations of this version are:

01) DO NOT BE A VIRTUAL GRID (An error occurs executing and do not know how to validate if it is a VIRTUAL GRID :cry: )
02) ALL COLUMNS SHOULD BE THE GRID TYPE "C / D / N / L" (if not, the process is not running because I have no more desire to work :x )
03) FORMAT OF DATA TYPE DATE TO BE 'BRITISH / FRENCH / JAPAN / AMERICAN "(if not, the columns of type character having date format will be processed without conversion rate and are poorly ordered and never learned to obtain the values of environment variables Clipper :oops: )
04) must be evaluated processor performance in each type of interface which will be used (by increasing the amount of records, crude falls!: O) If you are working with many rows could use a browser with INDICES ON THE TABLE OF ORIGIN No? :roll:
05) THE ROLE Concatenate all the fields in the grid and you can not customize the order criteria (But I'm working on the role GRIDCREATEINDEX ()) ;)
06) must be deposited in my bank account credited daily use :lol:

Regarding this update and future, I would mention that will be performed in separate files for independent functions related to content management processes control GRID (grid_ord.prg) of the functions used in string processing (str_func. prg). In this way attempt to separate the layers INTERFACE -> process <-> persistent to facilitate analysis of the possible inclusion of the various functions in HFCL.

Greetings!
Attachments
GRIDSETORDER3.zip
(4.28 KiB) Downloaded 642 times
User avatar
AdrianSB
Posts: 17
Joined: Thu Feb 26, 2009 7:38 pm
Location: Argentina - Quilmes

Re: GRIDSETORDER()

Post by AdrianSB »

Hola rathinagiri !

Gracias por tu interes !!

Antes de avanzar en la posible inclusión de las funciones en la HFCL quisiera comentarte que deseo finalizar los temas pendientes de la función GRIDSETORDER() y hacerles llegar mi propuesta sobre la posible implementación de las funciones GRIDCREATEINDEX() y GRIDSETINDEX() para permitir la personalización de los criterios de ordenamiento y la utilización de indices adicionales a los visuaizados en el control GRID.

Respecto de los temas pendientes en la función GRIDSETORDER(), necesitaría saber:

01) ¿ Cómo se valida si un GRID es VIRTUAL ?
02) ¿ Cómo se obtiene el SET DATE FORMAT activo ?

Respecto de la implementación de las funciones GRIDCREATEINDEX() y GRIDSETINDEX(), mi idea es la siguiente:

La función GRIDCREATEINDEX() recibirá los mismos parámetros establecidos para DBCREATEINDEX() con el agregado de un nuevo parámetro que permita pasar un array de referencias de nombres y claves para su acceso público, mientras que la función GRIDSETINDEX() recibirá el mismo parámetro que DBSETINDEX():

//////////////////////////////////////////////////

Public aGrid1 := {"oGrid1"} // Array público asociado al GRID1
Public aGrid2 := {"oGrid2"} // Array público asociado al GRID2

...
DEFINE GRID oGrid1
...
HEADERS {"Fecha","Factura","Producto","Cantidad","Unidad","Precio unitario"}
ONHEADCLICK { {||GRIDSETORDER(1)},{||GRIDSETORDER(2)}, ;
{||GRIDSETORDER(3)},{||GRIDSETORDER(4)}, ;
NIL,{||GRIDSETORDER(5)} }
...
END GRID
...
DEFINE BUTTON oBtnProceso
...
ACTION ( PROCESO())
...
END BUTTON

...
FUNCTION INICIAR_INDICES()

GRIDCREATEINDEX("Fecha","1+2+3",.F.,@aGrid1) // Indice 1
GRIDCREATEINDEX("Factura","2+3",.F.,@aGrid1) // Indice 2
GRIDCREATEINDEX("Producto","3+1",.F.,@aGrid1) // Indice 3
GRIDCREATEINDEX("Cantidad","4+1+2",.F.,@aGrid1) // Indice 4
GRIDCREATEINDEX("Precio unitario","5+1+2+3+4",.F.,@aGrid1) // Indice 5
GRIDCREATEINDEX("PROCESO1","2+",.F.,@aGrid1) // Indice 6 usado para un proceso asociado

RETURN()
...

FUNCTION PROCESO()
...

GRIDSETINDEX("PROCESO1")
...
RETURN(.T.)

//////////////////////////////////////////////////

Saludos !!

GOOGLE TRANSLATION

Rathinagiri Hello!

Thanks for your interest!

Before moving into the possible inclusion of HFCL the functions comentarte that I would like to finalize the outstanding issues of the role GRIDSETORDER () and getting my proposal on the possible implementation of the functions GRIDCREATEINDEX () and GRIDSETINDEX () to allow customization the criteria of organization and use of additional indicators to visuaizados in the GRID control.

Outstanding issues regarding the role GRIDSETORDER (), need to know:

01) How is valid if it is a VIRTUAL GRID?
02) How is the SET DATE FORMAT active?

Regarding the implementation of the functions GRIDCREATEINDEX () and GRIDSETINDEX (), my idea is this:

GRIDCREATEINDEX function () receive the same parameters set for DBCREATEINDEX () by adding a new parameter to move an array of references to names and passwords for access, whereas the role GRIDSETINDEX () receive the same parameter DBSETINDEX ():

//////////////////////////////////////////////////

Public aGrid1: = ( "oGrid1") / / Array GRID1 associated with the public
Public aGrid2: = ( "oGrid2") / / public Array associated GRID2

...
DEFINE GRID oGrid1
...
HEADERS ( "Date", "Bill," "Product", "Amount", "Unit", "Unit Price")
ONHEADCLICK ((| | GRIDSETORDER (1 )},{|| GRIDSETORDER (2));
(| | GRIDSETORDER (3 )},{|| GRIDSETORDER (4));
NIL, (| | GRIDSETORDER (5)))
...
END GRID
...
DEFINE BUTTON oBtnProceso
...
ACTION (Process ())
...
END BUTTON

...
FUNCTION INICIAR_INDICES ()

GRIDCREATEINDEX ( "Date", "1 +2 +3". F., @ aGrid1) / / Index 1
GRIDCREATEINDEX ( "Bill", "2 +3". F., @ aGrid1) / / Index 2
GRIDCREATEINDEX ( "Product", "3 +1". F., @ aGrid1) / / Index 3
GRIDCREATEINDEX ( "Quantity", "4 +1 +2". F., @ aGrid1) / / Index 4
GRIDCREATEINDEX ( "Unit Price", "5 +1 +2 +3 +4". F., @ aGrid1) / / Index 5
GRIDCREATEINDEX (PROCESO1 "," 2 + ". F., @ aGrid1) / / 6 index used for a process associated

RETURN ()
...

FUNCTION PROCESS ()
...

GRIDSETINDEX (PROCESO1)
...
RETURN (. T.)

//////////////////////////////////////////////////

Greetings!
Post Reply