La Voie Du Code

Sometimes I miss the embedded procedures feature of Object Pascal. OOP purists will throw a fit at this, but I know that the true Delphi fans will smile. Here’s the one liner delegate declaration required to implement subprocedures in C#:

/// <summary>
/// Use this delegate to simulate a pascal sub procedure i.e.
/// 
/// void OuterFunc() {
///     SubProcedure InnerProc = delegate() { ... };
/// 
///     ...
///     InnerProc();
///     ... 
///     InnerProc();
///     ...
/// }
/// </summary>;
public delegate void SubProcedure();

<french>

Les vrais fans de Delphi et de la programmation structurée conviendront avec moi que les sous-procédures sont bien cools. La simple déclaration de delegate décrite plus haut suffit pour émuler cette construction en C#.

</french>

Article original: Stopwatch class from .net 2.0 framework ported .net 1.1

Cette classe permet d’effectuer des timings très précis, cf. System.Diagnostics.Stopwatch.

Ma version Delphi.net (framework 1.1) est ici.

Décidément je commence a détester sérieusement la gestion des namespaces par Delphi.net. Dans le cas du paramétrage du remoting .net à travers par exemple, on peut déclarer des types distants dans un fichier de configuration XML. Cela se fait à travers des tags <activated> ou <wellknown> pour lesquels on donne dans l’attribut “type” le nom de la classe et de l’assembly. Ensuite un appel à RemotingConfiguration.Configure() suffit pour recenser le type.

Ainsi en Delphi.net lorsque votre classe TType est rangée dans l’unité Toto.MonModule et l’assembly Toto, voici ce qu’il faut écrire:

    <activated> type="MonUnité.TType, Toto" />

Il ne faut surtout pas inclure le nom de l’assembly dans le nom du type comme on serait tente de le faire si on suivait la logique pronée par Borland! Comme dans:

    <activated> type="Toto.MonUnité.TType, Toto" />

Ce niveau supplémentaire qu’est l’unité sent vraiment la verrue. Pour C# ou VB.net ou Chrome, cette notion d’unité n’existe pas et on aurait juste écrit:

    <activated> type="Toto.TType, Toto" />

Pour découvrir Delphi.net et avoir une vue d’ensemble d’ASP.net, j’ai porté le starter kit pour ASP.net appelé TimeTracker vers Delphi.net. Les starter kits sont des noyaux d’application créés par Microsoft pour donner un aperçu des possibilités d’ASP.net. Vous pouvez télécharger les versions originales pour le framework v1.1 sur le site www.asp.net.

Le résultat de mon portage est accessible ici.

Mes conclusions:

• .Net et ASP.Net, c’est cool.
• C# c’est pas mal du tout.
• Delphi.net ce n’est pas génial.

Pas grand chose à dire si ce n’est que j’ai réussi à reproduire dans Delphi.net 100% des fonctionnalités implémentées en C#, mais j’ai bien senti que le coeur n’y était pas du côté Delphien.

La mise en oeuvre des namespaces par exemple est réellement calamiteuse. En gros, dans Delphi.net un namespace n’est rien d’autre qu’un nom d’unité avec des points dedans! Par exemple vous définissez un type TToto dans une unité Toto dans le namespace VoieDuCode.Machin. Eh bien, pour pouvoir référencer ce type dans une autre unité il n’est pas possible d’écrire:

    uses VoieDuCode.Machin ...

Il faut absolument faire référence à l’unité:

    uses VoieDuCode.Machin.Toto ...

A travers ce genre de choses, on sent bien que .Net n’est pas un citoyen de première classe dans le monde Delphi…

Notez que l’Object Pascal concurrent pour .Net appelé Chrome propose un mécanisme de gestion des namespaces rigoureusement équivalent à celui de C#. Mais ceci sera le sujet d’un autre post…

Si j’avais le choix, je n’utiliserais pas Delphi comme langage dans le monde .Net. C# ou Chrome sont bien plus élégants et adaptés. Pour Win32 cependant, Delphi reste la meilleure solution, surtout que Borland propose un chemin de migration de Win32 a .Net à travers VCL.net.

XLReport d’AfalinaSoft est un composant impressionnant. Il permet d’utiliser des feuilles Excel comme modèles d’états dont les données sont issues de TDataSet Delphi. C’est simple et élégant et tellement puissant qu’ils l’ont décliné à toutes les sauces : contrôles .Net et ActiveX, générateur d’états pour l’utilisateur final. Au niveau déploiement, rien à ajouter au programme, tout est contenu dans le composant.

J’ai été particulièrement bluffé par le mécanisme de regroupement avec fusion des cellules contenant le même libellé.

Il y a un point sournois qu’il faut bien maîtriser, c’est la taille et la position des plages (« ranges ») qui permettent d’afficher les données multilignes. Pour éviter tout problème je donne la même taille à toutes les plages.

Attention aussi aux données regroupées dont les totaux en pied de tableau ne peuvent être référencés car il semblerait que le moteur supprime et recrée les cellules en question. Dans le cas des données non regroupées, les références fonctionnent très bien.

Certaines choses ne sont pas possibles à cause de l’Excel sous-jacent comme tout ce qui a trait à la pagination. Impossible par exemple de faire des reports de totaux d’une page à l’autre puisque l’on ne maîtrise absolument les sauts de page. En fait, il faut oublier les réflexes acquis à travers des générateurs d’états avancés comme Crystal Reports et profiter au maximum des fonctionnalités d’Excel comme l’activation de macros personnalisées ou la génération de tableaux croisés !