Blog de Gilles Vasseur - Pascal et compagnie

Voilà déjà plus d’un an que TMS Software, la société de Bruno Fierens, propose des bibliothèques innovantes dans la mesure où elles permettent au programmeur d’écrire un code unique pour générer des applications qui fonctionneront sur de nombreux systèmes d’exploitation, mais surtout compilables aussi bien par Delphi que par Lazarus. Elles introduisent ainsi la notion de composants neutres fonctionnant pour Windows, Max OSX, iOS, Android et Linux (avec ses dérivés comme Raspbian, par exemple), le tout via les compilateurs fournis par Delphi ou Lazarus.


Ces bibliothèques (FNC UI, FNC Blox et FNC Chart) reprennent en fait partiellement celles qui ont fait le succès de TMS Software. Le programmeur retrouvera ainsi les grilles, la gestion de planning, l’affichage visuel des arbres, les éditeurs, le traitement des listes et des textes, les sélecteurs, mais aussi les diagrammes et le traitement graphique des données.


Voici l’ensemble des composants proposés par FNC UI sur la palette de Lazarus :

Que le programmeur travaille avec les frameworks VCL, FMX ou LCL importe peu : il choisit la plateforme cible et son EDI, organise son interface utilisateur avec les composants fournis, élabore la partie métier, et compile… La base de code restera la même s’il désire modifier ses choix d’origine, car les méthodes et propriétés des composants proposés sont totalement identiques, quel que soit le framework utilisé.


La ressemblance des interfaces est parfaite. Voici par exemple le composant TTMSFNCRichEditor compilé pour Windows 10 64 bits avec la VCL, la LCL et FMX :

Afin d’obtenir les résultats escomptés, il faut évidemment tenir compte des impératifs d’une programmation moderne et des limitations du concept.


En premier lieu, le code doit être découplé au maximum en le rendant aussi peu que possible dépendant d’une condition particulière, sinon le risque est grand de rendre inopérantes des actions même simples. Il est ainsi impératif de bien séparer la partie interface utilisateur, gérée par les composants neutres, de la partie métier qui devra tenir compte à l’occasion du fonctionnement spécifique de la plateforme visée. Par exemple, Windows, Linux et Android n’ont pas la même façon de traiter un chemin d’accès ou un répertoire pour enregistrer ou lire un fichier.


Les compilateurs et les EDI ont eux aussi des particularités qui restreignent (un peu) la possibilité de fournir une base de code unique. La plus évidente tient au fait que la VCL utilise un fichier .dfm pour une interface utilisateur alors que FMX produit des fichiers .fmx et la LCL des fichiers .lfm, formats tous incompatibles entre eux. Les interfaces doivent par conséquent être produites pour chaque framework.


La seconde limitation tient aux espaces de nommage des unités suivant les frameworks utilisés. Afin de pouvoir enregistrer des classes aux noms identiques, il est en effet nécessaire de les faire évoluer dans des espaces de nommage différenciés. La bibliothèque a fait le choix de préfixer les unités par VCL., FMX., LCL (sans point pour une compatibilité ascendante).
Bruno Fierens propose une solution quasi évidente à ces problèmes, à savoir l’utilisation des directives de compilation avant la partie commune.


Pour les fichiers décrivant les fiches, il suffira de prévoir quelque chose comme :

Code Delphi :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{$IFDEF VCL}
 
  {$R *.dfm}
 
  {$ENDIF}
 
  {$IFDEF FMX}
  {$R *.fmx}
  {$ENDIF}
 
 
  {$IFDEF LCL}
 
  {$R *.lfm}
  {$ENDIF}

Pour ce qui est des espaces de nommage, on pourrait utiliser :

Code Delphi :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
uses 
 
  {$IFDEF VCL}
 
    VCL.TMSFNCPlannerBase, VCL.TMSFNCPlannerData, VCL.TMSFNCPlanner, VCL.TMSFNCCustomControl;
 
  {$ENDIF}
 
  {$IFDEF FMX}
    FMX.TMSFNCPlannerBase, FMX.TMSFNCPlannerData, FMX.TMSFNCPlanner, FMX.TMSFNCCustomControl;
  {$ENDIF}
 
  {$IFDEF LCL}
   LCLTMSFNCPlannerBase,  LCLTMSFNCPlannerData, LCLTMSFNCPlanner, LCLTMSFNCCustomControl;    
  {$ENDIF}

Dans les deux cas, le reste du code n’aura, en général, pas à être différencié suivant les frameworks.


Un dernier apport essentiel du concept de composant neutre est la possibilité d’utiliser du code graphique sans se préoccuper du framework. Les couleurs, le remplissage, les traits, les polices de caractères, tout est pris en charge automatiquement par une classe spécifique nommée TTMSFNCGraphics capable de dessiner de la même façon quels que soient le framework et la cible.


Bruno Fierens fournit ce bout de code comme exemple :

Code Delphi :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var
 
    gr: TTMSFNCGraphics;
  begin
    gr := TTMSFNCGraphics.Create(PaintBox1.Canvas);
 
    gr.Fill.Color := gcYellow;
    gr.Stroke.Color := gcGray;
 
    gr.DrawRectangle(0,0,100,20);
 
    gr.Font.Color := gcRed;
    gr.DrawText(2,0,100,20,'Hello world',false)
    gr.Free;
  end;

Il donnera toujours le résultat suivant :

Après cette partie théorique, je prévois bien évidemment une description plus précise des composants proposés. Affaire à suivre prochainement…