2008-11-07 9 views

Respuesta

6

Sí. No es posible a menos que elimine del DFM las propiedades que no están publicadas en Delphi 2007.

+0

¿Usted intentó mi respuesta? Pareció funcionar para mí, con la advertencia mencionada: las propiedades específicas de D2009 no se guardaron en .dfm en D2007, pero siempre y cuando no modifique y vuelva a guardar el formulario en D2007, al menos se conservarán. –

+0

Supongo que es posible, simplemente no es muy práctico –

2

Cada formulario tiene un archivo dfm que contiene la configuración de propiedad del formulario y sus componentes. Algunos valores de propiedades tienen valores predeterminados, por lo que no se almacenan si se mantiene el valor predeterminado. es sólo hizo una pequeña prueba:

  • crear un formulario en 2009
  • Añadir un par de controles estándar
  • Guardar que
  • abierto en 2006 (lo siento no 2007 sobre esta PC)

Y funcionó sin mensajes. Pero tal vez no seas tan afortunado.

Con Delphi, a menudo es un poco molesto compartir datos entre versiones. Las posibilidades de actualización son excelentes, pero la degradación es problemática. Por lo tanto, desaconsejo compartir archivos de formulario entre diferentes versiones.

Hasta donde yo sé, no es posible agregar definiciones condicionales en el archivo dfm. Pero, nuevamente, ¿realmente queremos eso? Preferiría un mecanismo que ignore las propiedades desconocidas.

4

Los proyectos Delphi siempre han sido extremadamente fáciles de reenviar puertos a nuevas versiones. Tienes que tener más cuidado, pero usar el código actual con compiladores más antiguos también es bastante directo. Mantuve el código en Delphi 2005/2006/2007 que otras personas todavía necesitaban usar en Delphi 6 y 7.

Si elimina las propiedades incompatibles de los DFM, deberían funcionar correctamente en las versiones anteriores sin estropearlas para Delphi 2009. El mayor ejemplo son las propiedades explícitas * introducidas en Delphi 2006. Tengo un "depurador DFM" hecho en casa que elimina estos. Recuerde que estas propiedades existen por alguna razón, por lo que solo debe eliminar aquellas que tenga la intención de ser compatible con versiones anteriores.

También puede considerar invertir en herramientas de análisis de código estático como CodeHealer o Pascal Analyzer. Además de señalar los problemas (especialmente CodeHealer) y ayudarlo a limpiar su código, puede elegir qué versión de Delphi analizar, por lo que es más fácil encontrar incompatibilidades además de las propiedades de DFM. Y pueden automatizarse como parte de su proceso de compilación.

Solo una nota. Comparta el código fuente, pero mantenga proyectos separados para cada versión. Esto es especialmente importante entre Delphi 2007 y Delphi 2009. El archivo .dproj más reciente utiliza la misma extensión, pero no es compatible con Delphi 2007. También puede acceder a algunos recursos incompatibles.

+0

No estoy de acuerdo con que Delphi proyecte el puerto fácilmente. He hecho migraciones en el pasado y parece que la mayoría de los componentes/controles necesitan al menos cambios menores, a menudo importantes. Esto se compara con decir que un proyecto en C# realizado en Visual Studio es mucho peor. –

+0

Tu experiencia ha sido diferente a la mía, entonces. Desde Delphi 1, no creo que haya trabajado en un solo proyecto que no se haya movido al menos una vez. Esto casi siempre ha sido muy directo. Incluso puedo volver a compilar varios de ellos en versiones anteriores. –

+0

Los problemas que he tenido se han limitado a mi código para solucionar errores de VCL. Luego, cuando sale una nueva versión, a veces tengo que deshacer las soluciones y luego encontrar e implementar las correcciones para todos los nuevos errores de VCL. Pero la compatibilidad subyacente de una versión a la siguiente es excelente en Delphi. –

2

Puede agregar de forma segura las propiedades en el código en su método OnCreate para el formulario y ajustar un {$ IFDEF VER200} // NUEVAS PROPIEDADES {$ ENDIF} a su alrededor. Puede dejar DoubleBuffered fuera de los ifdefs, como estaba presente en Delphi 2007, simplemente no disponible para el inspector de propiedades.

