2008-11-07 11 views

Répondre

6

Oui. Cela n'est possible que si vous supprimez les propriétés qui ne sont pas publiées dans Delphi 2007 à partir de DFM.

+0

Avez-vous essayé ma réponse? Cela a semblé fonctionner pour moi, avec la mise en garde mentionnée - propriétés spécifiques à D2009 non sauvegardées dans .dfm dans D2007 - mais tant que vous ne modifiez pas et ne réenregistrez pas le formulaire dans D2007, elles seront au moins conservées. –

+0

Je suppose que c'est possible, mais pas très pratique –

2

Chaque formulaire a un fichier dfm qui contient les paramètres de propriété du formulaire et de ses composants. Certaines valeurs de propriété ont des valeurs par défaut, elles ne sont donc pas stockées si la valeur par défaut est conservée. est-il juste fait un petit test:

  • Créer un formulaire en 2009
  • Ajouter quelques contrôles standard
  • Enregistrer ce
  • Ouvert en 2006 (désolé pas 2007 sur ce pc)

Et cela a fonctionné sans messages. Mais peut-être que vous n'êtes pas si chanceux. Avec Delphi, il est souvent un peu difficile de partager des données entre les versions. Les possibilités de mise à niveau sont excellentes, mais la rétrogradation est problématique. Donc, je déconseille de partager des fichiers de formulaire entre différentes versions. Pour autant que je sache, il n'est pas possible d'ajouter des définitions conditionnelles dans le fichier dfm. Mais encore une fois, le voulons-nous vraiment? Je préférerais un mécanisme qui ignore les propriétés inconnues.

4

Les projets Delphi ont toujours été extrêmement faciles à transférer vers de nouvelles versions. Vous devez être plus prudent, mais utiliser le code actuel avec des compilateurs plus anciens est assez simple, aussi. J'ai maintenu le code dans Delphi 2005/2006/2007 que d'autres personnes avaient encore besoin d'utiliser dans Delphi 6 et 7.

Si vous supprimez les propriétés incompatibles des DFM, elles devraient fonctionner correctement dans les anciennes versions sans les endommager pour Delphi 2009. Le plus grand exemple est les propriétés explicites * introduites dans Delphi 2006. J'ai un "DFM scrubber" brassé à la maison qui les enlève. Rappelez-vous, ces propriétés existent pour une raison, vous devriez donc seulement nettoyer celles que vous avez l'intention d'être rétrocompatible. Vous pouvez également envisager d'investir dans des outils d'analyse de code statique tels que CodeHealer ou Pascal Analyzer. En plus de signaler les problèmes (en particulier CodeHealer) et de vous aider à nettoyer votre code, vous pouvez choisir la version de Delphi à analyser, ce qui facilite la recherche d'incompatibilités en dehors des propriétés DFM. Et ils peuvent être automatisés dans le cadre de votre processus de construction.

Juste une note. Partagez le code source, mais gardez des projets séparés pour chaque version. Ceci est particulièrement important entre Delphi 2007 et Delphi 2009. Le fichier .dproj plus récent utilise la même extension, mais n'est pas compatible avec Delphi 2007. Vous pouvez également rencontrer des problèmes avec des ressources incompatibles.

+0

Je ne suis pas d'accord que les projets Delphi port facilement. J'ai fait des migrations dans le passé et il semble que la plupart des composants/contrôles nécessitent au moins des changements mineurs, souvent importants. Ceci est comparé à dire qu'un projet en C# fait dans Visual Studio est bien pire. –

+0

Votre expérience a été différente de la mienne, alors. Depuis Delphi 1, je ne pense pas avoir travaillé sur un seul projet qui n'a pas été déplacé au moins une fois. Cela a presque toujours été très simple. Je peux même recompiler plusieurs d'entre eux dans les versions précédentes. –

+0

Les problèmes que j'ai eu ont été confinés à mon code pour contourner les bogues VCL. Ensuite, quand une nouvelle version sort, je dois parfois annuler les solutions de contournement, puis trouver et mettre en œuvre des correctifs pour tous les nouveaux bogues VCL. Mais la compatibilité sous-jacente d'une version à l'autre est excellente dans Delphi. –

2

Vous pouvez ajouter en toute sécurité les propriétés dans le code de votre méthode OnCreate pour le formulaire et envelopper un {$ IFDEF VER200} // NEW PROPERTIES {$ ENDIF} autour d'elles. Vous pouvez laisser DoubleBuffered en dehors de l'ifdefs, car il était présent dans Delphi 2007, mais pas disponible pour l'inspecteur de propriétés.

Vous n'aurez à vous soucier que des propriétés que vous avez définies par défaut. Pour doublebuffered, vous ne devez vous inquiéter à ce sujet que si elle est définie sur true.Lorsque vous chargez le formulaire Delphi 2009 dans Delphi 2007, vous recevrez un avertissement indiquant qu'une propriété va être détruite. Notez simplement ces propriétés, car ce sont celles dont vous aurez besoin. J'utilise juste une telle méthode pour migrer mon code vers Delphi 2009 à partir de Delphi 2006. La plupart de mes projets contiennent plusieurs unités partagées et doivent compiler en Delphi 2006 pour la version d'expédition et Delphi 2009 pour la "prochaine" version. Je fais aussi beaucoup d'utilisation du {$ IFDEF UNICODE} pour définir où je dois m'assurer qu'une chaîne est large, ou en fonction de la routine.

14

DoubleBuffered est dans TWinControl depuis un certain temps maintenant. La différence dans Delphi 2009 est qu'il est publié maintenant. Si vous pouvez vivre avec seulement ignorer les erreurs (et ne pas faire les propriétés de travail à la place), voici une solution:

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. 

changer ensuite les déclarations des formulaires dans votre projet d'hériter de TDelphi2009Form, par exemple:

type 
    TFormMain = class(TDelphi2009Form) 
    ... 

Ceci fonctionnera à l'exécution - les erreurs de propriété seront ignorées. Pour le faire fonctionner au moment de la conception, aussi, créer un package de conception seule, ajouter designide.dcp à sa clause requires, et ajoutez l'unité suivante à elle:

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. 

Installez le package dans Delphi 2007 IDE et la propriété les erreurs pour les propriétés DoubleBuffered et ParentDoubleBuffered seront ignorées automatiquement lors de l'ouverture de vos formulaires dans l'EDI. Les valeurs des propriétés seront perdues lorsque vous enregistrez le formulaire dans Delphi 2007, vous devez donc les initialiser en code à la place.

EDIT: J'ai ajouté le code à la sortie des messages d'erreur du lecteur à la fenêtre Messages IDE:

IDE error messages

+0

+1 pour l'observation simple que la propriété existe avant D2009. Je ne le savais pas. Je suis maintenant capable de corriger certains problèmes en l'activant au moment du chargement, dans FormCreate. Très utile! –

Questions connexes