fermez cette fenêtre pour revenir au site de microrun

Plan de la page :



Types de fenêtres Bikini V2
Petites fonctions bien utiles
Saisies texte avec ascenseurs
Pourquoi utiliser le painter ?
Saisies multilignes
Utilisation des labels et zaskhide/zaskshow
Système de Bulles d'aide




Types de fenêtres Bikini V2 :

A partir de la V2, bikini abandonne les fenêtres type double cadre, simple cadre... qui n'avaient un intérêt que dans le mode texte, devenu maintenant marginal.

C'est pourquoi de nouveaux types de fenêtres font leur apparition :













































Quel est le paramètre dans Zlib ?

C'est la fonction zwintitle qui permet de définir le type de cadre, donc le type de fenêtre :
0 = Pas de cadre
1 = Cadre
3 = Cadre étendu
4 = flou
5 = transparent


Utilisation des fenêtres floutées dans les boites d'attente























début



Petites fonctions bien utiles :


Losque l'utilisateur quitte une boite de dialogue par ESCAPE (exemple: modification fiche client), on affiche systématiquement un message du type "En quittant cet écran vous perdrez toutes les modifications".

Or il arrive que l'utilisateur entre dans cette boite de dialogue uniquement pour consulter des données, sans rien modifier.
Dans ce cas, il est inutile de lui afficher le message de confirmation de sortie de la boite.

C'est l'objet de la fonction zdialog_ismodif que de savoir si l'utilisateur a modifié ou pas une boite de dialogue, pour savoir si oui ou non, on doit lui afficher ce message.

Au niveau des traitements après saisies, on est souvent amené à savoir si l'utilisateur a modifié la saisie, et également de ré-afficher dans la saisie la valeur initiale s'il a saisi une valeur incorrecte.
Ceci donne lieu à des traitement répétitifs (sauvegarde ancienne donnée et restauration, test si changement valeur)

L'objet des fonctions suivantes est de simplifier ces traitements répétitifs :

zask_ismodif, placée en traitement après, permet de savoir si la saisie a été modifiée.
zaskrollback_restore, placée en traitement après, permet de restaurer la valeur initiale de la saisie, après une entrée non valide.
Les fonctions zask_getoldalpha et associées permettent de retrouver la valeur initiale d'une saisie, avant modification par l'utilisateur.


Un autre problème est le contrôle de la saisie utilisateur. Admettons que l'on soit sur une facture. Le renseignement du CODE client est absolument obligatoire.
Or en naviguant à l'aide de la souris, l'utilisateur peut "oublier" cette saisie.
C'est pourquoi on est obligé de reporter les traitements de contrôle des saisies sur validation (bouton OK) de la boite de dialogue.
Ceci est chronophage à réaliser.

C'est pourquoi Bikini introduit les 2 fonctions suivantes :

zaskoblig : Cette fonction identifie une saisie comme "obligatoire".
Ceci veut dire que tant que le code n'aura pas exécuté la fonction zask_notoblig correspondante, l'utilisateur restera "coincé" dans la boite de dialogue: Cliquer sur le Bouton OK le renverra automatiquement vers la saisie non contrôlée.

Quel est le principe ? Il suffit de mettre l'instruction zask_notoblig dans le traitement après de la saisie du code client dans notre exemple, lorsque l'on a contrôlé que celui ci était bien renseigné et valide.

Ces fonction sont illustrées dans l'exemple EXBIKV18.




début




Saisies texte avec ascenseurs :


Cela est très simple à réaliser :

Il suffit d'associer un ascenseur vertical, et/ou un ascenseur horizontal à une saisie texte.
Dans le painter, mettre le numéro de saisie texte associée à l'ascenseur.
Avec Zlib, lors de la déclaration de l'ascenseur, zliftdcl, mettre le numéro de la saisie texte dans les 2 dernièrs paramètres.






















début





Pourquoi utiliser le painter ?


Tout d'abord, parce que c'est plus simple.
La mise en page avec le prototypeur sera plus simple à réaliser qu'à l'aide des coordonnées de la Zlib.

On a reproché à l'utilisation du painter le fait que le projet Bikini était au format Criteria, et nécessitait de ce fait l'installation de Criteria sur les stations du réseau.
Avec la génération de fichiers .Z et .ZPJ, plus besoin d'installer Criteria sur les stations.
La zlib lit un projet Bikini/painter sans Criteria.

Cela permet également de dissocier l'apparence de l'écran (dans le projet) et le code source d'exploitation.
Cela permet aussi d'avoir un code source plus compact.

Cela va permettre enfin d'utiliser plus simplement les labels, le système d'aide en ligne avec les bulles d'aide.

Bien qu'un écran soit réalisé à l'aide du painter, vous pouvez interroger dynamiquement une boite de dialogue à l'aide des fonctions d'interrogation de Bikini.

