Alaska Xbase++

Le futur de Clipper est déjà là

Durant de longues années, les centaines de milliers d’utilisateurs de Clipper de part le monde ont attendu une solution réelle, fiable et pratique à l’un de leurs principaux problèmes : la migration à Windows. Pendant ce temps, nous avons assisté à un défilé de propositions qui, pour une raison ou une autre, n’ont pas fini de satisfaire les programmateurs de ce langage si répandu. CA-Visual Object, la solution de Computer Associates qui aurait du être la voie naturelle de migration, n’a pas été réalisé comme attendu, à cause de sa syntaxe complexe, de la compatibilité limitée avec Clipper et, pourquoi ne pas le dire, au peu d’intérêt qu’a montré Computer Associates pour ce produit.

D’autres alternatives, comme FiveWin et Clip4Win, qui prétendent attaquer le problème depuis le point de vue de la compatibilité comme prémisse, ne sont pas plus qu’une simple extension à ce que Clipper est capable d’offrir et, s’ils permettent de profiter d’une bonne partie du code, ils héritent aussi des limitations d’un produit comme Clipper conçu pour des environnement DOS. Bien que son utilisation procure une rapide migration à Windows (de 16 bits bien sûr), son évolution postérieure résulte compliquée, étant donné que l’architecture et le compilateur sur lequel ils se basent ne sont pas les plus adéquats.

De fait, beaucoup d’anciens utilisateurs de Clipper ont définitivement éliminé leurs applications DOS optant pour recommencer à nouveau, que ce soit en utilisant un langage xBase pour Windows, comme Visual FoxPro, ou en optant pour un nouvel environnement de développement radicalement différent, comme Delphi ou Visual Basic. Passé la longue période d’apprentissage de ces outils, il est évident que les nouveaux développements s’ajustent beaucoup plus à la demande actuelle des entreprises et des utilisateurs. Mais la transition est toujours difficile, et de nombreuses sociétés de développement ont souffert, et même succombé, devant ce changement.

La cause du désespoir des derniers programmeurs Clipper est centrée sur ce qu’il faut faire pour adapter leurs programmes DOS et entrer ainsi dans le monde Windows avant de perdre leur base actuelle installée. A ABOX nous recevons des appels et des messages quotidiennement, nous demandant conseil sur ce sujet, et dont la réponse n’est pas évidente… du moins pour le moment. C’est que, malgré que la demande puisse se résumer en un simple « nous voulons un Clipper pour Windows », aucune des solutions exposées antérieurement ne correspond à cet énoncé.

Xbase++ entre en jeux

Cela fait un peu plus de trois ans, nous avons eu connaissance de la disponibilité d’un outil compatible avec Clipper et qui permettait de créer des applications pour OS/2. Vu la faible implémentation d’OS/2 dans notre pays, nous n’avons pas prêté une grande attention, bien que ses caractéristiques soient prometteuses. Cet outil est Alaska Xbase++ et, par bonheur pour les utilisateurs de Clipper, depuis la fin 1997 il est disponible pour Windows 95 et Windows NT 4.0.

Devant le grand potentiel de ce produit nous avons décidé de contacter Alaska, la société allemande créatrice du produit, pour obtenir plus d’informations sur celui-ci et solliciter sa distribution en France. Au cours du mois de novembre, nous recevions la visite du directeur marketind d’Alaska, Jürgen Zugck, qui nous a décrit en détail les caractéristiques actuelles et futures de Xbase++, et de sa propre entreprise. A plus d’une occasion, nous avons rencontré des fabricants d’utilitaires qui travaillent avec seulement un ou deux programmeur. Nous avons été grandement surpris que l’équipe de développement de Xbase++ soit formée par plus de dix personnes (beaucoup plus que celles que disposent Computer Associates pour Clipper et Visual Objects), et par le compromis qu’Alaska a adopté pour ajouter des améliorations au produit dans les prochains mois. Curieusement Xbase++ est un produit mûr, étant donné que la première version vît le jour en 1993. Elle fonctionnait sous OS/2 pour une raison simple : OS/2 était l’unique système d ‘exploitation de 32 bits alors disponible. Le succès qu’à eu le produit dans son pays d’origine, et le grand intérêt éveillé à l’échelle mondiale dans les différents forums dédiés à Clipper, nous fait concevoir de grandes espérances pour Xbase++.

