La notion de RECORD

Je propose la création d'une commande RECORD. Elle devrait permettre de créer une zone mémoire contigüe, composée des variables énumérées en paramètre:

Citation :: RECORD nom_du_record
dim n%, test%(30), a$=20, mois$(4)=15
dim suite%(4)
END_RECORD

Cette commande créerait une zone mémoire contenant 4+4*30+21+13*4+4*5 caractères. Elle forcerait la commande DIM de localiser toutes les données dans un espace mémoire précis, localisé, et adressable par le nom du record. Pour les variables de type chaîne de caractères, l'espace alloué comprend l'octet 0 terminal. Ainsi, dans l'exemple ci-dessus, les noms des mois sont codés sur 3 caractères maxi, suivi d'un octet 0.

Je sais bien que le vrai défi technique sera de gérer la longueur des chaînes de caractères. Elles devraient automatiquement être tronquées à leur longueur maximale. Par contre, elles devraient pouvoir être plus courtes, en terminant par un octet 0.

On devrait pouvoir faire ADR(nom_du_record) pour avoir l'adresse du début.
On devrait pouvoir faire LEN(nom_du_record) pour avoir la longueur totale.

Et je suggère les nouvelles commandes de gestion de fichier binaire:

Citation :: FILEBIN_RECORD_WRITE N,nom_du_record
FILEBIN_RECORD_READ N,nom_du_record
FILEBIN_RECORD_POSITION n,nom_du_record,rec%

Ceci permettrait de résoudre d'un coup plusieurs problèmes:
1. faciliter la réalisation d'applications de gestion, qui nécessitent en général des structures de ce type
2. créer des structures de paramètres pour l'appel de fonctions DLL, du système ou autre
3. contourner la limitation à 6 paramètres pour les appels de fonctions DLL
4. rendre possible le passage de tableaux à une DLL, et ce en entrée et en sortie (via ADR)
5. définir plusieurs types de RECORD, et en utilisant l'un ou l'autre, interpréter différemment le contenu d'un même fichier

Comme toujours, si cela peut aider à l' évolution de KGF et autres
dlls pour panoramic, Je suis avec toi.

+1

Klaus a écrit:: Je propose la création d'une commande RECORD

Ça ne sera pas plus précis de parler de TYPE RECORD au lieu de COMMANDE RECORD ?

Klaus a écrit:: Citation :
RECORD nom_du_record
dim n%, test%(30), a$=20, mois$(4)=15
dim suite%(4)
END_RECORD

Cette commande créerait une zone mémoire contenant 4+4*30+21+13*4+4*5 caractères.

Je n’arrive pas à saisir le calcul de la zone mémoire :
N% : un entier --- > 4 octets (caractères)
Test%(30) : un tableau d’entier --- > 4*30, or ce tableau contient 31 éléments de test%(0) à test%(30), donc 4*31, non ?
A$ = 20 : (je n’ai pas saisi ce que ça représente), je suppose qu’il s’agit d’un string de 20 caractères, donc 20+1 (pour le zéro terminal)
Mois$(4) : est-ce un tableau de string ou une seule string de longueur 4 octets ? Tu réserves à cette variable 13*4 octets, (c-à-d : (3*4+1)*4) veux-tu donner plus d'éclaircissements ?
Suite%(4) : tu réserves à cette variable 4*5 octets

Il se peut que j’ai passé à côté de la vérité.

De toutes les façons si ta proposition verra le jour, ça sera un petit pas pour le Panoramicien, un grand pas pour Panoramic.

Tu as raison; Papydall: il y a une erreur dans mon calcul de l'espace alloué. Voici ma suggestion, avec plus de commentaires, et la correciton de cette erreur. Et je pense même que je vais affiner ma suggestion en remplaçant DIM par DIM_RECORD (comme DIM_LOCAL dans les SUBà:

