Extraño[número] s en archivos Delphi DFM-¿origen y necesidad?

rename

Question

Necesito cambiar una gran cantidad de componentes Delphi definidos en un paquete a otros similares en otro paquete. Gran parte del trabajo pesado se puede hacer reemplazando texto (tipos de componentes y propiedades) en los archivos DFM, guardados como texto, por supuesto.

He buscado Stackoverflow y Google y ahora estoy adaptando el analizador DFM Felix Colibri de http://www.felix-colibri.com/papers/colibri_utilities/dfm_parser/dfm_parser.html

Me encuentro con una ''característica'' en los archivos DFM que el analizador atrapa: [number] s después de las especificaciones de tipo como esta:

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
    [...]

Muchos de estos DFM son muy heredados (tuve que adaptar el código de Colibri para eso), pero una pequeña aplicación de prueba con herencia no produjo los [número] s en el DFM.

Mi pregunta antes de tener que extender el código del analizador: ¿alguien sabe de dónde provienen estos [números] y, en consecuencia, puedo eliminarlos antes de analizar los archivos DFM?

Gracias

Ene

Answer 1

Esos números no son completamente inútiles. Digamos que tiene clases TA , TB y TC , y TB y TC ambas derivan de TA . Los DFM parecen:

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 y C difieren en que el orden de sus subcomponentes X e Y se invierte. El significado preciso del orden de los subcomponentes depende de los componentes (ver abajo), pero más notablemente, si son descendientes de TWinControl , o ambos son descendientes de TControl que no derivan de TWinControl , eso significa que difieren en si X se muestra sobre Y , o Y sobre X

Eliminar estos números puede cambiar las formas, por lo que no debe hacerlo ciegamente. Sin embargo, dependiendo de su objetivo, puede modificar el analizador (el código fuente parece estar disponible) para omitir los números.

El orden relativo de los componentes generalmente generalmente no importa mucho, pero hay algunas excepciones. Para explicarlo con más detalle:

Para los controles normales, los subcomponentes comienzan con (1) descendientes TControl que no derivan de TWinControl , luego (2) descendientes TWinControl , finalmente (3) cualquier componente que no sea TControl . En cada uno de estos, el orden relativo de los componentes es ajustable: para los controles, "Llevar al frente" y "Enviar al dorso" mueven el control lo más lejos posible, con la limitación de que un TWinControl que no sea TWinControl nunca se puede colocar después de un TWinControl . Para los no controles, la opción de "orden de creación" (ligeramente mal llamada) le permite cambiar el orden. Entonces, digamos que tiene dos etiquetas (A y B), dos controles de edición (C y D) y un conjunto de datos y fuente de datos (E y F), puede obtener que el orden sea, por ejemplo, ABCDEF, BACDEF, ABDCFE , pero no ACBDEF.

Ese orden se conserva cuando se guarda en un archivo DFM: cuando no se utiliza la herencia visual, los componentes simplemente se guardan y se vuelven a cargar en orden. Cuando utiliza herencia, los archivos DFM se procesan como base para derivada, por lo que en el caso anterior, cuando se crea TC , su miembro X siempre se crea antes de su miembro Y El [0] y el [1] son necesarios para indicar a Delphi RTL que corrija el pedido posteriormente, en aquellos casos en los que importa el orden de los componentes.

Lo que realmente hace el orden de los componentes depende del tipo de componente. Como sugieren los nombres "Traer al frente" / "Enviar al pasado", los controles usan el orden de los componentes para especificar el orden Z. Para otros tipos de componentes, significa lo que sea que el componente quiera que signifique. Por ejemplo, los menús pueden usar el orden de los componentes para especificar el orden de sus elementos de menú (de arriba a abajo). Los controles de la barra de herramientas pueden usar el orden de los componentes para especificar el orden de los botones de la barra de herramientas, incluso cuando esos botones de la barra de herramientas no sean en sí mismos controles. Los conjuntos de datos usan el orden de los componentes para especificar el orden de los campos y, por lo tanto, también el orden predeterminado de las columnas en un TDBGrid .