Ir al contenido


Foto

TClientDataSet


  • Por favor identifícate para responder
40 respuestas en este tema

#21 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.156 mensajes
  • LocationMéxico

Escrito 02 marzo 2013 - 09:49

Hola

He querido instalar los componentes en mi Turbo Delphi antes de intentar instalarlo en XE2 y se me ha presentado el siguiente mensaje de error:

[Pascal Error] GHFUtils.pas(210): E2250 There is no overloaded version of 'AddItems' that can be called with these arguments
[Pascal [Fatal Error] GHFClientDataSet.pas(510): F2063 Could not compile used unit 'GHFUtils.pas'


Adjunto la imagen de la línea donde se genera el error.

Saludos

Archivos adjuntos


  • 0

#22 Al González

Al González

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 99 mensajes

Escrito 03 marzo 2013 - 02:07

Rolphy:

Agregué tus valiosas observaciones junto con otros seis planteamientos en este nuevo hilo, en Club Delphi (puntos 7 y 8).  De todas formas pego aquí mis respuestas, adelantándote que sí vamos a tener que renombrar esa unidad, pero no debido a la sub-sigla FMX, sino a una pifia de mi parte en cuestión de siglas de países e idiomas.

Punto 7. Todos los archivos de código de GH Freebrary comienzan con las iniciales "GHF", y "MX" es el código ISO de dos letras asignado al país México. En la biblioteca existen dos unidades más cuyo nombre se compone de elementos similares: GHFEN (utilidades del idioma inglés) y GHFES (utilidades para España y del idioma español). Las tres unidades son muy pequeñas todavía, pero nos dan pauta para agregarles con el paso del tiempo más funciones, clases o constantes relacionadas con México (MX), el idioma inglés (EN), y España y el idioma español (ES), respectivamente. Esto además establece una propuesta de cómo tendrían que ser nombradas las nuevas unidades que lleguen a crearse para aspectos de otros idiomas y países.

Al manejar siglas es frecuente que ocurran este tipo de coincidencias. Renombrar la unidad significaría cambiar la regla anteriormente descrita y terminaríamos renombrando al menos dos unidades más. En mi opinión el uso de la sigla FMX para FireMonkey, con la consecuente impresión que causa al ver GHFMX, no tiene el suficiente peso para obligarnos a hacer ese cambio. Pero bueno, debemos aprovechar que los foros le permiten a un grupo de personas ponerse de acuerdo, y construir las mejores soluciones con base en las opiniones y argumentos de cada participante.

En descargo y analizando mis propias palabras, creo que vamos a toparnos con un verdadero problema cuando nos toque crear la unidad GHFAR (¿Argentina o idioma árabe?). ¡Puf, que metida de pata!

Punto 8. Con el tiempo he llegado a la conclusión (quizá estoy equivocado) de que los paquetes de Delphi tienden a volverse problemáticos, debido a las inevitables dependencias que guardan unos con otros. En viejas versiones de GH Freebrary (Interfaz GH, Magia Data) incluía un .dpk "de fábrica" para facilitar su registro en la paleta de componentes, y eso es ciertamente lo que hacen casi todos los autores de bibliotecas. Pero como usuario de Delphi, y después de varias desagradables experiencias por conflictos entre paquetes a raíz de los famosos requires, he optado por no crearle problemas al usuario de los componentes gh "heredándole" paquetes de fábrica que eventualmente va a tener que editar a fin de instalar el componente que desea usar realmente.

He preferido entregar una unidad "XXX_Reg" para cada uno de los componentes, y así el desarrollador decide cuáles instalar y cuáles no, dejando a su criterio el agregar estas unidades a un paquete existente (que podría ser DclUsr) o crear para ello uno nuevo. Esto lo indico en las instrucciones de instalación. Además, esto crea menos dependencias entre las propias unidades de la biblioteca, facilitando con ello la transición por partes a otras versiones de Delphi.


Eliseo:

No sé por qué daba por hecho que tenías Delphi 7.  Acabo de revisar la encuesta de octubre pasado, y ya recuerdo que tienes las versiones 6, Turbo Delphi 2006 y las XEs.

El error que reportas es una de las muchas y normales cuestiones de incompatibilidad entre versiones que vamos a tener que resolver.  Echando un vistazo rápido en la VCL de Delphi 2007, encontré que la causa concreta de ésta es que Borland, en alguna versión posterior a la 7, cambió la herencia de la clase TFieldList (el tipo de DataSet.FieldList), de tal manera que ya no desciende de TStrings, sino de TWideStrings.

El método TghObjList.AddItems actual (para delphi 7) puede recibir una lista TList o una lista TStrings, por lo que tendríamos que definirle otra sobrecarga de AddItems que admita un TWideStrings para ayudar a que la función ghEnumFields sea compatible con nuevas versiones.  Sin embargo, ninguno de los componentes usa dicha función.  El compilador marca el error porque uno o más de los componentes (uno de ellos es TghClientDataSet) usan otros elementos de la unidad GHFUtils.  Así que la función podría comentarse para permitir al compilador continuar, pero de antemano te digo que saldrán más cuestiones de compatibilidad entre versiones que habrá que arreglar.  Todo esto vendría quedando en el punto 2 del hilo de ocho temas que referí anteriormente.  Migrar una biblioteca de una versión a otra de Delphi es uno de los trabajos más laboriosos, pero de los que más satisfacciones surgen.

Viéndolo desde un punto de vista colectivo, ¿consideran que valdría la pena intentar ahora una versión para Turbo Delphi 2006 o concentrar la mayor parte del esfuerzo en crear una versión para Delphis un poco más actuales y utilizados como XE2?  Lo ideal es que exista una versión para todos del 7 en adelante, pero dados los escasos recursos de que disponemos, quizá debamos permitir que el peso del interés comunitario lo determine.

Invito a todos a que sigamos el hilo que inicié ayer en Club Delphi (http://www.clubdelph...ead.php?t=82395), o si prefieren que empecemos uno igual en DelphiAccess.  Aunque de antemano preferiría que no tuviéramos que "duplicar" trabajo, ya que, como saben, pocas veces basta con copiar y pegar.

Un abrazo.

Al González.
  • 0

#23 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.156 mensajes
  • LocationMéxico

Escrito 03 marzo 2013 - 03:49

Eliseo:

No sé por qué daba por hecho que tenías Delphi 7.  Acabo de revisar la encuesta de octubre pasado, y ya recuerdo que tienes las versiones 6, Turbo Delphi 2006 y las XEs.

El error que reportas es una de las muchas y normales cuestiones de incompatibilidad entre versiones que vamos a tener que resolver.  Echando un vistazo rápido en la VCL de Delphi 2007, encontré que la causa concreta de ésta es que Borland, en alguna versión posterior a la 7, cambió la herencia de la clase TFieldList (el tipo de DataSet.FieldList), de tal manera que ya no desciende de TStrings, sino de TWideStrings.

El método TghObjList.AddItems actual (para delphi 7) puede recibir una lista TList o una lista TStrings, por lo que tendríamos que definirle otra sobrecarga de AddItems que admita un TWideStrings para ayudar a que la función ghEnumFields sea compatible con nuevas versiones.  Sin embargo, ninguno de los componentes usa dicha función.  El compilador marca el error porque uno o más de los componentes (uno de ellos es TghClientDataSet) usan otros elementos de la unidad GHFUtils.  Así que la función podría comentarse para permitir al compilador continuar, pero de antemano te digo que saldrán más cuestiones de compatibilidad entre versiones que habrá que arreglar.  Todo esto vendría quedando en el punto 2 del hilo de ocho temas que referí anteriormente.  Migrar una biblioteca de una versión a otra de Delphi es uno de los trabajos más laboriosos, pero de los que más satisfacciones surgen.

Viéndolo desde un punto de vista colectivo, ¿consideran que valdría la pena intentar ahora una versión para Turbo Delphi 2006 o concentrar la mayor parte del esfuerzo en crear una versión para Delphis un poco más actuales y utilizados como XE2?  Lo ideal es que exista una versión para todos del 7 en adelante, pero dados los escasos recursos de que disponemos, quizá debamos permitir que el peso del interés comunitario lo determine.


Hola Al, Tengo Delphi4, Turbo Delphi que es Delphi 2006, XE y XE2, no creo pasar a XE3 porque me voy a esperar a XE4.

Yo soy de la opinión que si a una sola persona le sirve, ya valió la pena el esfuerzo, sin embargo, me ajusto a la decisión general.

Invito a todos a que sigamos el hilo que inicié ayer en Club Delphi (http://www.clubdelph...ead.php?t=82395), o si prefieren que empecemos uno igual en DelphiAccess.  Aunque de antemano preferiría que no tuviéramos que "duplicar" trabajo, ya que, como saben, pocas veces basta con copiar y pegar.


Y porque no comenzamos a usar delphispano.com para concentrar éste tipo de trabajos colaborativos, ahí está en espera de ser utilizado.

Saludos
  • 0

#24 Al González

Al González

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 99 mensajes

Escrito 03 marzo 2013 - 06:29

Yo soy de la opinión que si a una sola persona le sirve, ya valió la pena el esfuerzo [..]

Soy de la misma opinión, por ello lo de "intentar ahora" no "intentar" a secas.  ;)

Y porque no comenzamos a usar delphispano.com para concentrar éste tipo de trabajos colaborativos, ahí está en espera de ser utilizado.

No estoy al día sobre los avances de DelpHispano, si bien como siempre su éxito es mi deseo y encantado estaré de promover este proyecto desde ahí, pero para empezar el desarrollo de los distintos temas me gustaría hacer partícipe a la Comunidad en sus habituales espacios de opinión, que son los foros.  En su momento, si esto "pega" y lo viéramos necesario, podríamos llevar a cabo parte el trabajo en un espacio más adecuado.

Saludos. :)
  • 0

#25 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 04 marzo 2013 - 06:21

Saludos.

Al, creo conveniente utilizar archivos de extensión INC (esto es un TXT con otra extensión), utilizados para las incluir las directivas del compilador y métodos dependiendo de la versión de Delphi.

El personal de bibliotecas de TMS y Devrace FibPlus hacen uso extensivo de este recurso.

Ejemplo:
Para las versiones de Delphi:

{$IFDEF VER90}
{$DEFINE DELPHI2_LVL}
{$DEFINE ISDELPHI}
{$ENDIF}

{$IFDEF VER93}
{$DEFINE DELPHI2_LVL}
{$ENDIF}

{$IFDEF VER100}
{$DEFINE DELPHI2_LVL}
{$DEFINE DELPHI3_LVL}
{$DEFINE ISDELPHI}
{$ENDIF}

{$IFDEF VER110}
{$DEFINE DELPHI2_LVL}
{$DEFINE DELPHI3_LVL}
{$ENDIF}

{$IFDEF VER120}
{$DEFINE DELPHI2_LVL}
{$DEFINE DELPHI3_LVL}
{$DEFINE DELPHI4_LVL}
{$DEFINE ISDELPHI}
{$ENDIF}


Para agregar código:

{$IFDEF DELPHIXE_LVL}

function TimeSeparator: char;
  Result := FormatSettings.TimeSeparator;
end;

function DateSeparator: char;
begin
  Result := FormatSettings.DateSeparator;
end;
{$ENDIF}


¿Qué has resuelto con el tema de los BPL?
  • 0

#26 cadetill

cadetill

    Advanced Member

  • Moderadores
  • PipPipPip
  • 994 mensajes
  • LocationEspaña

Escrito 04 marzo 2013 - 07:49

Saludos.

Al, creo conveniente utilizar archivos de extensión INC (esto es un TXT con otra extensión), utilizados para las incluir las directivas del compilador y métodos dependiendo de la versión de Delphi.

El personal de bibliotecas de TMS y Devrace FibPlus hacen uso extensivo de este recurso.


Te faltó incluir el include del archivo inc



delphi
  1. {$I MiArchivoINC.inc}



Yo también lo uso en la GMLib y fenomenal ;-)

