 |
Vendredi 06 juin 2025 - 12:22 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Voici vos premières questions concernant l'utilisation de Superbase. Nous vous demandons d'être très précis dans l'explication de vos problèmes, en indiquant en particulier quelle version vous utilisez. Pour simplifier, je vous propose les termes suivants : SB2, SB4 et SBPro pour toutes versions confondues.
Problème 1
Dans un masque, il existe une instruction permettant de sélectionner à la souris les champs compris entre deux valeurs (exemple : ENTER 4 TO 8 ou ENTER 4,5 etc.). J' aimerais pouvoir avoir accès en même temps à deux séries de champs mais uniquement à ces champs. Afin d'éviter certaines manipulations, je ne veux pas employer l'instruction ENTER 4,0 me donnant accès à tous les champs. Comment peut-on sélectionner à la souris les champs 4 à 8 et les champs 12 à 16 ?
Mon problème est le suivant : j'ai créé un masque composé de lignes de transaction (tableau) sous lesquelles sont disposés des "boutons commandes" me permettant de choisir le déroulement du programme. J'aimerais pouvoir avoir accès en même temps à une ligne de transaction et une seule et aux boutons commandes.
Solution
Les solutions sont multiples et très simples, mais répondront globalement à ce problème par manque de précision sur la "structure" utilisée. En premier lieu, il faut noter que la commande ENTER (suivie éventuellement de n'importe quel paramètre) n'est pas une commande de masque mais du langage DML. De même, elle ne permet pas de sélectionner à la souris un champ mais provoque la saisie et rend temporairement la main à SBPro lui-même.
Comment créer plusieurs groupes de champs sélectionnables à la souris ? Avec SB2, les possibilités sont relativement limitées. Affectez à une touche la commande ENTER avec les paramètres de votre choix. Si vous n'utilisez pas une procédure DML de contrôle de la saisie des champs, vous assignerez une touche de fonction :
| KEY 1,"! ENTER champ4 TO champ8" |
Sinon n'importe quelle autre touche pourra exécuter cette commande, votre procédure de saisie comprenant par exemple le traitement suivant :
Avec SB4, les possibilités ont été améliorées grâce au nouveau concept des masques. Vous pouvez utiliser la méthode décrite ci-dessus, ou créer des boutons poussoirs qui provoqueront la saisie d'une série de champs lorsque l'on clique dessus. Affectez à chacun d'eux une commande ENTER (+ paramètres).
Pour ce qui est des lignes de transactions, vous utiliserez ce même principe de bouton, mais leur commande correspondante sera différente car le DML de SB4 pilote les lignes de transactions :
| BLANK :SELECT FORM ROW x% :ENTER ROW x% |
...où "x%" représente le numéro de la ligne de transaction.
Faites très attention à la gestion du fichier concerné car les données du masque de transaction sont, avec ce type de commande, dépendantes de celles de l'enregistrement. Notez également que la sélection d'une ligne de transaction rend la fiche correspondante active.
Problème 2
L'instruction WAIT x$ qui attend la frappe d'une touche ne marche pas très bien. Sur des programmes courts, pas de problèmes, par contre sur des programmes longs, le tampon clavier n'est pas toujours vidé. Je suis obligé d'employer la série d'instructions "GET x$ :WATT 4, GET x$" me vidant le tampon clavier.
Solution
Ce petit défaut de SBPro n'est absolument pas lié à la taille du programme mais semblerait plutôt dû à une mauvaise interprétation de la machine. Si vous traitez la valeur de la touche pressée, vous devez faire boucler votre programme sur l'instruction WAIT x$ :
Problème 3
Avec SB2, certaines vérifications sur les champs étaient faites à l'enregistrement. Avec SB4, elles sont effectuées dès la saisie. Exemple : si le champ1 est déclaré comme obligatoire, il n'est plus possible d'exécuter la séquence suivante :
|
BLANK DUPLICATE champ1 = "" ENTER champ1 |
Une des solutions est de gérer les erreurs ou de ne plus rendre les champs obligatoires.
Solution
Erreur n°50 : ce champ doit comporter des données. Cette erreur est incontournable, même avec un traitement des erreurs. Par contre, enlever l'attribut obligatoire d'un champ est la bonne solution lorsque vous travaillez avec une procédure qui contrôle la saisie. Ainsi, votre programme deviendrait :
| IF champ1 = "" GOTO FinDeProgramme |
Problème 4
Dans la définition du format d'étiquettes, il y a le champ "Rows". D'après la notice, il s'agit du nombre de rangées d'étiquettes par page et il convient d'entrer 0 si ce nombre n'a pas de signification (il n'a de signification que lorsque les étiquettes sont sur des pages indépendantes). Lors d'un "test", le programme imprime correctement des "X" sur deux rangées puis commande un saut de page.
Solution
Le paramètre "Rows" (nombre de rangées d'étiquettes par page) signifie en fait "pas de saut de page" et inhibe les préférences imprimante lorsqu'il a pour valeur "0". Le fait d'imprimer deux étiquettes correctement a été jugé suffisant par les auteurs de SBPro, et je suis d'accord avec vous pour dire que le double aurait facilité le test d'impression d'étiquettes...
Problème 5
Je n'ai pas trouvé le moyen d'imprimer des étiquettes (adresses par exemple) avec des index multiples : première index "code postal" et deuxième index (lorsque le code postal ne change pas) "nom ascendant". Je n'ai rien trouvé dans le manuel à ce sujet.
Solution
SBPro est un logiciel qui travaille sur un seul index à la fois, présent de manière logique sous la forme d'un champ. La création d'un index composé (et non pas multiple) s'appliquant à plus d'un champ à la fois est très facile à réaliser : il suffit de définir un champ supplémentaire qui représentera la concaténation des champs que vous voulez utiliser pour ce nouvel index.
Définition de ce champ :
- type : texte obligatoirement.
- longueur : faites la somme de la longueur de tous les champs qui vont composer cet index.
- calcul : créez une formule permettant de concaténer ces champs.
En effet, la consultation d'un tel index donnerait :
DupondAlain
DupondietJean
DupondLouis
DupondoPierre
...et est totalement inexacte en ce qui concerne l'ordre des données. Nous utiliserons donc avec SB4 la formule : PAD$ (nom.clients) + prenom.clients.
La fonction PAD$ () rajoute autant d'espaces que nécessaires à la donnée pour la "forcer" à la longueur maximale du champ qui la contient. La consultation de l'index donne désormais :
DupondAlain
DupondLouis
Dupondiet Jean
Dupondo Pierre
...et correspond au résultat recherché car dans un classement alphabétique le caractère espace est placé avant une lettre ou un chiffre.
Avec SB2, on peut simuler la commande PAD$ () avec :
| LEFT$ (champ + x, y) |
...où "x" est le nombre d'espaces correspondant à la longueur du champ et "y" la longueur maximale du champ. Soit pour notre exemple :
| LEFT$ (nom.clients + SPACE$ (20),20) |
Un index multiple peut être composé de n'importe quel type de champ (texte, numérique, date...), tous les champs différents d'un type texte étant convertis au format alphanumérique par la formule de calcul.
Il peut également être défini en temps que champ virtuel. En effet, dans un fichier important si vous devez concaténer deux champs (ou plus !) de longueur conséquente, les données occuperont beaucoup de place sur le disque dur, alors qu'un champ virtuel ne prend qu'un octet de plus par enregistrement. Le type virtuel sur les machines Amiga à base de 68000 est à déconseiller pour des raisons de performances. N'oubliez pas de créer votre index en activant le menu "nouvel index".
Problème 6
Mon application nécessite l'emploi d'un programme en BASIC compilé. J'exporte de Superbase 4 un certain nombre de données au moyen d'un programme DML (avec boîtes de dialogue), je lance manuellement le programme BASIC (plus de 1000 lignes), et après exécution de ce programme j'importe dans Superbase certains résultats au moyen d'un autre programme DML.
J'ai vainement essayé de lancer le programme BASIC compilé à partir de DML au moyen d'une commande CALL "STACK xxxxx" suivie de CALL "chemin/nom_programme". Le programme commence à s'exécuter, puis un magnifique Guru (8100005.002D15D4). Dois-je prévoir une gestion des erreurs dans le programme BASIC pour le rendre plus convivial avec DML ? Peut-être se plante-t-il sur des informations manquantes (fichiers vides) ? Comment s'effectue la sortie du programme appelé par DML et par suite le retour sous Superbase ?
Solution
A première vue, je serais tenté de dire que c'est l'instruction CALL "STACK xxxxx" qui provoque cette erreur système, SB4 prenant une importante partie du stack (pile) disponible pour pouvoir fonctionner. Je laisse le soin aux spécialiste du 68000 de vous donner la réponse. Peut-être connaissent-ils également le moyen de savoir quel programme (SB4 ou BASIC) provoque le Guru. Nous reviendrons ultérieurement sur cette question après éclaircissement.
Sinon, le BASIC ne peut pas être plus (ni moins) convivial avec SB4. Lorsque vous exécuter un de ses programmes, c'est lui qui a la main au niveau ressources système, SB4 se retrouvant à l'arrière-plan en attente d'une commande END mettant fin tout simplement et proprement à la cession BASIC. Vous pouvez également essayer d'utiliser en premier lieu la commande CALL "" qui aurait pour but "d'activer l'interpréteur de commande" du système.
Problème 7
(vous nous décrivez en détail la structure de vos fichiers et faites la remarque suivante :) ...un montant total enregistré sur une fiche peut être "ventilé" sur deux rubriques différentes et c'est le calcul incorrect par DML des totaux par rubrique qui m'a amené à traiter cela en BASIC...
Solution
Le calcul incorrect de données contenues dans un fichier est un faux "calcul inexact". Il existe plusieurs solutions pour "forcer" SBPro à compter juste et afficher "4" lorsqu'on lui demande "2 + 2".
L'appel à votre programme BASIC est certainement remplaçable par une procédure DML. Cette rubrique vous appartenant, vous avez possibilité de nous exposer ce problème que vous n'avez pas développé ici.
Problème 8
Une des raisons de l'achat de Superbase Pro a été mon intérêt pour les masques. Je m'imaginais plonger dans un univers de facilité et de gestion idéale. J'ai déchanté, après des heures et des heures d'essais, au point que j'ai abandonné tout masque : j'effectue mes saisies directement dans les fichiers avec les contrôles des champs disponibles. Les touches de fonction m'aident à changer d'index, à remplir les champs de données répétitives, à ouvrir et fermer des fichiers. Une seule fonction LOOKUP sert à lier des fichiers : c'est pauvre et c'est banal. Pourriez-vous donner des exemples d'emploi de masques de saisie qui pourraient relancer mon intérêt en leur faveur ?
Solution
Toute application créée avec SBPro devrait être utilisée à partir d'un masque, ne serait-ce que pour pouvoir travailler sur un bel écran bien plus clair que la présentation par défaut. Les possibilités d'un masque ont également un rôle de programme complémentaire à SBPro lui-même. Les inconvénients d'un masque sont vraiment minimes :
- Il faut créer tous les écrans. Si votre application est importante il est vrai que cela peut prendre du temps.
- Certaines fonctions ne sont pas évidentes au premier abord, comme les liens entre fichiers.
- Ils prennent de la place en mémoire.
- On risque de perdre énormément de temps à vouloir les piloter entièrement par le DML.
- Mise en place sans connaissance poussée de la programmation.
- Ouverture automatique de tous les fichiers qui le composent.
- Affichage de plusieurs fichiers sur le même écran.
- Utilisation des gadgets à cliquer permettant de "programmer" le déroulement d'une application.
- Affichage de données graphiques.
- Remplacement de la commande "ouvrir champs" : on n'affiche automatiquement que les champs utiles.
- Etc., la liste des avantages est très longue.
- Liaison dynamique des fichiers sur les index.
- Saisie de variables.
- Gestion complète des lignes de transactions (SB4).
- Affichage automatique fiche suivante/précédente des fichiers liés.
- Échange de données entre masque et fichier, et inversement.
- Création hyper-simplifiée de masques d'état.
- De nombreuses fonctions acceptent le paramètre FORM et deviennent des commandes de masque.
Problème 9
Les produits à gérer sont de trois natures :
- Les matières premières (code, description, prix d'achat). Exemple : farine, sucre, oeuf, chocolat.
- Les produits semi-finis composés de matières premières et/ou d'autres produits semi-finis (code, description, prix de revient). Exemple : génoise, composée de sucre, de lait et d'oeufs.
- Les produits finis (idem que semi-finis). Exemple : crème au chocolat, composée de génoise et de chocolat.
1. Je souhaiterais avec le DML que le code produit se recopie automatiquement dans les fiches composition lors de la création d'un produit.
2. Je souhaiterais que le prix de la ligne de transaction soit dépendant de la nature du produit (prix d'achat d'une matière première ou prix de revient d'un produit fini/semi-fini).
3. Je voudrais qu'une variable calculée (faisant partie du masque) "prix_de_revient_total%" soit recopiée automatiquement dans le champ "prix_de_revient" du fichier article.
4. Est-il possible d'avoir un masque multipage qui comporterait plusieurs tableaux transactionnels, et comment adresser la bonne ligne de transaction ?
Solution
Vous avez créé deux fichiers pour gérer ces produits, mais leur structure complexe est beaucoup trop lourde à manipuler. Elle fait principalement appel à des références croisées du type calculé ou validé. Reprenons-les :
1. Fichier "produit"
Le code sera défini et géré selon votre convenance. Le nom représentera le libellé du produit (dans votre cas : farine, sucre, etc).
2. Fichier "compo"
Il concernera les produits semi-finis ou finis qui sont composés de plusieurs autres produits et contiendra donc le détail de leur composition.
Créons un masque qui permette de gérer les produits :
Et comme SB4 le permet, nous allons profiter des boutons poussoirs qui faciliteront l'utilisation du masque. Notez qu'avec SB2 vous ne pouvez réaliser ce type d'exploitation.
- Bouton fiche précédente («). SELECT FORM PREVIOUS.
- Bouton fiche suivante (»). SELECT FORM NEXT.
- Bouton NOUVEAU. CHAIN "programme1".
- Les autres boutons ne seront pas traités dans cet article. Ils sont là pour exemple, et ne sont bien sûr pas limitatifs. Ils permettront l'appel de programmes DML avec la commande CHAIN.
Le listing du "programme 1" vous montre comment avec quelques lignes de DML on peut remplacer une structure de fichier encombrée de formules de calcul, de validation et tout ce que l'on peut imaginer en mode direct. Son principe est très simple et ne tient pas compte de tous les détails qui peuvent agrémenter ce type d'exploitation : aide à la saisie, messages d'aide ou contrôles divers.
Par contre, il vous montre comment utiliser les lignes de transaction dans un masque, et surtout dans cet exemple comment on peut les gérer en faisant appel au même fichier. Ce programme répond ainsi à vos quatre questions d'une manière très simple.
Dans un autre domaine, je souhaiterais passer des paramètres divers à des programmes graphiques pour visualiser mes données de façon plus parlante. Je parviens à l'aide de l'instruction CALL à appeler un programme GFA. Par contre, je ne sais pas organiser mes données pour les transmettre. Faut-il utiliser une boucle avec un tableau. Comment ?
Il me faudrait un programme graphique permettant de générer différents types de diagrammes avec légende.
Solution
Commençons par le plus simple : un programme graphique. Il en existe plusieurs, soit en commercial, soit dans le domaine public. Vous avez également la possibilité d'interfacer SB4 avec ARexx. Sinon, la solution la plus simple consiste à travailler en parallèle avec un tableur. En effet, vous bénéficiez avec cette solution d'une grande souplesse de traitement des données.
Comment organiser ses données pour les traiter avec un autre programme ? Plusieurs solutions sont envisageables, mais aucune n'est simple d'emploi.
1. Détournement d'une exploitation dans un fichier de données. Cette méthode est limitée à une utilisation en mono-fichier. Le résultat est récupérable (?) par n'importe quel programme.
2. Exportation d'un fichier résultant d'un rapport de données. C'est le principe le plus puissant et surtout le plus modulable. Il suffit de créer un masque générateur d'état, de modifier le programme DML correspondant pour pouvoir enregistrer les sous-totaux et totaux dans les champs d'un fichier de transfert que l'on exportera vers le programme cible. On veillera aux séparateurs de champs et d'enregistrements. A titre d'exemple, MaxiPlan pourra lire directement le fichier ASCII obtenu si l'on utilise respectivement "9" et "10,13" sans guillemets.
Ainsi, dans votre cas, vous pourriez par exemple traiter la part d'une matière première dans la totalité de vos produits en classant ces derniers par type. Notez que d'autres méthodes sont certainement utilisables.
|
