Discussion :

[ShaiLeTroll]

TComboBox = class(FMX.ListView.TComboBox) contre TComboBox = class(TCombobox).

Autant la première forme que l'on désigne pour "Hack"/"Jacking" est un grand classique que l'on pratiquait déjà avec la VCL
Autant la seconde forme est clairement un bug du compilateur si il laisse passer cela, comme le dit ALWEBER et Andnotor c'est un incorrect car c'est le même identificateur TComboBox


Je ne sais pas comment le gestionnaire de flux arrivent à trouver via un truc genre FindClass la TComboBox local à la place de la Namespace.Unit.TComboBox
Cela reste pour moi un mystère
Par contre, on sait que cela fonctionne très bien et l'on peut hériter de "Namespace.Unit.TComboBox" car le nom complet est bien un identifiant différent du TComboBox local que l'on est en train de définir

Un petit QC pour dénoncer le TComboBox = class(TCombobox) serait bienvenu !
Et ce n'est pas que pour les controles,
On pourrait très bien définir par manque d'originalité définir une classe technique hérité de la RTL

Code :

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

1
2
3
4
5
type
  TObjectList<T: class> = class(System.Generics.Collections.TObjectList<T>)
  public
    function MethodeSuperSympaQuiManque(): T;
  end;

Et évidemment TObjectList<T: class> = class(TObjectList<T>) doit absolument pas pouvoir être compileé car TObjectList est le dernier déclaré (donc la classe en cours de définition et pas celle que l'on choperais via System.Generics.Collections)

Bonjour,

[Rio, FMX]

Quelqu'un pourrait-il m'expliquer pourquoi en passant par TCombobox = class(FMX.ListBox.TComboBox) j'accéde directement aux propriétés Count, Items, ItemIndex ?

Je pense que tu as la réponse à ta question
TCombobox = class(FMX.ListBox.TComboBox) grâce à la portée d'unité on peut accéder à tout membre protégé de FMX.ListBox.TComboBox (ça évidemment tu le savais)
TCombobox = class(TComboBox) est un code incorrect que le compilateur devrait refuser (ça c'est le piège dans lequel il t'a fait tomber et qui est finalement la cause de tout ce sujet à rallonge)

[blonde]

la sauce Patrick Prémartin

Ca y est, il a son nom de marque en propre, bravo Patrick


Autrement, je suis ce topic avec beaucoup d'intérêt.

[Andnotor]

C'est vraiment une question de compilateur, la façon dont il traite le script. En soit, TComboBox = class(TCombobox) ne paraît pas illogique du fait de la clause uses. Mais il semble pour une fois que la partie gauche est traitée avant la droite

Il y a d'autres cas qui pourraient être tout aussi litigieux à l'instar de :

Code :

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

1
2
3
4
5
 
type
  PTruc = ^TTruc;
  TTrunc = record
  end;

puisqu'on défini un pointeur typé sur un type pas encore déclaré. Mais ça passe !

Soit le compilateur FMX suit le comportement de celui VCL et il génère une erreur (dans ce cas, c'est une erreur dans le compilateur) ou il y a évolution et il devrait effectivement prendre en compte la clause uses (ce serait une lacune dans le compilateur qui devrait être corrigée).

[SergioMaster]

Bonjour,

ça y est, il a son nom de marque en propre, bravo Patrick

J'ai hésité sur le nom de la sauce, ça fait grand chef mais sauce pprem n'aurait pas été mal non plus

Autant la seconde forme est clairement un bug du compilateur s’il laisse passer cela, comme le dit ALWEBER et Andnotor c'est un incorrect car c'est le même identificateur TComboBox

Tout d'abord, je tiens à signaler que j'utilisai la forme TComboBox = class(FMX.ListView.TComboBox), c'est lors d'une relecture technique que la question s'est posé du pourquoi cette forme et non TComboBox = class(TCombobox).. Suite à cette remarque j'avais donc testé la seconde forme qui, fait beaucoup couler d'encre numérique, est acceptée par le compilateur (s'il s'agit de FMX).
En tout cas, ce qui me rassure c'est que, d'après tes dires, la première forme utilisée au départ n'est pas si iconoclaste que ce que je le croyais (ouf)

Merci Shai

Un petit QC pour dénoncer le TComboBox = class(TCombobox) serait bienvenu !

Oserai-je ?

[ALWEBER]

1) Le fait de déclarer TCombobox = class(TCombobox) est une anomalie de programmation qui ne devrait pas exister. De ce fait Delphi ne pouvant résoudre cette egalité le traduit par TCombobox = class(Tobject) donc l'ancêtre primordial. Donc dans la complétion du code on ne voit que les éléments du TObject et pas les counts, items et autres.
2) J'ai refait les tests le comportement est bien le même en VCL et FMX. Donc ne pas accuser à tord FMX puisque le compilateur est le même pour les deux univers

