Discussion :

[Thierry Laborde]

Bonjour,

Et du coup est-ce que les options dans Menu Projets/Options/Application/Manifeste/Reconnaissance DPI changent quelque chose (En jouant sur les différentes options) ?

[BigBisous1013]

Bonjour,

Il y a pourtant moultes améliorations.
Je ne parle pas de la partie visuelle (quoique dans l'ensemble j'apprécie) des variables inlines (je trouve cela encore trop iconoclaste à mon goût, il me faudra du temps pour m'y faire). Bref, en gros des améliorations visibles. Mais je parle plutôt du nombre de bugs corrigés (par exemple le drag and drop) ou des améliorations de la RTL.

Un autre dinosaure

Je révise un peu mon jugement
Après un long moment sur l'nterface, j' ai retrouvé mes "anciens" mécanismes.

Pour les variables INLINE je trouve que ce n'est pas une avancée.
C'est du Basic ou du PHP etc, on met ce que l'on veut et surtout n'importe-où.
Sur une petite appli pouquoi pas? Mais les effets de bord merci.
Pour ceux qui ne retrouvent pas leurs variables je signale que les fonctions de plus d'une page-écran sont ( étaient ) déconseillées. Merci pour la programmation au kilomètre

Bonne journée à tous

Un dinosaure

[Andnotor]

Et du coup est-ce que les options dans Menu Projets/Options/Application/Manifeste/Reconnaissance DPI changent quelque chose (En jouant sur les différentes options) ?

Pas dans ce cas-là.

L'information comme quoi le DPI à changé est bien propagée aux sous-composants mais ceux-ci ne la gèrent que partiellement, voire pas du tout dans le cas du TSplitView.

Il suffirait de ceci :

Code :

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

1
2
3
4
5
6
7
8
9
procedure TCustomSplitView.ChangeScale(M, D: Integer; isDpiChange: Boolean);
begin
  inherited;
 
  CompactWidth  := MulDiv(CompactWidth, M, D);
  OpenedWidth   := MulDiv(OpenedWidth, M, D);
  AnimationStep := MulDiv(AnimationStep, M, D);
  ...
end;

[Invité]

Pour les variables INLINE je trouve que ce n'est pas une avancée.
C'est du Basic ou du PHP etc, on met ce que l'on veut et surtout n'importe-où.

on peut enfin faire

Code :

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

for var I := 1 to 10 do ...

[skywaukers]

Bonjour,

on peut enfin faire

Code :

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

for var I := 1 to 10 do ...

oui c'est peut-être le cas le plus parlant. Mais globalement je ne trouve pas que ce soit une avancée (ceci dit si ça peut faire venir des développeurs d'autres horizons, alors je l'accepte bien volontiers). Mais puisqu'il semble qu'on préfère aujourd'hui de grande méthodes à des petites fonctions (ce que laisse penser le fait qu'on préfère pouvoir déclarer la variable où on se trouve plutôt que de remonter la déclarer), ben je pense que c'est une fausse bonne idée. Lorsqu'on va relire notre code dans un an (ou plus), que la déclaration sera noyée dans une longue méthode, on trouvera surement ça moins clair que de pouvoir la trouver à un endroit précis, du moins c'est mon avis personnel.
Après il existe des add-on gratuits comme CnPack qui facilitent la déclaration d'une variable à son emplacement et de revenir d'un coup là où nous étions. Je crois même qu'il y a une solution intégrée à l'IDE maintenant pour faire ça encore plus simplement.

La vraie nouveauté de cette fonctionnalité par contre c'est (si j'ai bien tout suivi) l'ajout d'un niveau de portée puisqu'une variable déclarée à l'intérieur d'une itération ne sera visible qu'à l'intérieur de cette itération, notion qui n'existait pas avant.

@++
Dany

[pprem]

Bonsoir Dany

En tant que bonne pratique, je te rejoins dans le sens où il est préférable de déclarer ce que l'on utilise au même endroit que d'habitude.

En terme de simplicité de code et de relecture, je pense que c'est une bonne chose de ne plus devoir s'embêter à déclarer les variables qui ne servent que dans les itérations. Ca ne devrait pas perturber la lecture d'utiliser un "for var" plutôt qu'une déclaration en entête de fonction ou procédure et un "for" classique dedans.

[skywaukers]

Bonjour,

Bonsoir Dany

En tant que bonne pratique, je te rejoins dans le sens où il est préférable de déclarer ce que l'on utilise au même endroit que d'habitude.

En terme de simplicité de code et de relecture, je pense que c'est une bonne chose de ne plus devoir s'embêter à déclarer les variables qui ne servent que dans les itérations. Ca ne devrait pas perturber la lecture d'utiliser un "for var" plutôt qu'une déclaration en entête de fonction ou procédure et un "for" classique dedans.

Oui, nous sommes d'accord, déclarer une variable d'iération en haut de la méthode n'apporte pas de lisibilité au code. Je l'ai mal exprimé, mais je parlais surtout des autres cas de variable locales dont la déclaration peut être "noyée" au milieu du code de la méthode, surtout si cette dernière est volumineuse.

Bonne fêtes à tous !

@++
Dany

[Charly910]

Bonjour,

pour ma part je considère que l'obligation de déclarer les variables au début des unités, fonctions et procédure est une force du langage Pascal (tout comme dans ADA par exemple).
C'est dommage de déroger à cette règle à mon avis.
A+
Charly

[Andnotor]

Je tombe sur un cas de var inline qui m'aurait bien arrangé (enfin, façon de parler) mais qui ne passe pas : le passage d'un argument tel que Test(0, var Dummy); pour une fonction du type function Test(Arg :integer; var Res :integer) :boolean;.

Erreur E2033 (Les types des paramètres VAR originaux et formels doivent être identiques). La variable est donc vue mais son type ne peut être déterminé (l'écrire var Dummy :integer ne change rien).

On peut bien sûr déclarer la variable avant ou surcharger la fonction pour qu'elle ne retourne rien mais un "argument anonyme" aurait été pas mal question simplification lorsque la valeur retournée n'est d'aucun intérêt pour la suite du code