Discussion :

[SergioMaster]

Bonjour,

tout est dans le titre mais je vais être plus précis.

Je crée un composant dérivé de TBitmap

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
type
  [ObservableMember('NomFichierImage')]
  TFileNamedImage = class(TImage)
  private
    FNomFichierImage : TFileName;  // ajout de la propriété
    procedure ObserverToggle(const AObserver: IObserver; const Value: Boolean);
  protected
    function CanObserve(const ID: Integer): Boolean; override;
    procedure ObserverAdded(const ID: Integer; const Observer: IObserver); override;
    procedure DrawImage(Value : TFileName);
  published
    property NomFichierImage : TFileName read FNomFichierImage write DrawImage;
  end;

Jusque là rien de plus simple, seulement au design je ne voudrai pas voir la propriété MultiresBitmap du parent, comment dois-je m'y prendre ?

[retwas]

Tu ne peux pas réduire la visibilité d'une propriété.

La seule solution que j'ai trouvé pour l'instant c'est d'avoir une classe qui contient mon objet et ou je publie uniquement les propriétés que je veux..

[SergioMaster]

L'utilité de faire une unité Runtime et une autre pour le Design se confirme !
Dans l'unité de design

préalable, il faut indiquer que le paquet requiert designide.dcp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
unit FMX.Tutoriel;
 
interface
 
uses System.SysUtils, System.Classes,
     Data.Bind.Components,
     DesignIntf,                     // pour UnlistPublishedProperty
     FileNamedImage;
 
procedure Register;
 
implementation
 
procedure Register;
begin
  RegisterComponents('Tutoriel', [TFileNamedImage]);
end;
 
initialization
 // cache la propriété 
  UnlistPublishedProperty(TFileNamedImage, 'MultiresBitmap');  
 // affiche dans le concepteur de lien visuel (dommage, une seule propriété possible)
  Data.Bind.Components.RegisterObservableMember(TArray<TClass>.Create(TFileNamedImage), 'NomFichierImage', 'FMX'); 
 
finalization
 // déréférence 
  Data.Bind.Components.UnregisterObservableMember(TArray<TClass>.Create(TFileNamedImage));
end.

[SergioMaster]

Bonjour,

je croyais avoir trouvé la solution pour cacher la propriété mais

Comme le montre l'image je retrouve toujours celle-ci dans le panneau structure
en soit c'est pas gênant mais c'est un peu fort de café !

D'un autre côté, TImage de FMX, beaucoup plus complexe que le TImage VCL, utilise un interface (IMultiResBitmapObject)
donc sauf à dériver ma classe de manière beaucoup plus compliquée je ne vois pas comment je pourrais cacher la propriété dans la structure

[gvasseur58]

Bonjour Serge,

Comme l'a indiqué retwas, tu ne peux pas réduire la visibilité d'une propriété. C'est une application stricte du principe SOLID selon lequel les éléments de programmation doivent être ouverts à l'extension , mais pas à la modification (Open/closed principle). Avec ta technique de contournement, tu contreviens à un autre principe SOLID, à savoir que les objets doivent pouvoir être remplacés par des instances de leurs sous-types sans altérer la correction du programme (Liskov substitution principle) : en effet, en faisant disparaître artificiellement une propriété, tu interdis à l'ancêtre (ici, ta classe TImage) d'être remplacé par son descendant, car tu courrais le risque d'avoir utilisé une propriété devenue inaccessible puisque soustraite.
Moralité : en théorie d'une bonne POO, la démarche n'est pas recevable .

Maintenant, la difficulté tient aussi à l'architecture même du framework qui n'est pas toujours bien pensée et qui conduit à chercher des "trucs" pour en contourner les défauts. C'est le problème avec la POO : la moindre faiblesse dans l'architecture et les problèmes s'accumulent. Avec FireMonkey, le composant TImage descend directement de TControl en implémentant deux interfaces (IBitmapObject et IMultiResBitmapObject). Avec la VCL, TImage descend directement de TGraphicControl, une classe moins généraliste que TControl, mais à peine puisqu'elle s'occupe surtout du canevas. Dans cette hiérarchie, il manque une classe intermédiaire qui implémenterait tout ce qu'il faut, mais sans forcément le rendre publique : ce serait une classe TCustomImage. Ce que je dis n'est pas une abstraction puisque c'est le choix fait par les concepteurs de la LCL de Free Pascal . Comme ils ont été d'emblée confrontés à des plates-formes différentes, cette sorte de classe intermédiaire s'est sans doute imposée d'elle-même.