Saludos
  • 0

#27 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 04 marzo 2013 - 07:52


Saludos.

Al, creo conveniente utilizar archivos de extensión INC (esto es un TXT con otra extensión), utilizados para las incluir las directivas del compilador y métodos dependiendo de la versión de Delphi.

El personal de bibliotecas de TMS y Devrace FibPlus hacen uso extensivo de este recurso.


Te faltó incluir el include del archivo inc



delphi
  1. {$I MiArchivoINC.inc}



Yo también lo uso en la GMLib y fenomenal ;-)

Saludos


Saludos.

Sí, ya sabes cuando se anda dando ejemplo normalmente se queda algo.....
  • 0

#28 Al González

Al González

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 99 mensajes

Escrito 04 marzo 2013 - 10:18

Al, creo conveniente utilizar archivos de extensión INC (esto es un TXT con otra extensión), utilizados para las incluir las directivas del compilador y métodos dependiendo de la versión de Delphi.


Hola Rolphy, conozco las directivas que mencionas, algunas como $I (ahora también $Include) desde los tiempos de Turbo Pascal.  Las usé en versiones antiguas de la biblioteca, precisamente para mantener un único juego de unidades compatible con Delphi 1, 3, 4 y 5.  Hasta que se volvió muy pesado para una sola persona mantener en orden todo aquello.