Citation :: Citation :
RECORD nom_du_record
DIM_RECORD n%, test%(30), a$=20, mois$(4)=15
' n% prend 4 caractères
' test%(30) prend 31 fois 4 caractères
' a$=20 prend 20 caractères globalement, dont le dernier est le zéro binaire (19 caractères utiles)
' mois$(4)=15 prend 5 fois 15 caractères, dont chaque fois le dernier est le zéro binaire
DIM_RECORD suite%(4)
' suite%(4) prend 5 fois 4 caractères
END_RECORD

Cette commande créerait une zone mémoire contenant:
4 + 4*31 + 20 + 15*5 + 4*5 caractères.

J'ai "inventé" une notation dim a$=20 avec le signe "=" introduisant la longueur physique de l'espace maximal réservé à la chaîne de caractères. On peut envisager d'autres constructions, mais dans le contexte d'un RECORD, il faut pouvoir imposer une longueur maximale, et cet espace sera réservé à la création et prérempli de zéros binaires.

Ce code n'est pas à exécuter : c'est un REVE !
A lire seulement.

Code:: rem ============================================================================
rem Rêverie de Papydall suite au souhait de Klaus
rem ============================================================================

RECORD = Personne : ' Déclaration d'une variable structurée Personne
   DIM_RECORD prenom$ = 30 : ' Variable chaine de 30 caractères
   DIM_RECORD NomFamille$ = 30 : ' -----------------------------------------------
   DIM_RECORD Age% = 2 : ' Variable entière sur deux chiffres
   DIM_RECORD Etat_civil$ = 1 : ' Variable chaine de 1 caractère
END_RECORD

DEFINE Membre IS Personne : ' On défini une variable Membre du type RECORD
DEFINE Employe IS Personne : ' On défini une variable Employe du type RECORD
dim ec$ :' variable globale utilisée dans le programme
rem ============================================================================
' Affectation
Membre.Prenom$ = "Jean"
Membre.NomFamille$ = "Valjean"
Membre.Age% = 99
Membre.Etat_Civil$ = "M"
' Lecture
print "Prénom : " + Membre.Prenom$
print "Nom : " + Membre.NomFamille$
print "Age : " + str$(Membre.Age%)
if Membre.Etat_Civil$ = "M" then ec$ = "Marié(e)
if Membre.Etat_Civil$ = "C" then ec$ = "Célibataire
if Membre.Etat_Civil$ = "V" then ec$ = "Veuf/Veuve"
print "Etat civil : " + ec$
' Traitement avec la variable Employe du type RECORD
Employe.Prenom$ = "Victor"
Employe.NomFamille$ = "Oguh"
' Etc.
' Etc.
rem ============================================================================

Ah, tu vas plus loin que moi ! Evidemment, ce serait fichtrement intéressant. Mais tu introduis la notion de "membre" ou "propriété" signalé par une construction contenant.membre qui est un peu en-dehors de l'esprit de Panoramic. Mais ce serait bien, et quel confort de programmation...

Je suis un rêveur, Klaus

J'invente toujours des rêves plus fantastiques que la science-fiction pour me moquer de la réalité! Laughing

en fait si j'ai bien compris l'esprit dans lequel Jack souhaite développer Panoramic, il faudrait qu'il garde PAnoramic simple donc sans ces instructions 'sophistiquées' mais très utiles pour nous et qu'il les ajoute dans un des versions de PAnoramic qu'il souhaite créer. Personnellement, je ne sais pas trop pourquoi il préfère faire des versions séparées car dans Panoramic on peut faire de tout et moi ça me plait bien. J'ai peur que dans la version 3D parfois il nous manque une des fonctions qu'il va ajouter dans une autre version et vice-versa et que pour les développeurs débutants, il y ait juste plusieurs niveaux d'instructions triées par thème (les fondamentales, les 2D, les 3D, les fichiers, les structures, les grilles les fonctions avancées, etc ...) Ca ne ferait qu'une version de Panoramic à maintenir et à apréhender. LA comptabilité ascendante serait assurée, etc ...

