FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Ayuda para mejorar la clase TghXMLDoc
En el sistema operativo Windows existe una API conocida como MSXML, la cual ofrece un rico conjunto de interfaces COM con las cuales podemos leer, escribir y manejar archivos XML evitándonos complicaciones de análisis sintáctico. Aprovechando esta circunstancia, hace más de un año comencé el desarrollo de una modesta clase de nombre TghXMLDoc (el infijo "gh" por ser parte de GH Freebrary), cuyo propósito es facilitar el uso de MSXML desde Delphi. Cabe mencionar que de esta clase derivé algunas otras, más específicas, relacionadas con el manejo de hojas de cálculo Excel (pues internamente también son archivos .xml). Y pretendo que esta clase sea la base para cualquier otra relacionada con documentos XML (para LibreOffice, por ejemplo) que haya que crear en el futuro dentro de la biblioteca.
La finalidad del tema que ahora abro es captar propuestas de mejoras o ampliaciones de esta clase base, y que entre los interesados ayudemos en el análisis y desarrollo de tales modificaciones. No está de más recordar que para formarnos una opinión sólida de lo ya hecho, primero conviene descargarla (disponible para Delphi 7 y pronto para XE2) y al menos haber examinado un poco su código fuente. Expongo la primera inquietud de mejora. El actual constructor de la clase está así: Podría extenderme explicando cada línea y quizá lo haga luego, pero ahora me gustaría hacer notar sólo lo que realiza la primera sentencia. Content es un campo o miembro de la clase y su tipo es OLEVariant. Como puede verse, en ese campo guardamos la interfaz de un objeto COM creado mediante la función nativa CreateOLEObject. Tendrán presente que a esta función debemos darle el nombre o ProgID que identifique la clase de objeto COM que deseamos crear. El ProgID MSXML2.DOMDocument.4.0 corresponde al objeto principal de MSXML, el que representa a un documento XML entero. Así es como la clase Delphi TghXMLDoc viene a encapsular un único documento XML a través de la interfaz asignada a Content. En la parte final del ProgID aparece "4.0", y eso es lo que me interesa abordar con ustedes. Significa que, invariablemente, la actual implementación de TghXMLDoc requiere que la versión 4.0 de MSXML se encuentre presente en el sistema operativo, con sus debidos asientos en el Registro de Windows. Confieso que esa parte del código nunca me convenció del todo. ¿Por qué elegí específicamente la versión 4.0 de MSXML? La verdad no lo recuerdo, creo que bebí algunas cervezas ese día. Según la hoja de ruta de la API, resulta que la versión 4.0 no viene "de cajón" en Windows, sino que se instala con algunos otros productos. Y aunque es rara la vez que no está presente y muy fácil instalarla con esta actualización, creo que TghXMLDoc debería poder aprovechar alguna otra de las versiones disponibles en el equipo, sin que el programador o el usuario tenga que actualizar nada. Lo que propongo es que la clase no esté "casada" con esa versión en concreto, sino que sea flexible y pueda utilizar alguna otra versión de MSXML vigente. La pregunta del millón es ¿cuál es la mejor estrategia? Lo primero que se me ocurrió fue que podría agregarle algún parámetro (en el constructor) o propiedad para indicar la versión de MSXML con la cual debe trabajar. Pero luego pensé que el constructor de la clase podría examinar el Registro de Windows para determinar qué versiones hay instaladas y elegir el ProgID más apropiado ("MSXML2.DOMDocument.6.0", "MSXML2.DOMDocument.4.0",...). OK, ¿y si el programador quiere que se use uno en particular? (suponiendo que haya razones válidas para ello). Por otra parte, ¿es eficiente que el constructor busque en el Registro cada vez que creemos una instancia de TghXMLDoc? ¿no sería mejor hacer una única búsqueda y guardar el resultado en una variable global/de clase? Y haciéndolo así, ¿no importaría que la aplicación ignorase la instalación de alguna versión de MSXML ocurrida después de haber creado ya el primer objeto TghXMLDoc y antes de crear otros más? ¿Qué problemas de incompatibilidad tendría la clase si le permitimos trabajar con diferentes versiones de MSXML? ¿qué previsiones tendríamos que tomar? Sí leemos la tabla MSXML Releases de la hoja de ruta que mencioné antes, podríamos decir que actualmente sólo hay tres versiones estándares y vigentes que valdría la pena considerar: la 3.0, la 4.0 y la 6.0. Y quizá la preferencia debería ser de mayor a menor, pero Microsoft dice (cito parte de esa tabla): When MSXML 6.0 is not available MSXML 3.0 is generally the best fallback version. [Cuando MSXML 6.0 no está disponible, MSXML 3.0 es generalmente la versión anterior más adecuada]. Bueno, creo que habrán entendido el tipo de interrogantes que se presentan para mejorar esa parte tan importante de la clase. Les solicito algo de ayuda para flexibilizarla y que use la versión de MSXML que se tenga instalada (o la que el programador indique), y no forzosamente la 4.0. Ideas, código, seudocódigo, pros y contras...toda colaboración será bienvenida. De antemano, gracias. Al González. Última edición por Al González fecha: 30-10-2013 a las 10:06:15. |
#2
|
||||
|
||||
Hola Alberto.
No puedo darte una opinión sobre que cuál ProgID es el más apropiado para que aplique tu clase por desconozco los alcances que deseas darle y las prestaciones que te ofrece cada versión para las mismas. Pero, por si te sirviera de algo, te puedo dar una alternativa para obtener las versiones instaladas sin tener que recurrir al registro para obtenerlas. Hice dos funciones, la primera devuelve las versiones instaladas y la segunda la versión mayor de ellas. Espero que te aporten algún beneficio o al menos te den alguna pauta para seguir, mientras tanto seguiré pensando en "la pregunta del millón". Saludos
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
#3
|
||||
|
||||
Qué tal, ecfisa. Me agrada que te hayas sumado a esta pesquisa.
Después de estudiar un poco más el problema, veo que conviene olvidarnos de CreateOLEObject y los ProgIDs. Verás, cuando ejecutamos la función CreateOLEObject de Delphi, estamos llamando indirectamente la función CLSIDFromProgID de la API de Windows, que como ya has visto sirve para convertir un ProgID en su respectivo GUID de clase COM (CLSID). Según la referencia técnica ésta función busca en el registro de Windows ("Looks up a CLSID in the registry, given a ProgID"), aunque seguramente es una búsqueda más eficiente que la que podríamos hacer con las funciones y clases que normalmente se usan para leer y escribir entradas del registro. ProgIDToClassID es una envoltura Delphi de la función CLSIDFromProgID, y CreateOLEObject la usa para obtener el CLSID con el cual llamar a CoCreateInstance, la función de la API de Windows para crear una instancia de objeto COM: Ahora, si examinamos cómo trabaja predeterminadamente el componente nativo TXMLDocument (del cual no quise derivar a TghXMLDoc por razones de diseño), podemos ver que éste llama a CoCreateInstance sin pasar por CreateOLEObject o ProgIDToClassID, y además hace algo como lo que aquí pretendemos: intentar la creación del objeto con diferentes versiones de MSXML: El secreto es que Delphi declara esas constantes TGUID, que son en sí las CLSIDs que Microsoft asignó a las distintas versiones del objeto DOMDocument de MSXML. Las CLSIDs son fijas y por tanto no necesitamos obtenerlas buscando ProgIDs en el registro de Windows, sólo conocer cuál es su valor GUID y usar éste para llamar a CoCreateInstance. Aun así podríamos buscar cada GUID en el registro antes de crear el objeto COM, pero esto no tendría mayor beneficio que intentarlo directamente, más o menos como esas funciones CreateDOMDocument y TryObjectCreate. Esto comienza a allanar el camino. Podríamos decir que no vale la pena consultar el registro para convertir ProgIDs a CLSIDs que ya conocemos, y que TghXMLDoc debería llamar a CoCreateInstance intentando con diferentes CLSIDs. Pero todavía hay que resolver la cuestión de cuál es la mejor estrategia considerando, por ejemplo, cómo permitirle al programador indicar qué versión de MSXML debe utilizar nuestra clase o en qué orden de preferencia. En las constantes que Delphi declara no hay una de nombre CLASS_DOMDocument50, y eso es porque la versión 5.0 de MSXML sólo puede instalarse con Microsoft Office, es decir, no es formalmente estándar en Windows. Sin embargo podría ser utilizada también en equipos que tengan ese paquete instalado. Entre sus características exclusivas, destaca por ejemplo la capacidad de hacer firma digital sobre los archivos XML, algo que por alguna razón Microsoft retiró en la versión 6. Habiendo hecho este breve análisis, propongo que TghXMLDoc intente crear el objeto COM usando, predeterminadamente, sólo las CLSIDs CLASS_DOMDocument60, CLASS_DOMDocument40 y CLASS_DOMDocument30, en ese orden de preferencia. En esta lista predeterminada no tendría sentido contemplar versiones anteriores a la 3.0 por estar ya obsoletas. Pero sí tendrá sentido que un programador pueda indicar una versión en particular de modo expreso, cambiar el orden de preferencia o establecer su propia lista de CLSIDs. ¿Qué usar entonces? a) parámetro(s) adicional(es) en el constructor b) método virtual "GetCOMInstance" llamado por el constructor c) método función virtual "COMCLSIDs" que regrese una matriz (array) de TGUIDs d) una variable matriz global que pueda ser modificada por el programador e) esa matriz pero como campo o propiedad de clase (no soportada en Delphi 7) f) una combinación de los anteriores g) otro mecanismo Agradezco de antemano las ideas que puedan seguir aportando. Un saludo. |
#4
|
||||
|
||||
Esta semana continuaré con el tema.
Cita:
|
#5
|
||||
|
||||
Solución "candidata"
Hola amigos.
Creo que ha valido la pena el trabajo de investigación y desarrollo que realicé durante las últimas semanas. He resuelto el asunto de los identificadores de clases COM (CLSIDs) para que TghXMLDoc ya no dependa particularmente de MSXML 4.0, sino que ahora pueda usar cualquiera de las versiones vigentes de esa API que tenga el equipo donde corra la aplicación. Se descarta definitivamente (o casi) el uso de ProgIDs, ya que no es eficiente ni elegante consultar el Registro para obtener identificadores de clases que son fijos y del dominio público. En el camino y por seguir la sana práctica de separar el código en pequeños elementos de utilidad general, escribí varias funciones y constantes que, como si fueran átomos, ayudan a formar la molécula TghXMLDoc. En mis siguientes mensajes trataré de explicar estos cambios, pero de antemano solicito "beta testers" para esta versión candidata. Es el archivo GHFreebrary_Delphi7_20140103RC.zip del repositorio. Aunque ya realicé diversas pruebas, me gustaría someterlo al visto bueno de ustedes. Espero sus comentarios. Un saludo. Al. Última edición por Al González fecha: 05-01-2014 a las 03:39:29. |
#6
|
||||
|
||||
Gracias por compartir tanto trabajo
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#7
|
||||
|
||||
Cita:
Primero los átomos agregados al núcleo de la biblioteca (unidad GHFRTL.pas), empezando por las nuevas constantes: ghchDotDecimals es una constante conjunto que agrupa a los 10 dígitos decimales y el punto. Es común encontrar cadenas o subcadenas formadas por una combinación de estos 11 caracteres, como es el caso de las versiones de un producto (14.8.01), visto también en el sufijo de un ProgID (ADODB.Command.2.8, Msxml2.DOMDocument.6.0). En el presente caso es utilizada por la función ghRightDigitsDots que aparece más abajo. ghEmptyPWideChr es una constante PWideChar que indica una cadena vacía. Resulta útil para darse en lugar de Nil cuando alguna rutina espera una cadena de caracteres WideChar terminada en nulo, aunque esté vacía pero que no sea un puntero en blanco. En el presente caso es usada por la función ghPWideChr que aparece más abajo. Las constantes ghciMSXMLDocNN contienen los identificadores de clases COM (CLSIDs) que Microsoft asignó al objeto DOMDocument de MSXML 3.0, 4.0, 5.0 y 6.0. Observen que estos identificadores son GUIDs (del tipo TGUID en Delphi) que se expresan como si fueran cadenas de 38 caracteres, pero el compilador realmente los toma como valores de 16 bytes. ghMSXMLDocClassIDs es una matriz (array) unidimensional que contiene esos mismos identificadores de clases. Noten que debí poner nuevamente los cuatro valores GUIDs, toda vez que el compilador de Delphi no admite referencias a constantes tipificadas dentro de la definición de otras constantes. ghMSXMLSchemaCacheClassIDs es una matriz que lleva relación con la anterior, pero esta contiene los identificadores de clases para el objeto XMLSchemaCache, el cual se utiliza en MSXML para validar documentos contra esquemas XSD. Es importante anotar que la mencionada API no admite combinar objetos DOMDocument y XMLSchemaCache de diferentes versiones, y que TghXMLDoc previene eso mismo en su método AddSchema mostrado más abajo. ghMSXMLVersions es una matriz relacionada con las anteriores dos, pero en lugar de GUIDs almacena los cuatro números de versión como simples cadenas de caracteres. La finalidad de esta matriz es permitir conocer la versión de cualquiera de los GUIDs anteriores sin tener que consultar el registro de Windows. Ahora pasemos a las funciones átomo, también agregadas a GHFRTL.pas: En Delphi 7 todavía no era posible comparar dos valores TGUID usando el operador "=", y por muchos años la recomendación fue usar la función IsEqualGUID importada de OLE32.dll. Pero me surgió la pregunta: ¿qué tan eficiente será hacer una simple comparación de 16 bytes con IsEqualGUID? Por otra parte, encontré que las versiones recientes de Delphi sí admiten la comparación de TGUIDs con el operador "=". Cuando eso ocurre, el compilador inserta una llamada al método interno TGUID.Equal: El cual es de cuatro a cinco veces más rápido que IsEqualGUID. Así que buscando algo similar para Delphi 7 creé esa función ghEquals, y para mi sorpresa resultó ligeramente más eficiente que el método TGUID.Equal (en Delphi 7 genera un poco menos de código máquina y en XE2 conviene añadirle la directiva InLine). En GHF hay varias funciones para buscar un elemento dentro de una matriz unidimensional. Es el caso de ghPosGUID, la cual nos dice en qué posición (a partir de 0) de una matriz de GUIDs se encuentra un GUID en particular. Si devuelve -1 significa que ID no se encuentra en la matriz Values. Noten que ghPosGUID llama a ghEquals. ghValidGUIDs llama a ghPosGUID con cada uno de los elementos de una matriz de GUIDs (Values) para verificar que todos ellos se encuentren incluidos en otra matriz de GUIDs (IDs). Devuelve True si se cumple la validación, o False si alguno de los elementos de Values no está en IDs. ghCheckMSXMLDocClassIDs usa la función ghValidGUIDs para verificar que todos los GUIDs dados (parámetro Values) sean identificadores de clases MSXML DOMDocument (la constante matriz ghMSXMLDocClassIDs mostrada con anterioridad). En caso de que alguno de los elementos de la matriz Values no se encuentre en la matriz ghMSXMLDocClassIDs, eleva una excepción con el procedimiento ghRaise. Espero no se hayan cansado de leer, falta un poco más. ghCreateCOMObj se encarga de crear una instancia de objeto COM. Es una simple envoltura de la función estándar CoCreateInstance que nos ahorra escribir el segundo y tercer parámetro de ésta última, los cuales por lo general son "Nil" y "ClsCtx_InProc_Server Or ClsCtx_Local_Server". ghSetGUID es una de esas funciones que los puristas odian por ser una especie de "If envuelto", pero que con el advenimiento de la compilación in-line se vuelven importantes para la simplificación del código fuente de las rutinas llamadoras. Recibe un puntero a TGUID (Ref) y un TGUID (Value), y si la referencia es válida le asigna éste. Haciendo uso de ghCreateCOMObj y ghSetGUID, ghCOMObj recibe una lista (matriz ClassIDs) de identificadores de clases COM e intenta crear una instancia de objeto con el primero de esos identificadores. Si no lo consigue (seguramente por no encontrarse instalada esa CLSID), entonces intenta con el segundo, y así sucesivamente, hasta lograr crear el objeto COM, el cual es regresado como resultado en forma de interfaz. Si el parámetro UsedClassID no es una referencia Nil, pone en ella el valor del GUID que tuvo éxito, es decir, la CLSID con la que finalmente se consiguió crear la instancia COM. Si no han perdido detalle de lo tratado en este hilo, lograrán adivinar que esta función es la clave para permitirle a TghXMLDoc trabajar con cualquiera de las versiones de MSXML que se tengan instaladas. ghCOMDispatch es una envoltura de la función ghCOMObj, cuya finalidad es indicarle a CoCreateInstance que deseamos una interfaz IDispatch y obtener ese IDispatch como resultado en lugar de una interfaz genérica IUnknown. Esto es importante para lograr acceso práctico a todas las propiedades y métodos de instancias COM mediante variables OLEVariant. Hagamos una pausa para comer... |
#8
|
||||
|
||||
ghPWideChr es una función para convertir una cadena normal a una cadena de caracteres WideChar terminada en nulo. Eso mismo puede conseguirse con una expresión como "PWideChar (WideString (Cadena))" pero es más concisa (tanto en código fuente como en código máquina) una expresión "ghPWideChr (Cadena)". ghGetClassID envuelve a la función CLSIDFromProgID del sistema operativo, haciendo por nosotros la conversión del ProgID de tipo String a PWideChar (usando la función ghPWideChr). Obtiene el identificador de clase que corresponde a un ProgID dado. ghGetProgID es la función inversa a ghGetClassID. Dado un identificador de clase (parámetro ClassID) obtiene el ProgID que le corresponde mediante la función ProgIDFromCLSID del sistema operativo. ghProgID envuelve a ghGetProgID con el propósito de que el resultado de la función sea el ProgID obtenido en lugar de un valor de estado. Si el CLSID dado no está en el Registro, el resultado será una cadena vacía (en virtud de que la variable Result es usada como parámetro Out para ghGetProgID). La función ghRightDigitsDots toma una cadena de caracteres y regresa la subcadena que en su extremo derecho se componga de dígitos decimales y puntos (dando 'MSXML2.DOMDocument.4.0' devuelve '.4.0'). La función ghRightVersion, toma una cadena de caracteres y regresa la subcadena que en su extremo derecho se componga de dígitos decimales y puntos (para ello llama a ghRightDigitsDots), pero descarta el primer carácter de la subcadena en caso de ser un punto para que ésta siempre comience con número (dando 'MSXML2.DOMDocument.4.0' devuelve '4.0'). ghProgIDVersion es una función que combina a ghProgID con ghRightVersion. Sirve para obtener la versión de un identificador de clase COM (parámetro ClassID) con base al ProgID que ese identificador tenga asociado en el registro de Windows. ghClassID envuelve a ghGetClassID con el propósito de que el resultado de la función sea el identificador de clase obtenido en lugar de un valor de estado. Si el ProgID dado no está en el Registro, el resultado será un GUID en blanco (con todos sus bytes en cero). Esta sobrecarga de ghClassID permite indicar un sufijo de versión para el ProgID dado. Si se da 'MSXML2.DOMDocument' y '6.0', se buscará el CLSID de 'MSXML2.DOMDocument.6.0'. Si se da 'MSXML2.DOMDocument' y '' (cadena vacía en el parámetro Version), se buscará el CLSID de 'MSXML2.DOMDocument'. Esto resulta útil dado que muchos ProgIDs pueden o no pueden tener un sufijo de versión. Esta otra sobrecarga de ghClassID es muy similar a la anterior, salvo que la cadena de versión se obtiene de un identificador de clase ya conocido (parámetro VersionID). Es decir, esta función obtiene el CLSID que corresponde a un ProgID cuya versión es igual a la del ProgID de otro CLSID. El actual código de TghXMLDoc no necesita llamar a esta sobrecarga, pero es probable que resulte útil a quienes deseen acceder a más objetos de MSXML (además de DOMDocument y XMLSchemaCache). La función ghMSXMLSchemaCacheClassID sirve para obtener el identificador de clase COM del objeto XMLSchemaCache de MSXML según la versión de otro identificador de clase COM (parámetro VersionID). El uso típico es darle uno de los CLSIDs de DOMDocument para obtener el correspondiente CLSID de XMLSchemaCache. La función llama a ghPosGUID para determinar si VersionID está en la constante matriz ghMSXMLDocClassIDs, en cuyo caso devuelve el GUID contenido en la misma posición de la constante matriz ghMSXMLSchemaCacheClassIDs. Observen que como último recurso se apoya en la función ghClassID descrita anteriormente. Usando TghXMLDoc no entrará a ese Else, a menos que el programador fuerce a la clase a usar una versión de MSXML que no sea vigente. ghMSXMLSchemaCache combina una llamada a ghMSXMLSchemaCacheClassID con una llamada a ghCOMDispatch. Con ello crea una instancia de objeto XMLSchemaCache de la misma versión de MSXML que el CLSID indicado (parámetro VersionClassID). El método TghXMLDoc.AddSchema (mostrado más abajo) llama directamente a esta función cuando se agrega el primer esquema de validación. ghMSXMLVersion es la última de las funciones sueltas que escribí en esta fase de desarrollo. Sirve para obtener la versión de un identificador de clase MSXML según el ProgID que tenga asociado. Esta rutina, antes de apoyarse en la función ghProgIDVersion descrita líneas arriba, verifica si el CLSID dado se encuentra en la matriz ghMSXMLDocClassIDs, en cuyo caso regresa una de las cadenas de la matriz ghMSXMLVersions. De último momento, viendo su código, creo que debería hacerle una de dos cosas: a) renombrarla por "ghMSXMLDocVersion" (y que se llame sólo con CLSIDs de DOMDocument), o b) Hacer que busque también en la matriz ghMSXMLSchemaCacheClassIDs (evitando búsquedas en el Registro cuando se llame con CLSIDs de XMLSchemaCache). La necesidad de esta función surgió al agregar la propiedad Version a TghXMLDoc (ver más abajo). Última edición por Al González fecha: 05-01-2014 a las 05:22:41. |
#9
|
||||
|
||||
Recuerden que todas las funciones y constantes descritas en las entradas anteriores (cuyos nombres inician con el prefijo gh), son elementos "sueltos" de la unidad GHFRTL, el kernel de GH Freebrary. Su uso no está restringido a la clase TghXMLDoc que les dio origen. Estos átomos pueden ser utilizados por cualquier programador para lo que guste o necesite (añadir GHFRTL al Uses), incluso para crear una clase mucho mejor y más completa que la mía, lo cual es bastante factible.
Considero una buena práctica y casi un deber moral el escribir clases, componentes o aplicaciones repartiendo el código en constantes, tipos y pequeñas funciones de uso general que no solo permitan cumplir con el objetivo particular del momento, sino que además sirvan luego para construir más clases, componentes y aplicaciones, ya sea por parte de otros programadores en su labor diaria o por uno mismo cuando haya que desarrollar la siguiente solución de software. Creo que esa es la verdadera esencia de las bibliotecas y mi manera de ampliar lo que Delphi hace por nosotros. En seguida el código de la clase (GHFXMLDoc.pas). Observen que el constructor tiene dos sobrecargas, la primera de ellas es por si nosotros mismos queremos indicar la versión, o versiones, de MSXML a usar: Aunque lo habitual será no especificar ningún CLSID y dejar que la clase lo determine: En este caso se intentará con las CLSIDs contenidas en una matriz dinámica de nombre GHXMLDocDefaultClassIDs, en la cual se establecen de forma predeterminada las GUIDs ghciMSXMLDoc60, ghciMSXMLDoc40 y ghciMSXMLDoc30 (ver sección Initialization al final de la unidad). Lo único nuevo en la clase son las propiedades ClassID y Version, los constructores rehechos (conservando compatibilidad con versiones anteriores) y la adaptación del método TghXMLDoc.AddSchema. El largo pergamino de los mensajes anteriores fue para esas cuatro cosillas. Por favor, no duden en preguntar sobre cualquier cuestión que les surja. Les recuerdo que necesito voluntarios para probar el código, más que nada para sacar nuevas ideas y perfeccionarlo entre todos. El estándar XML llegó para quedarse y cada vez se usa para más cosas. Esta humilde clase sólo es una propuesta de cómo facilitárnoslo en Delphi. Espero incluirla la semana que viene en la siguiente liberación para XE2. ¡Un abrazo! Al González. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Utilidades para mejorar el IDE de Delphi | martinzcr | Varios | 1 | 14-09-2007 13:43:40 |
Obtener iconos para mejorar aspectos | zugazua2001 | Varios | 2 | 05-08-2006 20:43:45 |
Para mejorar el impacto del Curriculum Vitae | marcoszorrilla | Humor | 5 | 23-05-2006 09:52:38 |
Para mejorar el currículum | Pablo Carlos | Humor | 3 | 02-09-2005 17:46:34 |
Ayuda para crear una clase | estebanx | OOP | 0 | 10-03-2005 17:36:49 |
|