No descarto su uso ahora, aunque tampoco me parece demasiado complejo seguir un esquema como el de la VCL: un juego de archivos único para cada versión del compilador.  Con la ventaja de un código más "limpio" que esto da. :)

¿Qué has resuelto con el tema de los BPL?


Dos o tres mensajes atrás comenté sobre los DPKs / BPLs, y lo de renombrar la unidad GHFMX. :)

De eso último, por cierto, ya hubo algo más de retroalimentación: http://www.clubdelph...5955#post455955

Saludos cordiales.
  • 0

#29 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 04 marzo 2013 - 11:11

No descarto su uso ahora, aunque tampoco me parece demasiado complejo seguir un esquema como el de la VCL: un juego de archivos único para cada versión del compilador.  Con la ventaja de un código más "limpio" que esto da. :)


Saludos.

Ahora sí que me perdí.

Por ejemplo, crear carpetas por cada versión de Delphi soportada y copiando los fuentes dentro de cada una. ¿Te refieres a eso? en caso de no ser así ¿Puedes explicarme mejor?
  • 0

#30 Al González

Al González

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 99 mensajes

Escrito 04 marzo 2013 - 11:22

Por ejemplo, crear carpetas por cada versión de Delphi soportada y copiando los fuentes dentro de cada una. ¿Te refieres a eso?