Bonjour,

je croyais avoir trouvé la solution pour cacher la propriété mais

Comme le montre l'image je retrouve toujours celle-ci dans le panneau structure
en soit c'est pas gênant mais c'est un peu fort de café !

D'un autre côté, TImage de FMX, beaucoup plus complexe que le TImage VCL, utilise un interface (IMultiResBitmapObject)
donc sauf à dériver ma classe de manière beaucoup plus compliquée je ne vois pas comment je pourrais cacher la propriété dans la structure

[SergioMaster]

Bonjour Gilles,

Bon c'est clair cependant je ne voulais pas (pour le tutoriel en cours Livebindings : Composants observables , partie que tu n'as pas encore pu lire) rajouter en complexité en créant une classe intermédiaire.
Donc soit j'abandonne l'idée de cacher la propriété peu gênante au design soit je colle tes explications soit ?
du coup, je ne sais pas si, une fois des Multires indiqués, il ne va pas y avoir un problème avec mon chargement d'image en FMX (Bitmap.LoadFromFile)

NB. ajouter en complexité ne me parait pas une solution acceptable car je voulais par la suite fusionner FMX et VCL en un seul source

[gvasseur58]

Bonjour,

Je crains que les explications alourdisse le tutoriel. En fait, je vois deux solutions : tu ignores cette visibilité indésirable ou tu hérites d'un autre composant. Pourquoi ne pas partir de TPaintBox ? Il descend lui aussi de TControl (pour FMX), mais il est plus léger que TImage et n'utilise pas les deux interfaces dont celle qui te gêne. L'image n'est cependant pas permanente... Comme je ne sais pas exactement ce que tu veux montrer à travers cet exemple, je ne peux pas en dire plus . Bon courage !

[SergioMaster]

tu ignores cette visibilité indésirable

cela alourdira moins

[Invité]

Bonjour Serge,

il me semble qu'il est possible de pratiquer inversement comme on le fait avec Lazarus. On part toujours d'un TCustomAncêtre dont les propriétés sont "cachées" et on "valide" celles que l'on veut faire apparaître. Il me semble avoir essayé avec un TCustomListView en XE7. J'ai rapidement abandonné mais autant que je me souvienne le problème n'était pas à ce niveau. Je ne sais pas si un TCustomBitMap existe. J'ai vaguement regardé sur le web mais évidemment je n'ai rien trouvé... ce qui ne prouve pas que cela n'existe pas.

Cordialement. Gilles

[gvasseur58]

Bonjour,

C'est la solution évoquée dans un de mes messages plus haut. Malheureusement, un TCustomImage n'existe pas .

Bien cordialement,

Gilles (aussi !)

Bonjour Serge,

il me semble qu'il est possible de pratiquer inversement comme on le fait avec Lazarus. On part toujours d'un TCustomAncêtre dont les propriétés sont "cachées" et on "valide" celles que l'on veut faire apparaître. Il me semble avoir essayé avec un TTCustomListView en XE7. J'ai rapidement abandonné mais autant que je me souvienne le problème n'était pas à ce niveau. Je ne sais pas si un TTCustomBitMap existe. J'ai vaguement regardé sur le web mais évidemment je n'ai rien trouvé... ce qui ne prouve pas que cela n'existe pas.

Cordialement. Gilles

[Invité]

Bonjour,

je me disais que FireMonkey était un environnement bien fermé comparé à Lazarus. En réalité, en Lazarus on pourrait copier la classe d'origine -celle qui dérange Serge-, rétrograder ses propriétés published pour aboutir à un "custom", puis recréer une nouvelle classe à partir de cette dernière modifiée en réactualisant les propriétés published souhaitées...et en recompilant Lazarus.

Ce serait cependant un cas d'école parce que la structure de Lazarus est bien faite, elle !

