Présentation
Documentation
L'équipe
Sérialisation
 
Programmes
Objets
Libs Utilitaires
Libs Internes
   
 
Editeur
Syntaxes
Windows
Versions
   

SCR/AL1 - TOME VII. Version Windows

3. Création d'une application Win32

Par rapport aux versions classiques en mode caractère (DOS, Unix ou DOSWIN), quelques différences - en particulier dans la procédure de démarrage d'une application - sont apparues avec la version Windows de SCR4/AL1.

Cette section présente les nouveautés en matière de mise en oeuvre d'un applicatif sous Win32. Elle est structurée comme suit :

3.1 Principales étapes du portage

Le portage d'une application existante sous Windows est simple si on a pris la précaution de n'utiliser que des fonctions SCR4/AL1 d'un niveau assez élevé.

Il est évident par exemple que certaines fonctions comme SCR_write() qui écrit directement dans l'écran ne seront plus exploitables.

Les fonctions SCR/AL1 modifiées ou annulées sont décrites dans un chapitre séparé.

En prenant comme hypothèse que les fonctions utilisées sont "classiques" et s'inscrivent dans les librairies de SCR4/AL1, on procèdera comme suit pour porter une application.

Options de compilation

Les options de compilation des fichiers sources (.c) et des fichiers d'objets (.f) doivent être modifiées. Les options de compilation des sources C pour le compilateur Borland 5.0 sont :

    bcc32 -W -v -w-rvl -w-pro -H -Ic:\scr\i;e:\bc5\i

Certaines options ne sont pas indispensables (-w-* et -H), mais sont souhaitables soit pour la lisibilité des messages de compilation, soit pour la performance (-H).

Les directories qui contiennent les include files (-I...) sont à adapter en fonction de l'installation.

En ce qui concerne les fichiers d'objets, il faut ajouter le paramètre -w pour indiquer à scr4_e le nom du fichier de ressources Windows à générer. Une ligne classique est donc :

    scr4w_e -1obj -optmem -actmem -namemem -af iode.f -o o_objs -w o_objs

Le programme scr4w_e est identique à scr4_e à ceci près qu'il s'agit d'un exécutable Win32 et permet donc de compiler des fichiers de taille plus grande que scr4_e. Les fichiers produits sont dependant identiques.

Le résultat de la commande précédente est la génération des fichiers

Compilation des ressources

Les ressources générées par scr4_e dans le fichier .rc doivent être compilées par le compilateur de resources (rc32 ou brc32) et ensuite linkées avec le programme exécutable pour être exploitées en cours d'exécution.

Deux commandes sont donc nécessaires :

   brc32 -ie:\bc5\i;c:\scr\i -r o_objs.rc
move o_objs.res iode.res

pour la compilation des ressources (ce qui génère un fichier .res) et, pour le lien avec l'exécutable :

    brc32 iode.res

Fichiers icône et bitmap

Le fichier .rc généré par scr4_e contient deux références:

Ces deux fichiers peuvent être remplacés par les fichiers spécifiques de l'application en cours de construction. Ils doivent cependant porter les noms repris ci-dessus.

Plus d'explications sur le fichier bitmap seront fournies plus loin.

Fonctions main() vs WinMain()

Contrairement aux applications DOS ou Unix classiques, il faut sous Windows créer une fonction WinMain() et non main(). Une discussion sur ce sujet fait l'objet d'une partie ultérieure de ce manuel.

Retenons simplement à ce niveau que :

Exemple de makefile

    CC = bcc32 -W -DSCRW32 -v -I.;c:\bc5\I;c:\SCR\I -w-rvl -H -c -w-pro
LINK = bcc32 -M -W -v -Lc:\bc5\L;c:\scr\l -ea.out

all : web.exe

web_objs.c : web.f
scr4w_e -af web -w web_objs -o web_objs -1obj

web.res : web_objs.rc web_objs.c
brc32 -ic:\bc5\i;c:\scr\i -r web_objs.rc
move web_objs.res web.res

web.exe : web_objs.c web_objs.obj web.res web.obj
$(LINK) web.obj web_objs.obj scr4wo.lib scr4wi.lib s32wi4.lib
move a.out web.exe
brc32 web.res