Bon, je pars hors sujet. Je soutiens ta demande et j'espère que Jack pourra l'ajouter dans Panoramic

@Klaus : C'est une notion de structure comme en C ?

Je ne connais pas le C. Mais en Delphi, il y a exactement cela.

Une construction RECORD...END_RECORD entoure des définitions de variables. Pour différencier les DIM nécessaires, j'ai proposé une commande DIM_RECORD, un peu comme DIM_LOCAL ne définit que les variables locales dans une SUB. La commande DIM_RECORD ne devrait être reconnue qu'entre RECORD et END_RECORD, et RECORD et END_RECORD doivent se trouver par paires, tout comme SUB et END_SUB. Et entre RECORD et END_RECORD, seule la commande DIM_RECORD ne devra être autorisée, rien d'autre.

On peut même imaginer une commande FREE_RECORD nom_du_record qui efface dynamiquement toute la définition du record et libère la mémoire, à l'image de la commande FREE pour les variables normales.

De même, une commande CLEAR_RECORD nom_du_record serait très utile: elle mettrait des zéros binaires dans l'ensemble de la mémoire réservée pour un record. Ceci serait d'ailleurs un moyen élégant de remettre un tableau d'entiers à zéro: l'inclure dans un record et faire un CLEAR_RECORD sur ce record...

