2012-06-11 6 views
8

Si deseo reemplazar un componente VCL TXxx ¿debo basar mi componente en TXxx o TCustomXxx?¿Qué clase de base usar al desarrollar el componente Delphi VCL?

Busco para hacer reemplazos directos para varios componentes de edición de texto (TEdit, TMemo, etc.) para los manipuladores tienen WM_PASTE para sanear entradas a un back-end que es muy exigente con lo que aceptará (básicamente solo glifos imprimibles ASCII de 7 bits, espacios y pares CR/LF ... incluso los caracteres de pestañas no son aceptables). Estos nuevos componentes tienen que ir a una aplicación existente, y no quiero hacer nada que no sea absolutamente necesario para que funcionen exactamente como lo hicieron los antiguos, a excepción del comportamiento de pegado no predeterminado.

He hecho uno basado en TMemo y parece funcionar, pero de alguna manera tengo la impresión de que el enfoque recomendado sería usar TCustomMemo. ¿Hay algo que este olvidando?

Respuesta

16

Por convención, la diferencia entre TSomething y TCustomSomething es que este último tiene pocas o pocas propiedades publicadas para que pueda elegir cuáles publicar usted mismo. De lo contrario, no debería haber ninguna diferencia.

+0

Gracias, eso es lo que esperaba escuchar. – wades

0

TObject -> TPersistent -> TComponent -> TControl -> TWinControl -> TCustomEdit -> TCustomMemo -> TMemo

enter image description here

TMemo es sólo un 'envoltorio' para el control TCustomMemo. Puede usar ambos, pero me gusta usar la versión personalizada porque se deriva de un componente no visual.

Si desea reemplazar componentes en proyectos futuros, puede construir un módulo de datos alrededor del control y administrar sus propiedades dentro del módulo de datos. Después de reemplazarlo, solo tiene que cambiar la forma en que el módulo de datos maneja el componente y no todos los componentes de su proyecto.

-1

Otra opción sería simplemente una subclase de los respectivos componentes de esta manera:

unit SubClassedControls; 

interface 

uses StdCtrls, Messages; 

type 

    TEdit = class(StdCtrls.TEdit) 
    private 
    procedure WMPaste(Message: TWMPaste); message WM_PASTE; 
    end; 

implementation 

{ TEdit } 

procedure TEdit.WMPaste(Message: TWMPaste); 
begin 
    // do whatever is necessary 
end; 

end. 

entonces es importante añadir los SubClassedControls unidad detrás de la unidad StdCtrls en la cláusula usos de la forma. Al hacer esto, puede continuar utilizando los controles estándar existentes, pero en el tiempo de ejecución su aplicación usará realmente los controles subclase. En caso de que tenga una aplicación existente con muchos controles, esta podría ser una manera más fácil de cambiar el comportamiento de sus controles.

+0

-1 porque no leyó la pregunta. Sugieres que hagas exactamente lo que estaba hablando, y no le prestaste atención a la parte que no entendí. – wades

+0

@wades, lo siento, mi respuesta fue solo en respuesta a "... y no quiero hacer nada que no sea absolutamente necesario para hacer que funcionen exactamente como lo hicieron los antiguos, a excepción de los que no comportamiento de pegado predeterminado. ".Y todavía creo que mi solución es de lejos la más simple para su problema en cuestión. Por supuesto, puede intercambiar cientos de controles con su propio TMyEdit derivado de TCustomEdit, etc., pero esto es mucho más engorroso. – iamjoosy

1

La manera en que siempre he entendido el concepto de tener TSomething y TCustomSomething es cuando se crea su propia herencia de, digamos TButton a su propia llamada TMyBytton. Supongamos que desea ocultar una propiedad, como Caption (suponiendo que no desea texto). Con el TButton, no puede ocultar esta propiedad. Pero utilizando un TCustomButton, puede publicar las propiedades que desee que sean visibles en el inspector de objetos y excluir aquellas que no desea ver. Una vez que se ha publicado una propiedad, no se puede deshacer en otras clases heredadas.

Cuestiones relacionadas