Bon ceci dit, le problème de Serge ne gène que les développeurs parce que l'Utilisateur ne le verra pas...

Cordialement. Gilles

[SergioMaster]

Bonjour,

En fait mon objectif est de faire simple, il serait tout à fait possible de créer une classe TCustomImage pour virer l'interface qui me gêne

Lazarus ce n'est que du VCL puisque Lazarus est un clone de Delphi 7. Je m'y suis attardé il y a longtemps (presque 10 ans déjà) et trouvait qu'à l'époque il y avait un manque criant de composant et puis il y avait cette histoire de en recompilant Lazarus, barbant.
Je ne suis pas sûr que Lazarus utilise les Interfaces dans ses composants non plus.

le problème de Serge ne gène que les développeurs

exact et encore ce n'est qu'un très petit effet de bord au moment du design mais je me disais qu'en cachant la propriété au design par UnlistPublishedProperty c'était pas mal, sauf que la propriété bien que plus listée est toujours visible (et modifiable) dans le panneau structure.

en théorie d'une bonne POO, la démarche n'est pas recevable

Cette sentence y met donc un stop

[Invité]

Oui,

bonne POO, il faudrait que les classes fournies le permettent facilement... ce qui n'est visiblement pas le cas dans ton cas. Lazarus, il y a belle lurette qu'il a dépassé son ancêtre. Il est parti effectivement de VCL mais maintenant il est largement supérieur dans nombreuses de ses approches même quand je le compare à Firemonkey. Mais je te l'accorde faute de moyen, il manque et manquera toujours de composants. Et par exemple, j'ai été incapable de faire des forms 'click through' dans les 3 OS alors qu'avec Firemonkey c'est très facile. Et ce n'est pas le nouveau mojave qui simplifiera la tâche des développeurs de Lazarus .

Remarque que même Qt est à la peine : je viens d'installer mojave et la dernière version stable de Qt (la 5.11.2). Premier test en compilation static OK mais

Project WARNING: Qt has only been tested with version 10.13 of the platform SDK, you're using 10.14.
Project WARNING: This is an unsupported configuration. You may experience build issues, and by using
Project WARNING: the 10.14 SDK you are opting in to new features that Qt has not been prepared for.
Project WARNING: E.g., 10.14 enables dark mode and layer-backed views, which Qt 5.11 does not support.
Project WARNING: Please downgrade the SDK you use to build your app to version 10.13, or configure
Project WARNING: with CONFIG+=sdk_no_version_check when running qmake to silence this warning.

Maintenant je n'ai plus qu'a essayer PAServer19.0.pkg pour voir comment cela fonction avec un Delphi community.

Bonne fin de journée. Gilles.

[SergioMaster]

A force de t'entendre parler de Lazarus, j'ai voulu en avoir le cœur net !
J'ai donc désinstallé mes anciennes version et, tant qu'à faire installé la version 2.0 RC histoire de voir de quoi il en retournait pour un TImage
histoire de comparer.

Delphi VCL Lazarus Delphi FMX
TImage = class(TGraphicControl) TImage = Class(TCustomImage) TImage = class(TControl, IBitmapObject, IMultiResBitmapObject)
TCustomImage = Class(TGraphicControl) deux interfaces
IBitmapObject étant plus ou moins la propriété Picture
IMultiresBitmapObject son nom est parlant

Delphi VCL il serait très facile de faire un peu à l'inverse de Lazarus un TCustomImage pour publier les propriétés de TImage
Ce qui, en FMX, devient plutôt galère : Faire un copier de TImage pour créer une nouvelle classe TCustomImage(TControl, IBitmapObject) est bien évidemment possible. Cependant, pour un tuto que je veux simple et dont l'objectif n'est pas de créer un composant mais plutôt créer un composant observable par LiveBinding, il est évident que je ne vais pas le faire !

Lazarus, il y a belle lurette qu'il a dépassé son ancêtre.

Ce serait malheureux, si depuis le début des années 2000 il était resté le même mais je retourne ta phrase
Delphi, il y a belle lurette que Delphi 7 est dépassé, malgré quelques déboires épiques comme D8 il a fait mal celui là !

