Al González
09-01-2014, 09:27:29
Hola amigos.
Necesito que me ayuden a probar algo muy sencillo en versiones de Delphi de la 2009 en adelante. De momento sólo tengo XE2, en la cual he detectado lo que al parecer es un defecto de automatización relacionado con parámetros WideChar, pero no he tenido la suerte de encontrar información sobre si ya fue corregido el problema o en cuáles versiones de Delphi se presenta.
Una sentencia con la que pueden probar es:
OLEVariant (CreateOLEObject ('MSXML2.DOMDocument.6.0')).CreateElement ('a');
(debe estar la unidad COMObj en el Uses para poder usar CreateOLEObject)
Si aparece una excepción como "cadena clase no válida", pueden intentar con otro ProgID ('MSXML2.DOMDocument.3.0', 'Word.Application', etcétera). Lo importante es que en seguida se coloque el nombre de un método que sea válido para ese tipo de objeto (CreateElement es un método de DOMDocument), que dicho método espere un argumento de tipo cadena de caracteres y que pongan una cadena literal compuesta sólo por una letra.
Una instrucción como la anterior se ejecuta sin problemas en Delphi 7, mientras que en XE2 causa una excepción "Este nombre no puede empezar por el carácter...". Viendo el código máquina con la ventana CPU, encontré que Delphi 7 manda el carácter como String, mientras que XE2 lo manda como un Byte, por lo que XE2 requiere de una pequeña ayuda para evitar el error mencionado:
OLEVariant (CreateOLEObject ('MSXML2.DOMDocument.6.0')).CreateElement (String ('a'));
(el molde de tipo String ('a'))
Tradicionalmente, la automatización ha convertido los argumentos String y Char a WideString (el tipo usado en COM), pero XE2 no lo hace cuando la expresión es un carácter Char (WideChar), mientras que un valor de tipo ANSIChar sí lo convierte a WideString. Esto supone que cuando adaptaron el compilador a Unicode (Delphi 2009), tuvieron un descuido respecto a los valores de tipo WideChar usados en la automatización de tipo late binding. Lo bueno es que se soluciona con un simple molde de tipo.
Básicamente me interesa conocer desde qué versiones ocurre este problema y si ya fue corregido en lanzamientos posteriores a XE2. Así sabré qué ediciones de GHF deberán prevenirse empleando el molde de tipo "String (Valor)" (además de XE2), por no decir que este hilo, con la información que ustedes me ayudarán a completar, le será de ayuda a alguien más que se tope con el mismo problema.
Ruego a quien pueda hacer esa sencilla prueba, no lleva más de un par de minutos. :)
De antemano, gracias.
Al.
Necesito que me ayuden a probar algo muy sencillo en versiones de Delphi de la 2009 en adelante. De momento sólo tengo XE2, en la cual he detectado lo que al parecer es un defecto de automatización relacionado con parámetros WideChar, pero no he tenido la suerte de encontrar información sobre si ya fue corregido el problema o en cuáles versiones de Delphi se presenta.
Una sentencia con la que pueden probar es:
OLEVariant (CreateOLEObject ('MSXML2.DOMDocument.6.0')).CreateElement ('a');
(debe estar la unidad COMObj en el Uses para poder usar CreateOLEObject)
Si aparece una excepción como "cadena clase no válida", pueden intentar con otro ProgID ('MSXML2.DOMDocument.3.0', 'Word.Application', etcétera). Lo importante es que en seguida se coloque el nombre de un método que sea válido para ese tipo de objeto (CreateElement es un método de DOMDocument), que dicho método espere un argumento de tipo cadena de caracteres y que pongan una cadena literal compuesta sólo por una letra.
Una instrucción como la anterior se ejecuta sin problemas en Delphi 7, mientras que en XE2 causa una excepción "Este nombre no puede empezar por el carácter...". Viendo el código máquina con la ventana CPU, encontré que Delphi 7 manda el carácter como String, mientras que XE2 lo manda como un Byte, por lo que XE2 requiere de una pequeña ayuda para evitar el error mencionado:
OLEVariant (CreateOLEObject ('MSXML2.DOMDocument.6.0')).CreateElement (String ('a'));
(el molde de tipo String ('a'))
Tradicionalmente, la automatización ha convertido los argumentos String y Char a WideString (el tipo usado en COM), pero XE2 no lo hace cuando la expresión es un carácter Char (WideChar), mientras que un valor de tipo ANSIChar sí lo convierte a WideString. Esto supone que cuando adaptaron el compilador a Unicode (Delphi 2009), tuvieron un descuido respecto a los valores de tipo WideChar usados en la automatización de tipo late binding. Lo bueno es que se soluciona con un simple molde de tipo.
Básicamente me interesa conocer desde qué versiones ocurre este problema y si ya fue corregido en lanzamientos posteriores a XE2. Así sabré qué ediciones de GHF deberán prevenirse empleando el molde de tipo "String (Valor)" (además de XE2), por no decir que este hilo, con la información que ustedes me ayudarán a completar, le será de ayuda a alguien más que se tope con el mismo problema.
Ruego a quien pueda hacer esa sencilla prueba, no lleva más de un par de minutos. :)
De antemano, gracias.
Al.