Autres modifications de portage

Il est possible (et souhaitable) d'apporter d'autres modifications aux sources pour faire en sorte que l'application portée s'intègre au mieux dans l'environnement Windows.

Pour ce faire, on dispose de différents outils :

Ces nouvelles possibilités sont détaillées dans les sections suivantes.

3.2 Disparition de la fonction main()

Sous Windows le code de démarrage du compilateur C appelle la fonction WinMain() et non la fonction main(). C'est le résultat de la compilation avec le paramètre -W.

Main, quand-même ?

Si on ne compile pas avec -W, on peut créer un exécutable 32 bits qui s'exécute dans la fenêtre DOS appelante. Les messages de printf() sont alors affichés dans cette fenêtre. Cette façon de faire convient pour de petit utilitaires.

Si on doit utiliser cette méthode, il faudra peut-être redéfinir la fonction Wprintf() si elle est appelée par une sous-fonction de SCR/AL1. Il suffit de la créer dans un des modules (pas dans une librairie) pour que celle-ci remplace la version de SCR/AL1.

Si ne le fait pas, on obtient en général un problème lors du link.

WinMain

Pour simplifier le travail de portage, la fonction WinMain() est intégrée dans la librairie scr4wo.lib.

WinMain() effectue les opérations suivantes:

Il est possible de remplacer la fonction WinMain de SCR/AL1 par sa propre fonction. Dans ce cas, l'application ne peut avoir d'interface écran (sauf à tout refaire soi-même...). Il s'agira par exemple d'un programme d'impression ou de création de fichiers. Il faut se reporter aux manuels concernant l'API Win32 pour en connaître la syntaxe.

3.3 Fonctions d'initialisation

Deux fonctions sont appelées par SCR4/AL1 et sont donc les deux points d'accès du programmeur lors de l'initilisation de son code :

    WscrStart1()
WscrMain()

Ces fonctions sont appelées par la fonction WinMain() définie dans scr4wo.lib.

WscrStart1()

Cette fonction est optionnelle: par défaut elle ne fait rien. Si on souhaite la remplacer, il faut se souvenir que le fichier .scr n'est pas encore chargé. Elle contient donc en principe ce qui auparavant précédait dans le main() l'appel à SCR_init().

Sa syntaxe est :

    int WscrStart1(int argc, char **argv);

argc est le nombre d'arguments de la ligne de commande et argv un tableau de pointeurs vers les différents arguments.

Si la valeur de retour n'est pas nulle, le programme se termine.

WscrMain()

Cette fonction DOIT être définie : elle retourne le HANDLE vers la fenêtre principale de l'application.

Sa syntaxe est :

    HWND WscrMain(int argc, char **argv);

où argc est le nombre d'arguments de la ligne de commande et argv un tableau de pointeurs vers les différents arguments.

Cette fonction est appelée après le chargement des objets définis dans le fichier .scr. Une fonction de la librairie scr4wo.lib permet de créer le HANDLE nécessaire à partir d'un objet APPL :

    HWND WapEditAppl(APPL *ap);

Il est conseillé de placer cette fonction dans un fichier séparé. Les prototypes des fonctions et le type HWND sont définis dans le fichier scr4w.h.

3.4 Fonction de clôture

Une fonction permet de faire le "nettoyage final". Elle est appelée après la destruction de toutes les fenêtres de l'application. Cette fonction se nomme WscrEnd(). Par défaut, elle exécute un code équivalent à SCR_end(). Si on redéfini cette fonction, il faut y inclure SCR_end().

Elle permet par exemple de sauver un profile dans un fichier.

WscrEnd(argc, argv)

Sa syntaxe est :

    WscrEnd(int argc, char **argv);

argc est le nombre d'arguments de la ligne de commande et argv un tableau de pointeurs vers les différents arguments.

La valeur de retour n'est pas exploitée, le programme se terminant de toute façon.

3.5 Fichiers à inclure

Dans les modules existants ou nouveaux, il faut comme toujours inclure le fichier scr.h (ou scr4.h, ce qui est équivalent).

Un nouveau fichier, incluant lui-même scr4.h, est ajouté aux fichiers .h fournis avec SCR4/AL1. Ce fichier, scr4w.h, inclut également windows.h et d'autres fichiers nécessaires à la compilation des applications.

