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
)
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
)
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
)
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!!
) SI TRABAJAN CON MUCHOS REGISTROS PODRIAN UTILIZAR UN BROWSE CON INDICES SOBRE LA TABLA DE ORIGEN ¿ NO ?
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
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
)
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
)
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
)
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?
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
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!
. 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.
). 