Sí.  Y para la distribución no necesariamente tener que descargar todas esas carpetas.  Sólo el ZIP de la versión que interese al desarrollador.  (y)
  • 0

#31 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 04 marzo 2013 - 11:25

Sí.  Y para la distribución no necesariamente tener que descargar todas esas carpetas.  Sólo el ZIP de la versión que interese al desarrollador.  (y)


Saludos.

Veo un problema en este planteamiento y es que si encuentras un error genérico en cualquier unidad para su corrección debes ir a "no sé cuantas" carpetas para ir corrigiendo una por una.

Desde mi modo de ver es una desventaja.
  • 0

#32 Al González

Al González

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 99 mensajes

Escrito 04 marzo 2013 - 11:38

[...] si encuentras un error genérico en cualquier unidad para su corrección debes ir a "no sé cuantas" carpetas para ir corrigiendo una por una.


Desde luego Rolphy, esa es la principal desventaja y una buena razón para usar las directivas de compilación que comentábamos.  La cuestión es evaluar el costo-beneficio de un esquema y del otro.  Yo, en lo personal, doy prioridad al código fuente claro y organizado, algo que se compromete en cierta medida cuando usas directivas para determinar la compilación a realizar según la versión del lenguaje.  Por otra parte, teniendo en orden las distintas versiones y las aplicaciones de pruebas ("testing"), el trabajo se hace más fácil de ejecutar.