Cela permet de au programme de savoir quels sont les éléments constitutifs de cette boite et où ils sont.

zget_askexist permet de savoir si une saisie existe. Un même source peut par exemple gérer les commandes, les devis et les factures sachant que toutes les zones ne sont pas identiques car ce sont des écrans différents.
; Par exemple, l'effacement d'une zone, relatif à ses coordonnées qui sont inconnues :
zclear_zone(" ",zget_askx(10)+1,zget_asky(10)-5,26,1)

; Où le rafraîchissement d'une date à l'écran :
zprintxy(zget_askx(10)+1,zget_asky(10)-5,zdatalpha(fin)+chr$(26))

zget_askdim2, par exemple permet de savoir combien de lignes fait un tableau.
Ce tableau peut en effet être de différente tailles selon la taille de l'écran (80, 100, 120 colonnes...)



début





Saisies multilignes :

Les saisies multilignes sont intéressantes dans le cadre de saisies de factures, écritures comptables etc...

Le principe est très simple: Il suffit de réaliser X tableaux verticaux de saisie, d'un même nombre de lignes, et de leur associer un ascenseur horizontal, de la même manière qu'avec une saisie de texte scrollé.


Exemple de saisie multiligne : Saisie des lignes de factures
























Le source est exactement le même que celui de saisie de ces tableaux, aux différences près suivantes :

1) On définit une fonction de lecture et une fonction d'écriture de la ligne :
zline_setbefore et zline_setafter permettent d'associer cette fonction au multiligne.

Ensuite on encadre chaque saisie par les fonctions zline_before et zline_after.

Reste à écrire les callback associés aux fonctions zline_setbefore et zline_setafter.
C'est là que le nouveau système de listes mémoires, (ou ZSI) peuvent intervenir pour simplifier les choses.

Voir exemple EXFACTUR largement remanié.



début





Utilisation des labels et zaskhide/zaskshow :

L'utilité de l'utilisation des labels est la suivante :
Lorsque l'on masque une ou un groupe de saisies, masquer automatiquement les libellés associés (zaskhide)
Lorsque l'on démasque une ou un groupe de saisies, démasquer automatiquement les libellés associés (zaskshow)


Cliquer sur "Géré en stock" affiche automatiquement les informations relative à la fiche de stock.
Décliquer sur "Géré en stock" les effacee automatiquement.
A noter que l'image de fond (zwinback), est automatiquement affichée sur l'effacement.






















Comment faire les labels ?

Dans le PAINTER, deux méthodes :

* Soit on sélectionne un texte à l'écran, et on en fait un label par Ctrl G.
* Soit on sélectionne une zone vide à l'écran, on va dans dessin/label, et on entre le texte du label.
Le label doit toujours être associé à une saisie.

Un label dans le painter
















Par la Zlibrary, le système était plus compliqué.
la nouvelle fonction zlabeldcl simplifie drastiquement l'utilisation des labels en zlib+
il suffit maintenant de les déclarer lors des déclarations des saisies.

Le label ainsi déclaré sera mémorisé et affiché ou masqué automatiquement lors de l'exécution, en fonction des zaskhide et zaskshow.

A noter que l'on peut associer des labels à des check et radio-boutons. Dans ce cas cliquer sur le label activera automatiquement le check ou le radio.

Cliquer sur "Nom" activera automatiquement le radio en 2ième position












début





Système de Bulles d'aide :


Bikini V2 permet d'afficher des bulles d'aide lorsque le curseur souris passe les saisies (onRollOver).
Une nouvelle fonction fait automatiquement afficher la ligne status dans ces bulles d'aide.
Ceci évite de reconstruire un nouveau système d'aide en ligne pour les bulles d'aide, alors que la ligne status est renseignée dans les applications.



















Où se positionnent les bulles d'aide ?
Les bulles se positionnent automatiquement au dessous du pointeur de la souris.
Celà peut être génant sur les listes car la bulle cache une partie de celle-ci.
Cela est résolu car si le pointeur de la souris s'approche trop de la bulle, celle-ci se déplace automatiquement.
Si une partie importante de la liste est ainsi cachée, il suffit de déplacer la souris vers cette partie pour déplacer la bulle.

La fonction zstatus2bubble, positionnée en début d'application (après le zinit), redirige tous les messages de la ligne status vers les bulles d'aide.

ATTENTION! Seuls les messages de la ligne status issus du PAINTER sont ainsi redirigés.
En effet, les messages status présents dans le traitement avant des saisies (zstatus), ne peuvent être connus de Zlib en début d'exécution des boites de dialogue.


Cest pourquoi la nouvelle fonction zstatusdcl permet de déclarer un message sur la ligne status lors des déclarations d'une boite de dialogue.
Ce message sera ensuite automatiquement repris dans le système de bulles d'aide.

début