Mais, qu’est ce que Xbase++ et qu’est ce qui le différencie des autres alternatives offertes jusqu’à présent ? La réponse est immédiate : Xbase++ est un authentique et un efficace compilateur du langage Clipper pour environnements graphiques. Il ne s’agit pas d’un utilitaire qui ajoute quelque chose à Clipper pour le faire fonctionner sous Windows, sinon d’un nouveau compilateur totalement réécrit et adapté au nouveaux GUIs. Par conséquent, il est évident d’indiquer que Clipper n’est pas requis, vu que Xbase++ comprend son propre compilateur et éditeur de liens. D’autre part, Xbase++ respecte la syntaxe de Clipper lors du développement d’applications, ce qui garantit la compatibilité du code écrit et sa progressive adaptation aux interfaces graphiques. Mais voyons en détail tous ce que nous offre ce produit.

La syntaxe familière Xbase

Xbase++ est compatible au niveau du langage avec CA-Clipper, depuis la version Summer 87 jusqu’à la 5.2e. S’il existe bien de petits changements dans le code en relation avec le travail sous un environnement graphique, ceux-ci sont minimes et sont parfaitement documentés. La migration d’applications Clipper est, par conséquent, très facile. De la même façon, un certain degré de compatibilité est offert avec le code Xbase d’autres langages, comme FoxPro ou dBase, bien qu’il ne soit pas total.

Il faut être reconnaissant que Xbase++ supporte des caractéristiques comme le pré processeur, les codeblocks et la définition de macros, si naturels dans les programmes Clipper. De la même façon, son architecture de trois couches permet d’utiliser trois éléments caractéristiques en programmation : des commandes, des fonctions et des objets. Vous disposez d’une totale liberté au moment d’utiliser n’importe quel de ces éléments et d’adopter le modèle de programmation qui vous convienne le mieux, étant donné que le compilateur transforme des commandes, des fonctions et des objets de forme transparente.

Naturellement, les commandes propres à Clipper sont totalement supportées. Une application aussi facile que la suivante :

  USE CLIENTS INDEX CODE BROWSE( )

Montre un écran « browse » typique avec la base de données sélectionnée.

Puisque la fonction BROWSE() est propre au mode texte, cette petite application montrerait une fenêtre Windows avec le browse en format texte. En fait, on obtient après la compilation avec Xbase une authentique application Windows, bien que son aspect rappelle l’émulation d’un programme DOS. Une simple modification au code antérieur permet de disposer d’un browse graphique propre à Windows :

  USE CLIENTS INDEX CODE APPBROWSE PRENOM, NOM, ADRESSE, POPULATION

La commande APPBROWSE, incluse dans Xbase++ comme une alternative à BROWSE(), facilite la rapide et simple adaptation des applications à un environnement graphique.

Toutes les commandes se traduisent à des fonctions grâce au pré processeur de Xbase++. Vous pouvez combiner librement des commandes et des fonctions, ce qui permet d’écrire le programme antérieur de la façon suivante :

  DbUseArea("CLIENTS")
  DbSetIndex("CODE")
  APPBROWSE PRENOM, NOM, ADRESSE, POPULATION

Le dernier niveau de la syntaxe correspond aux objets. Xbase++ implémente un modèle de programmation orienté objets avec toutes les caractéristiques propres de ce paradigme : déclaration de nouvelles classes, héritage multiple, encapsulation et polymorphisme. Bien que l’utilisation de ce modèle ne soit pas obligatoire, le fait d’avoir été inclus dans Xbase, c’est disposer de la possibilité de l’utiliser une fois finalisé ce que l’on pourrait appeler la migration basique. Avec cela, vous pouvez profiter de tous les avantages propres de l’orientation objet dans vos développements. Naturellement, des classes bien connues en Clipper, comme Get et Tbrowse, sont disponibles à l’intérieur de la hiérarchie de Xbase++, et vous pouvez créer des héritages à partir de celles-ci pour créer des sous-classes.

La transition à un environnement graphique

Si Xbase++ se distingue par quelque chose, c’est par la facilité qu’il offre pour la transition des applications à un environnement graphique. Ainsi, comme en CA-Visual Objects il était pratiquement obligatoire de réécrire ou de redessiner l’interface utilisateur, avec Xbase++ le changement des contrôles DOS vers ses homologues Windows résulte beaucoup plus direct. Mais pas seulement cela, sinon que le paradigme du contrôle des évènements propre à Windows se dissimule (ou s’encapsule, suivant la terminologie orienté objet) sous le modèle de classes de Xbase++, le transformant en un modèle de manipulation d’évènements beaucoup plus facile et flexible. Ce modèle facilite la migration d’une application en mode texte vers un environnement graphique, et en plus, il assure l’indépendance du code en ce qui concerne le GUI qui est finalement utilisé, que ce soit Windows 95, Windows NT ou même OS/2.