Hay que echarle una buena pensada a este punto.  Como te digo, no descarto ninguna opción. :)

Saludos.
  • 0

#33 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 04 marzo 2013 - 11:42

Saludos.

Al usted es el Head Master lo que decida será acogido, una vez este punto este completado conjuntamente con el tema de los BPL creo que estaríamos en el camino adecuado de hacer compatible la librería GH con las versiones de Delphi de uso actual.
  • 0

#34 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 22 marzo 2013 - 12:17

Saludos.

He sacado tiempo y he realizado una instalación (sin realizar prueba) del componente TghDataSource en Delphi 2010.

Tuve algunos Warnings y Errors, ojala Al pueda echar un vistazo, en la unidad GHFRTL en su mayoría pude corregirlos solo un Warning no pude corregir en el siguiente método:


delphi
  1.   Function ghStr (Const Value, MinLength :Integer;
  2.     Const PadChr :Char = '0') :String; Overload;
  3.   Var
  4.     AResult :PChar Absolute Result;
  5.     I :Integer;
  6.   Begin
  7.  
  8.     /// Para XE2 utilizar System._Str2Ext
  9.     Str (Value:MinLength, Result); //<<--------- Aqui
  10.  
  11.     If PadChr = ' ' Then
  12.       Exit;
  13.  
  14.     I := 0;
  15.  
  16.     While AResult [I] = ' ' Do
  17.     Begin
  18.       AResult [I] := PadChr;  // Direct writing on the unique string Result
  19.       Inc (I);
  20.     End;
  21.   End;



Buscando referencia encontré en el wiki de Embardero la descripción del método y la salvedad (nota) de que era posible que dicha advertencia podía surgir, pero no su arreglo.

A manera general, cree un Package llamado GHFreebraryCore donde añadí todas las unidades para su compilación mas no pude completar el proceso porque existen demasiadas incompatibilidades de tipo de datos en el ClientDataSet por lo que procedí a crear el paquete GHFCoreDataSource donde si pude realizar la compilación de manera satisfactoria.

Al, en los siguientes métodos el compilador marca error:

Error 1:


delphi
  1.   Function TghClientDataSet.ActiveRecBuffer :PChar;
  2.   Begin
  3.     If State In ghdsCalc Then
  4.       Result := CalcBuffer
  5.     Else
  6.       Result := ActiveBuffer;
  7.   End;


El compilador indica: [DCC Error] GHFClientDataSet.pas(639): E2010 Incompatible types: 'Byte' and 'Char'.
Viendo la unidad DB, la propiedad CalcBuffer es del tipo TRecordBuffer, definido: TRecordBuffer = PByte. La asignación de Result := ActiveBuffer también marca error, la definición function ActiveBuffer: TRecordBuffer; inline;.

Error 2 y 3:


delphi
  1.   Procedure TghClientDataSet.SetBaseOrder (Const Cursor :IDSCursor);
  2.   Var
  3.     Index :DSIDXDesc;
  4.  
  5.     Function Activate :DBResult;
  6.     Begin
  7.       Result := Cursor.UseIndexOrder (PChar (GHClientDataSetBaseOrder));
  8.     End;
  9.   Begin
  10.     If Not CheckStatus (Activate, dberr_NoSuchIndex) Then
  11.       Exit;
  12.  
  13.     { We add the "natural" base index (rows as they were created/appended).
  14.       NOTE: the default order (szDefault_Order) is not necessarily equal to
  15.       this "base order". }
  16.     ZeroMemory (@Index, SizeOf (Index));  //PAnsiChar
  17.     StrLCopy (Index.szName, PChar (GHClientDataSetBaseOrder),
  18.       SizeOf (Index.szName) - 1);
  19.     Check (DSBase.CreateIndex (Index));
  20.  
  21.     Check (Activate);
  22.   End;



