[Nombre] étranges dans les fichiers DFM Delphi - origine et nécessité?

Question

J'ai besoin de changer un grand nombre de Delphi composants définis dans un paquet de semblables dans un autre package. Beaucoup de grunt travail peut être fait en remplacement de texte (types de composants et propriétés) dans le DFM fichiers enregistrés au format texte, bien sûr.

J'ai cherché sur Stackoverflow et Google et je suis maintenant en adaptant le Felix Colibri DFM analyseur de http://www.felix-colibri.com/papers/colibri_utilities/dfm_parser/dfm_parser.html

Je tombe sur une option dans la DFM fichiers que l'analyseur étouffe sur: [nombre]s après le type de spécifications, comme ceci:

inherited DialoogEditAgenda: TDialoogEditAgenda
  ActiveControl = PlanCalendar
  Caption = 'Agenda'
  [snip]
  inherited PanelButtons: TRzPanel
    Top = 537
    [snip]
    inherited ButtonCancel: TRzBitBtn [0]  <== *here*
      Left = 852
      [snip]
    end
    object CheckBoxBeschikbaarheid: TRzCheckBox [1]  <== *here*
      Left = 8
      [snip]
    end
    inherited ButtonOK: TRzBitBtn [2]  <== *here*
      Left = 900
      [snip]
    end
  end
  inherited PageControl: TRzPageControl
    Left = 444
    [snip]
  end
  object PanelBeschikbaarheid: TRzSizePanel [2]  <== *here*
    Left = 967
    [snip]
  end
  object PanelScheduler: TRzPanel [3]  <== *here*
    Left = 23
    Top = 22
    [...]

Beaucoup de ces Smgf sont fortement héréditaire (j'ai dû m'adapter Colibri code pour que déjà), mais une petite application de test avec l'héritage échoué à produire le [nombre]s dans la DFM.

Ma question avant d'avoir à étendre l'analyseur de code: personne ne sait où ces [nombre]s viennent et, par conséquent, je peux peut-être enlever avant l'analyse de la DFM fichiers?

Merci

Jan

Answer 1

Ces nombres ne sont pas complètement inutiles. Disons que vous avez les classes TA, TB et TC, et TB et TC proviennent tous deux TA. La Sgf ressembler à:

object A: TA
  object X: TX
  end
end

inherited B: TB
  object Y: TY
  end
end

inherited C: TC
  object Y: TY [0]
  end
  inherited X: TX [1]
  end
end

B et C diffèrent en ce que l'ordre de leur X et Y - composants est inversé. La signification précise de cette sous-composante de l'ordre dépend des composants (voir ci-dessous), mais surtout, si elles sont à l' TWinControl de descendants, ou ils sont tous les deux TControl des descendants qui ne dérivent pas des TWinControl, ce qui signifie qu'ils diffèrent en ce que X est montré plus de You Y plus de X.

La suppression de ces numéros peuvent changer de formes, de sorte que vous ne devriez pas aveuglément faire. Toutefois, selon votre objectif, vous pourriez être en mesure de modifier l'analyseur (code source semble être disponible) pour simplement ignorer les chiffres.

L'ordre relatif des composants n'a généralement a généralement pas beaucoup d'importance, mais il existe quelques exceptions. Pour expliquer un peu plus en détail:

Pour les contrôles normaux, ceux-ci commencent par (1) TControl des descendants qui ne dérivent pas des TWinControl, puis (2) TWinControl descendants, enfin (3) la non-TControl composants. Dans chacun de ces cas, l'ordre relatif des composants est réglable: pour les contrôles, le "Porter à l'avant" et "arrière-plan" déplacer le contrôle autant que possible, avec la limitation que les non-TWinControl ne peut jamais être mis après un TWinControl. Pour les non-contrôle, l' (légèrement mal nommée) "l'ordre de Création" option vous permet de changer l'ordre. Donc, disons que vous avez deux étiquettes (A et B), deux contrôles d'édition (C et D), et un ensemble de données et de la source de données (E et F), vous pouvez obtenir l'ordre de l'être, par exemple, ABCDEF, BACDEF, ABDCFE, mais pas ACBDEF.

Cet ordre est conservé lors de l'enregistrement d'un fichier DFM: lorsque l'héritage visuel n'est pas utilisé, les composants simplement sauvegardées et chargées à nouveau dans l'ordre. Lorsque vous utilisez l'héritage, la DFM, les fichiers sont transformés à base de dérivés, de sorte que dans le cas ci-dessus, lors de l' TC est créé, son X membre est toujours créé avant sa Y membre. L' [0] et [1] sont nécessaires pour indiquer à l'Delphi RTL pour fixer l'ordre par la suite, dans les cas où l'ordre des composants questions.

Ce que le composant de commande ne fait dépend du type de composant. Comme le "faire front"/"arrière-plan" noms l'indiquent, les contrôles de l'utilisation du composant afin de spécifier l'ordre. Pour les autres types de composants, cela signifie que quelle que soit la composante veut dire. Par exemple, les menus peuvent utiliser le composant afin de spécifier l'ordre de leurs éléments de menu (du haut vers le bas). La barre d'outils contrôles pouvez utiliser le composant afin de spécifier l'ordre des boutons de barre d'outils, même lorsque ces boutons de barre d'outils ne sont pas eux-mêmes contrôles. Des ensembles de données utiliser le composant afin de préciser le champ de l'ordre, et donc aussi l'ordre par défaut des colonnes dans un TDBGrid.