Maintenant si je regarde plus spécifiquement le composant Timage, ma cible, je suis plutôt déçu (pas d'interface). Cela étant en faisant du ligne par ligne pour comparer Delphi TImage et Lazarus TCustomImage effectivement il y a plus de possibilité/fonctionnalité/propriété (je ne sais pas trop comment définir exactement.

[Paul TOTH]

Bonsoir,

Que cherches tu à faire exactement ? car quand on dérive de TImage c'est qu'au départ on veux un TImage, et sans sa propriété MultiResBitmap il ne sert pas à grand chose...peut-être dois-tu simplement dériver d'autre chose...quitte à utiliser en interne un TImage si besoin est.

après dire que FMX est mal conçu, il est surtout conçu très différemment de la VCL, notamment tout composant peut être parent d'un autre, c'est ce que je réclame pour la VCL d'ailleurs

[SergioMaster]

Bonjour,

Que cherches tu à faire exactement ? car quand on dérive de TImage c'est qu'au départ on veux un TImage,

En fait l'objectif n'est pas tant de faire un composant TImage autre que de rajouter une propriété observable (livebindings) : un nom de fichier (par nom j'entends chemin complet pour windows, nom du fichier pour androïd ou tout autre truc du même genre)
Il me fallait un exemple plus parlant que le TObservableTrackBar du docwiki et utilisant beaucoup d'image à mon boulot (stockées hors BDD) je me suis dit pourquoi pas lier le nom de l'image stockée dans ma BDD avec une propriété (en fait c'est assez souvent demandé dans le forum)

J'ai d'abord fait la chose pour VCL puis la même chose pour FMX ça, pas de soucis. Ce qui est intéressant c'est que la démarche est quasi identique entre les deux et permet d'envisager le "une unité deux frameworks" pour un "même" composant


C'est au moment du design (et uniquement) que je trouvai que les propriétés Picture pour VCL, MultiresImage pour FMX pouvaient (peut-être) perturber le programmeur car, du coup, au design on peut changer aussi bien le nom de l'image que l'image chargée des propriétés citées.
En soit rien de gênant, je pense même que, pour FMX cela peut être un atout genre image par défaut car c'est dans la propriété image que se charge le fichier pour VCL par contre c'est "juste une image au démarrage" puisque Picture est modifiée par la suite.
Comprenons nous bien, je ne veux pas que mon composant n'ai plus la propriété MultiresBitmap (bien que peu utile) juste qu'elle ne soit plus visible au design.

Donc, ce que j'ai testé c'est

• pour FMX UnlistPublishedProperty(TFileNamedImage, 'MultiresBitmap');
• pour VCL UnlistPublishedProperty(TFileNamedImage, 'Picture');

permettant de cacher ces propriétés, au design uniquement, à l'inspecteur d'objet, à mon avis les règles de POO ne sont pas bafouées (mais à l'époque de ma formation les Objets étaient tout juste une graine)
Tout allait donc bien dans le meilleur des mondes jusqu'à ce que je vois dans le panneau structure, réapparaitre ce MultiresBitmap (cf Image post #4)

C'est donc, une toute petite tempête dans un verre d'eau pour un "confort" très relatif rien de plus
comme l'indiquait Gilles (selzig) l'utilisateur final n'en verra rien. Je suis certainement le type d'artisan qui donne un coup de lime sur des pièces qui seront toujours invisibles

[Paul TOTH]

Alors je n'ai pas creusé plus loin, mais il y a peut-être quelque chose à faire au niveau des TSprig, j'ai découvert cela en implémentant mon TGraphicPanel

https://github.com/tothpaul/Delphi/b...gister.pas#L84

en créant un TSPrig pour ton image il est peut-être possible de masquer ses enfants ... à vérifier, mais c'est une piste, moi j'en avait besoin pour gérer le drag&drop et permettre à un TGraphicControl d'être parent d'un autre

[SergioMaster]

Intéressant et à fouiller ces TSprig !
Je n'avais aucune idée de leurs existences du coup encore des liens qui conduisent à d'autres liens et vidéos
Conclusion : à fouiller pour élargir mes connaissances mais que je vais écarter pour l'instant pour l'objectif est de rester simple pas de rajouter une couche de nouveauté