Para la asignación Result := Cursor.UseIndexOrder (PChar (GHClientDataSetBaseOrder));, indica [DCC Error] GHFClientDataSet.pas(1515): E2010 Incompatible types: 'Char' and 'AnsiChar' (no supe como resolverlo, tengo deficiencias con relación al UniCode).

La definición de UseIndexOrder es:


delphi
  1. function UseIndexOrder(        { Switch to index order }
  2.         pszName  : PAnsiChar
  3.     ): DBResult; stdcall;



El tercer error es en la llamada del método StrLCopy (Index.szName, PChar (GHClientDataSetBaseOrder), SizeOf (Index.szName) - 1);,
indica [DCC Error] GHFClientDataSet.pas(1526): E2250 There is no overloaded version of 'StrLCopy' that can be called with these arguments.

La definición de la función StrLCopy:


delphi
  1. function StrLCopy(Dest: PAnsiChar; const Source: PAnsiChar; MaxLen: Cardinal): PAnsiChar; overload;
  2. function StrLCopy(Dest: PWideChar; const Source: PWideChar; MaxLen: Cardinal): PWideChar; overload;



Espero puedas darnos una mano (y)...
  • 0

#35 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 22 marzo 2013 - 01:06

Saludos.

Pues con deseos de seguir compilando, comente las líneas que marcaban errores, además de sacar del paquete dos unidades y voila se completo satisfactoriamente.

Ahora bien, como dije que había comentado líneas, es de saber que al momento de los componentes acceder a esos métodos se comportara de una manera extraña.

Las líneas comentadas tienen el encabezado OJO DESCOMENTAR, para cuando alguien se siente a resolver las incompatibilidades existentes.

Las unidades a las que me vi forzado a sacar del paquete son:
  • GHFSQLConnection
  • GHFFirebirdSQLConnection

Creo que con los pequeños cambios realizados se podrá compilar más fácil para Delphi XE, para Delphi XE2 habría que ver lo relacionado al Unit Scope.
  • 0

#36 Al González

Al González

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 99 mensajes

Escrito 22 marzo 2013 - 01:41

Muchas gracias, Rolphy.

Vi el aviso que dejaste en Club Delphi, donde, por cierto, se te echa de menos como a casi todos los grandes amigos que tengo aquí.  Pongo un enlace a mi respuesta, para no redundar: http://www.clubdelph...7434#post457434

Saludos.

Al González.
  • 0

#37 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 22 marzo 2013 - 09:16

Saludos.

He estado tratando de compilar la librería para Delphi XE continuando con el mismo proceso de crear paquetes y demás, con esto me refiero a la incompatibilidad existente desde Delphi 2010 en relación al TClientDataSet osea a las líneas de código que comente en el archivo que subí para Delphi 2010.

Procedí a crear un paquete con todas las unidades, salvo GHFFirebirdSQLConnection y GHFSQLConnection, al realizar la compilación me encuentro con el siguiente error en la unidad GHFClientDataSet: [DCC Error] GHFClientDataSet.pas(139): E2268 Parameters of this type cannot have default values en los métodos:


delphi
  1. Function CreateCursor (Const ABookmark :TBookmark = Nil)
  2.           :IDSCursor;
  3. Procedure EnableControls (Const ABookmark :TBookmark = Nil);