Dans le reste du programme, un record devrait être regardé comme une chaîne de caractères binaires. Donc, la fonction LEN(nom_du_record) devrait retourner la longueur totale du record, etc. Mais la localisation physique des données ne devra jamais changer. Un record est le nom (et donc l'adresse) d'une zone mémoire contigüe, de longueur fixe.

Il découle de ce que j'ai dit ci-dessus, qu'un record ne peut pas avoir un record comme élément. Je pense que ce niveau de sophistication est totalement inutile. Mais la structure d'un record contenant plusieurs éléments de type entier, flottant ou chaîne de caractères, ainsi que des tableaux de ces types, est un enrichissement important pour Panoramic.

J'ai laborieusement réalisé cela par des fonctions dans KGF.dll, et avec le support de quelques macros. Mais ça reste très laborieux, et c'est étroitement lié à la manière dont Panoramic gère l'allocation de mémoire pour ses variables. Et je crains que dans une version future, et en particulier une version Android, tout cela ne marchera plus. Et c'est pourquoi je suggère cette notion de structure qui est la base de la programmation en informatique de gestion. Certes, je sais que Jack est parti d'eun contexte ludique, pour la réalisation de jeux. Mais il a nommé son langage "Panoramic" pour bien signifier qu'il est utilisable tous horizons. Alors, j'aimerais bien qu'on ouvre un peu l'horizon des applications de gestion...

A titre d'exemple, j'aimerais pouvoir écrire quelque chose de ce genre:

Code:: declarer_records() : ' définir tous les records
charger_combos() : ' charger les combos et dlist

end

sub declarer_records()
record Client : ' fichier client.dat
dim_record cli_code% : ' code client
dim_record cli_nom$=20 : ' nom du client
dim_record cli_prenom$=20 : ' prénom du client
dim_record cli_typeclient% : ' type du client du fichier types.dat (indice dans une combo)
dim_record cli_adresse$(3)=40 : ' adresse du client en 4 lignes
dim_record cli_telephone$(1)=20 : ' téléphone du client (2 numéros)
dim_record cli_fax$=20 : ' fax du client
dim_record cli_mail$(1)=20 : ' adresse mail du client (2 adresses)
dim_record cli_url$=255 : ' URL du site web du client
dim_record cli_coderemise% : ' code remise du fichier remise.dat (indice dans une combo)
end_record

record Remises : ' fichier remise.dat (à charger dans une combo)
dim_record rem_coreremise% : ' code remise
dim_record rem_libelle$=20 : ' libellé de la remise
dim_record rem_taux : ' taux de la remise
end_record

record_Types : ' fichier types.dat (à charger dans une combo)
dim_record typ_typeclient% : ' type de client
dim_record typ_libelle$=20 : ' libellé du type de client
dim_record typ_remisedefaut% : ' code remise du fichier remise.dat (indice dans une combo)
end_record

record Commandes : ' fichier commandes.dat (entêtes des commandes)
dim_record cde_numero% : ' numéro de la commande
dim_record cde_cli_code% : ' code client
dim_record cde_date$=8 : ' date de la commande
dim_record cde_statut% : ' statut de la commande du fichier cdestatus.dat (indice dans une combo)
dim_record cde_lignes% : ' nombre de lignes de la commande
dim_record cde_total_HT : ' montant total hors taxes de la commande
dim_record cde_total_TVA : ' montant totat de la TVA de la commande
dim_record cde_total_port : ' montant total des frais de transport
dim_record cde_total_TTC : ' montant total TTC de la commande
dim_record cde_regle : ' montant total déjà réglé pour la commande
end_record

record cdestatut : ' fichier statut.dat (à charger dans une combo)
dim_record cst_cdestatut% : ' statut de la commande de cdsstatut.dat
dim_record cst_cdelibelle$(20) : ' libellé du statut
end_record

record TauxTVA : ' fichier TauxTVA.dat
dim_record tva_code% : ' code TVA
dim_record tva_libellé1$=20 : ' libellé long de ce code TVA
dim_record tva_libelle2$=4 : ' libellé court de ce code TVA
dim_record tva_taux : ' taux de ce code TVA
end_record

' ... etc

end_sub

sub charger_combos()

' catégories de remises
filebin_open_read 1,"remise.dat"
clear n_combo_type_remise% : ' combo des types de remise
clear n_dlist_type_remise% : ' taux des types de ermise
while file_eof(1)=0
filebin_record_read 1,Remises
item_add n_combo_type_remise%, right$("00"+str$(rem_coreremise%),2)+" - "+rem_libelle$
item_add n_dlist_type_remise%, str$(rem_taux)
end_while

' ... etc

end_sub

Ce code, utilisant les commandes proposées, crée quelques records d'une application de gestion commerciale, et charge dans des combos et dlist des valeurs de paramétrage comme la liste des taux de remise, des taux de TVA etc.

La structure RECORD (c-à-d enregistrement) regroupe sous un identificateur plusieurs variables de types différents.
Prenons comme exemple l’adresse de quelqu’un auquel vous désirez écrire.
Les indications sur l’enveloppe peuvent être :
Qualité du destinataire : Monsieur
Prénom nom : Jean Dupond
Numéro et rue : 36, Chemin des Roses
Code postal et ville : 92999 Panoramicville

Si Monsieur Jean Dupond désire programmer sa tenue de stock, il aura besoin de la structure suivante :
Numéro de référence : 12345
Désignation : Paillasson
Prix H.T : 25.80
Fournisseur : Sté-Pano

Ce qui est remarquable, c’est que sous une dénomination générale (comme ‘article’ par exemple) se regroupent plusieurs informations (Numéro de référence, désignation, etc.) dont le type de données est différents.
ARTICLE réunit les éléments et les types suivant :
Numéro de référence entier
Désignation string[30]
Prix H.T flottant
Fournisseur string[20]

En Turbo Pascal on déclare cette structure comme suit :
TYPE
Article = RECORD
NumRef : INTEGER ;
Designat : STRING[30] ;
prixHT : REAL ;
fournisseur : STRING[20] ;
END ;

VAR
seVendBien : article ;

La variable sevendBien est du type ARTICLE qui lui-même se constitue des champs NUMREF, DESIGNAT, PRIXHT et FOURNISSEUR.
Pour accéder à l’un des éléments, on emploie un identificateur du nom de la variable et de celui du champ. Les deux noms sont séparés par un point.

seVendBien.numRef := 17001 ;
seVendBien.designat := 'Bonnet de bain' ;
seVenbien.prixHT :=17.95
seVendBien.fournisseur := 'Le soleil brille S.A.' ;

Durant des années j’ai programmé en Turbo Pascal en utilisant des telles structures, mais revenons sur terre : on est sous PANORAMIC OK mais le rêve n’est pas interdit !

@Papydall (et aux autres connaisseurs de structures RECORD dans d'autres langages):

Je connais pas mal de langages où de telles constructions sont possibles. Certaines sont très sophistiquées, d'autres moins. Certains sont même capables de définir des RECORD dont la structure et la longueur finale varient en fonction du contenu...

Certains langages utilisent la construction contenant.membre ce qui permet d'avoir le même nom de membre dans deux contenants différents. D'autres utilisent simplement les noms des membres qui doivent alors être uniques.

Pour ma part, j'ai essayé de proposer un ensemble de commandes et un principe d'implémentation qui reste cohérent avec l'esprit du Panoramic actue. On n'a pas, dans Panoramic, la notion de "membre" ou de "propriété". On n'a pas la OOP (Object Oriented Programmation). Ou du moins pas dans son expression habituelle, car dans sur le fond, il y a bien quelque chose de cet esprit qui est perceptible à travers la notion des "objets" de Panoramic. Mais leur usage est rendu accessible par un ensemble de commandes et fonctions telles qu'on les connaît dans un langage non-OOB, non-procédural. C'est ce qui fait sa simplicité, et c'est son point fort sur le plan technique.

J'ai donc intentionnellement écarté des solutions du type

Citation :: RECORD essai
FIELD date$=8
FIELD valeur%
END_RECORD

RECORD test
FIELD champ1%
FIELD cham2$(10)=20
FIELD trace as essai
...
END_RECORD

DIM enreg1 as test
DIM enreg2 as test

enreg1.champ1 = 2
enreg1.champ2$(3) = "Un essai"
enreg1.trace.date = date$
enreg1.trace.valeur% = 17
enreg2 = enreg1

Certes, ce serait "puissant". Mais on n'est alors plus du tout en Panoramic. On est en C, en Delphi, en VisualBasic etc, mais plus en Panoramic.

J'ai donc volontairement exclu la notion de "membre" (introduit par un "."), ainsi que la notion de records dont des éléments peuvent être des records. Mais je pense que cette limitation, peut-être frustrante du point de vu intellectuel d'un programmeur expérimenté, n'est en réalité pas du tout contraignante pour le Panoramicien normal, celui qui cherche à programmer facilement sa propre gestion de cave à vin, ou la gestion financière du patrimoine d'un proche sous tutelle (je sais de quoi je parle !).

Donc, mon souhait est vraiment une plus large ouverture de Panoramic vers des applications de gestion, mais sans y ajouter en tarabiscotant les constructions syntaxiques. Je sais, il manque encore deux vastes aspects:
1. la gestion des impressions. J'y ai apporté une solution provisoire dans KGF.dll, mais Jack a mentionné son intention de faire évoluer cela en Panoramic. Donc, j'attends.
2. accès aux bases de données, ou tout au moins aux fichiers ISAM (Indexed Sequential Access Method) avec une ou plusieurs clés. Là encore, j'y ai apporté même plusieurs solutions dans KGF.dll, mais pour le moment, je ne suis pas au courant des intentions de Jack dans ce domaine.

C'est sur que la déclaration d'un tel type de structure apporterait vraiment une ouverture et une souplesse au langage Panoramic.

Quand à la réalisation d'un SGBD, il existe déjà des solutions assez élaboré comme SQLite par exemple.
J'avais fait un exemple qui s'appuyait sur la syntaxe du langage SQL.
Il fonctionnait pas trop mal.