Code :

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

1
2
3
4
5
6
7
  TComboBox = class(TCombobox) ;
var
  Form1: TForm1;
  v1 : TComboBox ;
implementation
{$R *.dfm}
  v1.

3) Delphi n'accepte pas que deux composants aient le même nom. Donc si on veux quand même le faire il faut retirer le composant du même nom du package de base de Delphi et mettre le sien à la place. Mais dans ce cas le programme sera peu portable. Il est possible aussi une déclaration au début de chaque programme du type : TComboBox = class(Vcl.StdCtrls.TCombobox)... En forme de surcharge . Dans ce cas ce type local au programme est prioritaire et un class helper fonctionne bien.
4) Les visibilités Private, Protected, Strict private et Strict Protected sont sans effet au sein d'une même unité, ce qui explique certains comportement

Un autre exemple

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
unit ex05f_accesPrivate1;
interface
uses  Classes ;
type
  TMaClasse = class
  private
    fv1: integer;
  public
    property v1: integer read fv1 write fv1;
    function fRetourneValeurPlusUn: integer;
  end;
implementation
function TMaClasse.fRetourneValeurPlusUn: integer;
begin
  result := fv1 + 1;
end;
end.
//--------------------------------------------------
program ex05f_accesPrivate;
{$APPTYPE CONSOLE}
{$R *.res}
uses
  System.SysUtils,
  ex05f_accesPrivate1 in 'ex05f_accesPrivate1.pas';
type
  TAccesPrive = class(TObject)
  private
    fv1: integer;
  end;
  TMaClasseDescendante = class(TMaClasse)
  public
    procedure IncrementeValeurPlusUn;
  end;
 
procedure TMaClasseDescendante.IncrementeValeurPlusUn;
begin
  TAccesPrive(TMaClasse(self)).fv1 :=
  TAccesPrive(TMaClasse(self)).fv1 + 1;
end;
 
var
  aClass1X: TMaClasseDescendante;
 
begin
  aClass1X := TMaClasseDescendante.Create;
  aClass1X.v1 := 3;
  aClass1X.IncrementeValeurPlusUn;
  writeln(aClass1X.fRetourneValeurPlusUn.ToString);
  aClass1X.Free;
  readln
end.

[ShaiLeTroll]

Il y a d'autres cas qui pourraient être tout aussi litigieux à l'instar de :

Code :

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

1
2
3
4
5
 
type
  PTruc = ^TTruc;
  TTruc = record
  end;

puisqu'on défini un pointeur typé sur un type pas encore déclaré. Mais ça passe !

Oui, c'est une bonne grosse exception à la règle le coup de pointeur avant
D'ailleurs en D6, je me souviens de Crash de l'EDI quand je saisissais, oui je faisais l'erreur de mettre un T au lieu du P (ou cas d'un copier coller)

Code :

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

1
2
3
4
5
 
type
  TTruc = ^TTruc;
  TTruc = record
end;

[ALWEBER]

Oui, c'est une bonne grosse exception à la règle le coup de pointeur avant

Code :

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

1
2
3
4
5
 
type
  TTruc = ^TTruc;
  TTruc = record
end;

Non ce n'est pas une exception. Il fait partie de la définition d'origine du langage Pascal donnée par Niklaus Wirth au même titre que la définition de type "Forward"

[SergioMaster]

Bon, je crois que l'on en a fait le tour, je ferme la discussion (j'ai découvert cette possibilité) avec un résolu en prime