Indagando, encontré que Embarcadero cambio el tipo de datos de TBookmark anteriormente (<= Delphi 2007) era del tipo Pointer pero para versiones modernas (>= Delphi 2009) es del tipo TBytes. Hasta aquí todo bien porque pude realizar la compilación con Delphi 2010, pero a partir de Delphi XE se introdujo un bug por parte de EMBT y se corrige en Delphi XE3 (buscar el nombre del error que expuse con referencia al tipo TBytes).

¿Algún workaround para Delphi XE y XE2?

Al, ¿Crees prudente eliminar el valor por defecto?.

P.D. Al ya hice el comentario en ClubDelphi.
  • 0

#38 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 24 marzo 2013 - 07:39

Saludos.

Pude realizar la compilación para Delphi XE1.  Aun persisten algunos problemas de incompatibilidad heredados desde la compilación para Delphi 2010 en la unidad del ClientDataSet y del SQLConnection.

Las líneas con problemas están marcadas con "//  OJO DESCOMENTAR" al igual que el otro archivo RAR que había subido para Delphi 2010.

La buena noticia de todo esto es que se puede instalar el componente TghDataSource tanto para Delphi 2010 como XE1, dentro de poco me pondré a compilar para Delphi XE2.

Debo mencionar que para resolver el problema del valor por defecto de los parámetros de los métodos: CreateCursor y EnableControls.  Simplemente le elimine el valor por defecto y donde quiera que se hace referencia a dichos métodos donde no se le indicaba valor al parámetro le paso el valor Nil.

Happy Coding!!
  • 0

#39 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 24 marzo 2013 - 08:36

Saludos.

La compilación para Delphi XE2 fue bastante corta, prácticamente exacta a Delphi XE1, claro esta que la compilación esta solo para Win32.  Quedara en lo adelante ver que tan factible hacer la librería compatible con Win64 y demás entornos soportados por Delphi XE2+.

Me encontré dos mensajes de error:
1) En la unidad del ClientDataSet en el método Procedure DataEvent (Event :TDataEvent; Info :LogInt); Override; para versiones anteriores a Delphi XE2 esto esta bien pero para versiones posteriores se debe reemplazar por Procedure DataEvent (Event :TDataEvent; Info :NativeInt); Override;.

2) Para darle a la librería un estilo de codificación Delphi XE2, realice la sustitución de los nombres de las unidades "estandard" por su Unit Scope mas el nombre de la unidad generando esto un error para la clase TIniFile = Class (IniFiles.TIniFile) por lo que fue sustituido por TIniFile = Class (System.IniFiles.TIniFile).

Igual, existe los errores de incompatibilidad desde la compilación para Delphi 2010 que he venido mencionando desde mis post anteriores.

Happy Coding!!
  • 0

#40 Al González

Al González

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 99 mensajes

Escrito 25 marzo 2013 - 11:25

De nuevo, gracias Rolphy.  Veo muy valiosa esta exploración de rutas que has hecho, es más de lo que esperaba para comenzar a allanar el camino. :)

Sobre los parámetros con valor predeterminado, recordar a manera de tip que, cuando nos vemos impedidos de usarlos debido a su tipo de dato, existe la alternativa de crear una sobrecarga (Overload), de tal suerte que se mantiene la característica de poder hacer la llamada con o sin el parámetro en cuestión; desde luego, ponderando cada caso.  Estimaré la conveniencia de recurrir a ello en los métodos que encontraste.

Como te comentaba anteriormente, se creó un nuevo foro para la biblioteca.  Aparte me han hecho moderador del mismo, así que siéntete bienvenido a él, y extiendo esta cordial invitación a todos aquellos colegas y amigos con genuino y noble interés en apoyar el proyecto.  De cualquier forma, comprenderé cuando las aportaciones lleguen a través de otros canales y mi agradecimiento por las mismas será invariable.

Quién iba a decir que la afinidad que sentí con Marc cuando describía su experiencia con la clase TClientDataSet iba a derivar en este enriquecedor pasaje.

¡Un abrazo!

Al González.
  • 0