Seuls les modules faisant explicitement appel à des fonctions de l'API SCR/AL1 spécifique à Windows (WscrMain() par exemple) doivent inclure scr4w.h. Il est déconseillé de l'inclure dans les autres fichiers, car le temps de compilation en est considérablement allongé et la portabilité en est obérée!

3.6 Ecriture d'une fonction WinMain()

Si l'application ne nécessite pas d'interface écran, on peut définir sa propre fonction WinMain(). Celle-ci est définie dans l'API Win32 auquel on se reportera pour la syntaxe complète.

Signalons seulement que les arguments de WinMain() ne sont pas les mêmes que ceux de main(). La ligne de commande est passée dans un seul string que le programmeur doit découper lui-même.

3.7 Variables globales SCRW32

Quelques variables globales font également leur apparition :

    U_ch  *WSCRMainTitle;
U_ch *WSCRQueryEnd;

La première est le titre de l'application qui apparaîtra comme titre des fenêtres (sauf dans le cas des objets acceptant un TITLE). Par défaut, ce titre vaut "Application SCR4/W". On peut la changer en spécifiant

    GLOBAL APPL_NAME "titre"

dans un des fichiers de description d'objets SCR/AL1 ou en assignant une autre valeur en C.

La seconde est le message affiché pour confirmer la fin du programme. Par défaut, cette variable est fixée au texte :

        "Quitter l'application ?"

On peut la modifier n'importe où dans le code. Si la valeur de ce pointeur est nul, aucune question n'est posée et le programme se termine dès que l'utilisateur choisit une option adéquate.

3.8 Programmer avec une fonction main()

Le programme scr4w_e est une application Windows, mais qui affiche ses messages directement dans la fenêtre DOS appelante.

Pour ce faire, il faut procéder comme suit:

On peut dès lors utiliser les vieilles bonnes fonctions printf, ...

3.9 Applications avec fichiers concaténés

Les applications qui exploitaient la possibilité de concaténer à l'exécutable les fichiers .scr et .cmt (voire d'autres fichiers) ne peuvent plus utiliser cette fonctionnalité. En effet, les ressources de Windows sont elles aussi concaténées par une méthode semblable à l'exécutable.

L'effet est que les ressources ne sont plus exploitables correctement par Windows et la conséquence est en général un splendide plantage.

3.10 Les ressources générées

Le processus de génération d'une application nécessite (au moins actuellement) le passage par la création de ressources Windows.

Ce fichier .rc contient, pour chaque PAGE générée une définition de ressource. Ces définitions ne doivent pas être modifiées par le programmeur car elles sont regénérées à chaque compilation.

Par contre, les ressources contiennent également des références à deux fichiers externes: l'un contient l'icône de l'application et l'autre les bitmaps utilisés dans les TOOLBARS.

Ces deux fichiers peuvent être remplacés par le programmeur pour être adaptés à chaque application. Les sections suivantes expliquent le rôle de chacun de ces fichiers et la manière de les modifier.

3.11 Définition des icônes

Le fichier scr4w.ico contient l'icône de l'application. Celle-ci peut être modifiée par le programmeur de façon à associer une icône adéquate au programme développé. Il suffit de remplacer le fichier scr4w.ico par le nouveau fichier.

Le nom doit cependant rester le même car dans le fichier .rc généré par scr4_e, le nom scr4w.ico est fixe.

3.12 Définition des bitmaps

Le fichier scr4w.bmp contient les images utilisées dans les TOOLBARS de l'application.

Ces images sont jointes en une seule "bande" et à chaque image est associée un numéro d'ordre qui est référencé dans la définition des TOOLBARS.

Si on remplace le fichier scr4w.bmp, il faut donc adapter tous les TOOLBARS de l'application en conséquence.

La définition précise des TOOLBARS fait l'objet d'une section distincte.

Le nom du fichier doit rester le même car dans le fichier .rc généré par scr4_e, le nom scr4w.bmp est fixe.

Copyright © 1998-2015 Jean-Marc Paul and Bernard PAUL - Envoyez vos remarques ou commentaires à bernard@xon.be