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


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


33
2018-06-06 14:29


origen


Respuestas:


Esos números no son completamente inútiles. Digamos que tienes clases TA, TB y TCy TB y TC ambos 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 su X y Y los subcomponentes se invierten. El significado preciso del orden de los subcomponentes depende de los componentes (ver a continuación), pero más notablemente, si están TWinControl descendientes, o ambos TControl descendientes que no derivan de TWinControl, eso significa que difieren en si X se muestra sobre Y, o Y encima 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) TControl descendientes que no derivan de TWinControl, entonces (2) TWinControl descendientes, finalmente (3) cualquier no-TControl componentes. 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 no-TWinControl nunca se puede poner después de una 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 base a derivada, por lo que en el caso anterior, cuando TC es creado, es X miembro es siempre creado antes de su Y miembro. los [0] y [1]son necesarios para decirle 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 utilizan 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.


33
2018-06-06 14:41