Comme nous l’avons déjà commenté, il suffit de recompiler les programmes actuels pour les migrer à un environnement graphique, obtenant ainsi une authentique application Windows mais avec des caractères au lieu de contrôles graphiques. Puis, en utilisant quelques éléments propres à Xbase++, appelés XbasePARTS (ou XBP), il est possible de transformer peu à peu l’interface en remplaçants des GETs par des listes, des menus DOS par des menus Windows, ou remplacer des touches de fonction par des boutons de commande. Les XbasePARTS ne sont que des classes qui isolent le programmeur des détails propres à chaque système d’exploitation au moment de créer et de manipuler des contrôles. Conceptuellement, ils seraient similaires aux contrôles ActiveX, bien que leur utilisation n’entraîne aucune complexité.

Il est intéressant de détacher que Xbase++ permet de combiner la syntaxe traditionnelle de Clipper, basée sur des commandes SAY, GET, READ, SET KET ou TBROWSE, avec des XbasePARTS dans un même écran. Cette façon de travailler, appelée Mode Hybride, facilite une transition progressive des applications. Sont comprises quelques 35 classes XbasePARTS qui englobent depuis des contrôles simples, comme PushButtons, jusqu’à des plus élaborés, comme Tbrowse en format graphique.

Pour créer de nouvelles fenêtres vous pouvez utiliser un dessinateur visuel de formulaires, similaire à celui de beaucoup d’autres outils de programmation. Le dessinateur permet de spécifier une base de données pour générer le code source du formulaire de manière automatique. Le code généré utilise largement les XbasePARTS, liant chaque champs avec le type de contrôle le plus approprié.

Xbase++ incorpore en plus un moteur de graphiques, Graphics Engine, qui garantit une sortie par écran ou par imprimante indépendante du dispositif pour bitmaps, metafiles et graphiques vectoriels 2D. D’autres éléments graphiques basiques sont supportés, comme des lignes, cercles, rectangles et courbes, qui peuvent s’échelonner, se tourner et se déplacer facilement.

Applications de 32 bits, enfin

Quand Xbase++ fût conçu, il a été établi qu’il devrait produire des applications 32 bits et profiter au maximum des avantages de ce type d’architecture. De là, comme nous l’avons déjà commenté, la première plate-forme pour laquelle il fût développé a été OS/2. Les versions actuelles de Xbase++ pour Windows 95 et NT 4.0 respectent naturellement cette hypothèse de dessein, fournissant des applications natives de 32 bits dont les exécutables respectent le format de fichiers objet que chaque plate-forme détermine. Cela revient à dire que Xbase++ ne produit pas de programmes capables de fonctionner sous Windows 3.x ni DOS.

Travailler sur des plates-formes de 32 bits suppose une amélioration du rendement des applications, grâce surtout, à une plus grande capacité d’accès aux données de la mémoire. La mémoire maximum théorique à laquelle ont accès les applications est de 4,2 GB, et les mécanismes de protection contre des erreurs de programmes sont beaucoup plus robustes. De plus, Xbase++ génère un code natif (dans le style de CA-Visuak Objects) et pas le connu pseudo compilateur de Clipper, ce qui rend le rendement bien plus important. D’un autre côté, Xbase++ inclus sont propre compilateur et éditeur de liens de 32 bits, qui en plus de programmes exécutables, est capable de génèrer des DLLs.

Une autre caractéristique propre des systèmes d’exploitation de 32 bits est le branchement multiple (multithreading), c’est à dire la possibilité qu’une application exécute une partie de son code en parallèle pour mener à bien une tâche. Cette caractéristique est extrêmement intéressante quand il s’agit d’obtenir une exécution plus rapide des applications lors d’accès à des bases de données. S’il n’est pas courant de nos jours de disposer de machines avec plus d’un processeur, où le multithreading paraît avoir plus de sens, les avantages de cette fonction qu’offre le système d’exploitation sont évidents même si l’on ne dispose qu’une seule CPU. Implémenter le multithreading est cependant une tâche complexe, vu qu’on a besoin de mécanismes sophistiqués pour assurer la correcte exécution en parallèle.

Xbase++ ne supporte pas seulement le branchement multiple depuis sa première version, sinon qu’en plus il encapsule tous les types de données du langage pour garantir l’opération asynchrone et concurrentes des applications. Ainsi, le programmeur de Xbase ne doit pas se préoccuper de la complexité que procure la mise en pratique de cette capacité du système d’exploitation. Les opérations sur des bases de données par exemple, peuvent être réalisées en exécutant divers fils d’exécution qui agissent en premier ou second plan, en fonction des nécessité de l’application. Vous pourriez alors laisser tourner un processus de recherche complexe ou une impression de grande taille, pendant que l’utilisateur introduit des données dans d’autres tables. Tous les mécanismes nécessaires pour manipuler le branchement multiple, comme des tâches de synchronisation entre fils d’exécution, sont gérés en interne par les classes de Xbase++.