SÓLO tendrá que preocuparse por las propiedades que establece diferente de la predeterminada. Para la doble copia, solo debe preocuparse por esto si está configurado en verdadero.

Al cargar el formulario Delphi 2009 en Delphi 2007, recibirá una advertencia de que una propiedad se va a destruir, solo tome nota de esas propiedades, ya que esas son las que tendrá que tratar.

Estoy utilizando solo un método para migrar mi código a Delphi 2009 desde Delphi 2006. La mayoría de mis proyectos contienen varias unidades compartidas y deben compilarse en Delphi 2006 para la versión de envío y Delphi 2009 para la "próxima" versión. También uso mucho la definición {$ IFDEF UNICODE} donde necesito asegurar que una cadena sea de cadena ancha o ansistring, dependiendo de la rutina.

14

DoubleBuffered ha estado en TWinControl desde hace algún tiempo. La diferencia en Delphi 2009 es que está publicado ahora. Si se puede vivir con tanto ignorar los errores (y no haciendo las propiedades funcionan en su lugar), aquí es una solución posible:

unit Delphi2009Form; 

interface 

uses 
    Windows, Classes, SysUtils, Controls, Forms; 

type 
{$IFDEF VER200} 
    TDelphi2009Form = class(TForm); 
{$ELSE} 
    TDelphi2009Form = class(TForm) 
    private 
    procedure ReaderError(Reader: TReader; const Message: string; var Handled: Boolean); 
    protected 
    procedure ReadState(Reader: TReader); override; 
    end; 

    TReaderErrorProc = procedure(const Message: string); 

var 
    ReaderErrorProc: TReaderErrorProc = nil; 
{$ENDIF} 

implementation 

{$IFNDEF VER200} 
type 
    THackReader = class(TReader); 

procedure TDelphi2009Form.ReaderError(Reader: TReader; const Message: string; var Handled: Boolean); 
begin 
    with THackReader(Reader) do 
    Handled := AnsiSameText(PropName, 'DoubleBuffered') or AnsiSameText(PropName, 'ParentDoubleBuffered'); 
    if Handled and Assigned(ReaderErrorProc) then 
    ReaderErrorProc(Message); 
end; 

procedure TDelphi2009Form.ReadState(Reader: TReader); 
begin 
    Reader.OnError := ReaderError; 
    inherited ReadState(Reader); 
end; 
{$ENDIF} 

end. 

a continuación, cambiar las declaraciones de los formularios en su proyecto para heredar de TDelphi2009Form, por ejemplo:

type 
    TFormMain = class(TDelphi2009Form) 
    ... 

Esto funcionará en tiempo de ejecución - se tendrá en cuenta los errores de propiedad. Para hacer que funcione en tiempo de diseño, también, crear un paquete único diseño-, añadir a su designide.dcp requiere cláusula, y añadir la siguiente unidad a la misma:

unit Delphi2009FormReg; 

interface 

uses 
    Delphi2009Form; 

procedure Register; 

implementation 

uses 
    DesignIntf, DesignEditors, ToolsAPI; 

procedure ShowReaderError(const Message: string); 
begin 
    with BorlandIDEServices as IOTAMessageServices do 
    AddTitleMessage(Message); 
end; 

procedure Register; 
begin 
    RegisterCustomModule(TDelphi2009Form, TCustomModule); 
    ReaderErrorProc := ShowReaderError; 
end; 

initialization 

finalization 
    ReaderErrorProc := nil; 

end. 

instalar el paquete en Delphi 2007 IDE y la propiedad los errores para las propiedades DoubleBuffered y ParentDoubleBuffered se ignorarán automáticamente al abrir sus formularios en el IDE. Los valores de las propiedades se perderán cuando guarde el formulario en Delphi 2007, por lo que debe inicializarlos en código.

EDITAR: He añadido el código de salida de los mensajes de error de lector a la ventana Mensajes IDE:

IDE error messages

+0

+1 por la simple observación de que la propiedad existe antes de D2009. No lo sabía. Ahora puedo corregir algunos problemas con solo encenderlo en el momento de la carga, en FormCreate. ¡Muy útil! –

Cuestiones relacionadas