Une nouvelle gestion des données

Sans aucun doute, ce qui préoccupe les développeurs actuels de langages Xbase est le futur de leur environnement de programmation. On ne peut pas nier que le modèle de base de données DBF, orienté vers la manipulation de registre et vers l’utilisation pratiquement individuelle des données, constitue de nos jours une sérieuse limitation du langage.

Pour résoudre ces déficiences, Xbase++ implémente un nouveau modèle pour la gestion de données appelé Database Management Language Broker (DMLB). Son but est d’encapsuler le modèle de base de données physique et d’offrir accès à celui-ci à travers des commandes et des fonctions du langage Xbase++. L’intérêt de cette nouvelle façon de concevoir l’accès aux données ne se limite pas aux bases de données orientées registre (comme les propres fichiers DBF), sinon qu’en plus, cela permet la gestion de bases de donnes relationnelles, comme SQL, et de n’importe quel autre modèle Client/Server. En d’autres termes, Xbase++ permet de sélectionner et d’utiliser le modèle de base de donnes qui s’ajuste le mieux aux besoins de vos applications.

Xbase++ accède aux bases de données par DatabaseEngines (DBEs), similaires au concept des classiques RDD de Clipper, mais très différents en fonctionnalité. En particulier, la flexibilité qu’ils offrent est très supérieure ; par exemple, Xbase++ permet de créer un indice NTX sur le contenu d’un fichier SDF et de faire une recherche suivant l’indice. De plus, et contrairement aux contrôleurs RDD, les DatabaseEngines peuvent être chargés et déchargés de la mémoire pendant l’exécution de l’application.

Le package de base comprend cinq BDEs : DBF, NTXII, CDX (compatible avec FoxPro 3 et 5), SDF (System Data Format) et DEL (ASCII délimité). De plus, il existe un package optionnel qui permet l’accès à divers serveurs de base de données relationnelles : Oracle 7, DB2 et SQLAnyware. Prochainement, sera disponible l’accès par des contrôleurs ODBC 2.0 et l’intégration avec Advantage Database Server comme moteur de données.

D’autre part, bien que la syntaxe pour l’accès et la manipulation de données puisse continuer à s’utiliser comme jusqu’à aujourd’hui, Xbase++ permet l’introduction de certaines améliorations dans le code qui le simplifie et améliore sa consistance. Une de celles-ci est la possibilité de lier des champs de n’importe quelle base de données à des contrôles de l’écran de façon qu’un quelconque changement dans la base de données, que se soit un saut de registre ou une modification de celui-ci, se reflète automatiquement sur les contrôles sans qu’il soit nécessaire d’introduire du code spécifique pour cela. Dans ce but, vous devez utiliser DBRegisterClient(), une des nouvelles fonctions que Xbase++ incorpore par rapport au langage Clipper standard.

L’évolution de Xbase++

Xbase++ est prévu pour évoluer de façon immédiate. Dans ce sens, les plans qu’Alaska, son fabriquant, à prévu pour ce produit sont vraiment excellents. Bien qu’aujourd’hui Alaska est atteint son but, il n’est pas moins vrai qu’il s’agit d’une première version pour Windows NT et 95, et que, par conséquent, son environnement de développement n’est pas aussi évolué que celui d’autres outils visuels de développement. Mais n’oublions pas que l’intérêt principal de Xbase++ n’est pas d’être un RAD avec un langage propriétaire, mais de faciliter la véritable migration des applications Clipper ainsi que leur évolution future.

Avec Xbase++, Alaska a développé XbToolsIII, un package additionnel qui supporte toutes les fonctions de la bibliothèque CA-Clipper Tools III pour qu’il ne soit pas nécessaire de retoucher le code dans le cas où l’on utiliserait ces fonctions dans les programmes Clipper. De la même façon, d’autres fabricants de bibliothèques sont en train d’adapter les versions de leurs produits pour qu’ils puissent fonctionner avec Xbase++, ce qui démontre le futur prometteur que les fabricants d’utilitaires voient dans ce produit.

Résumé des caractéristiques

Prix

Thèmes associés

	Démo de Alaska Xbase++
	XbToolsIII: Adaptation de Clipper Tools III à Xbase++
	ADS-Database Engine: Connectez Alaska Xbase++ avec Advantage

ACCUEIL | PRODUITS | SERVICES | NOUVELLES | A PROPOS D'ABOX