Créer un objet dont le type est passé en paramètre

Aujourd'hui, on crée les objets par des commandes dont le nom implique leur type. Exemple: BUTTON, EDIT, ...

On a une fonction OBJECT_TYPE qui nous renseigne sur le type d'un objet dont on passe le numéro en paramètre. C'est très utile.

Maintenant, j'aimerais avoir une commande du genre:

Code:

CREATE_OBJECT TYPE, N
  TYPE est la valeur numérique de l'objet à créer, telle qu'elle serait retournée par OBJECT_TYPE()
  N est le numéto de l'objet à créer

ou

Code:

CREATE_OBJECT TYPE$, N
  TYPE$ est une chaîne de cacatères contenant le type de l'objet à créer ("BUTTON", "EDIT", ...)
  N est le numéto de l'objet à créer

Par ailleurs, je me permets de relancer ma demande postée ici:
https://panoramic.1fr1.net/t6711-adresse-d-un-tableau#80461

La première forme me plait bien car on passe le paramètre sous forme numérique.
De même, avoir l'adresse d'un tableau ou d'un élément d'un tableau est possible.
Dans un premier temps, je vais faire integer(&matrice) comme tu le proposes, mais je pense que cela ne sera pas suffisant. On verra bien...

Mais pour que je sorte une version contenant ces 2 possibilités, il va me falloir quelques jours.
Il y a un moment que je n'ai plus travaillé sur panoramic car j'ai fait une (longue) pause. Il faut que je redémarre mes "machines de production" et que je reprenne là où j'avais arrêté. Cela va prendre un peu de temps...

Il y a aussi des choses à reprendre, comme le dessin de lignes ou le dernier point n'est pas tracé. J'avais dit que j'allais modifier la documentation, mais je pense que modifier le code est plus logique...
Bref, je pense qu'une nouvelle version va bientôt pointer son nez.

Et il y a bien d'autres choses à faire comme remanier le site qui est vieillissant.

Ah, super, Jack ! Surtout, va à ton rythme - il n'y a pas d'urgence pour nos.

Je résume les 3 points:
1. pouvoir provoquer la création d'une variable simple Panoramic via un message envoyé par SEND_MESSAGE (pas par POST_MESSAGE !) similaire à USER_EVENT, sauf que ce message est traité directement par l'interpréteur de Panoramic et non transmis au programme application, et qui retourne l'addresse de la variable créée

2. avoir un accès plus général aux tableaux multi-dimensionnels de Panoramic, soit en ayant l'adresse d'un élément quelconque (@tableau[3,5] par exemple), soit en ayant accès au tableau créé par Delphi sont les éléments sont @Tableau[0], @Tableau[1] etc, quelqu'en soit la syntaxe en Panoramic. Probablement par une fonction spécifique...

3. pouvoir créer un objet en spécifiant le numéro du type de l'objet et son numéro Panoramic

Bonjour à tous les 2 et bonjour à tous !

Il y a du mouvement dans l'air à ce que je vois... Super !

Ca tombe bien car moi aussi j'avance sur mon éditeur d'objet...

Bonjour à toutes et à tous.

Je suis pour, cela va réduire considérablement ma procédure de création d'objet.

Bonjour à tous

En attendant, il est possible de simuler "CREATE_OBJECT type, N" en passant par un sub comme je l'ai fait ici (c'est le sub MAKE_OBJECT_FROM_TYPE(typ%,obj%))

Je suis en train de remanier Panoramic et j'ai fait une version "expérimentale" et provisoire (elle ne sera disponible que pendant quelques jours) à des fins de test.
Cette version est basée sur l'éditeur ELIP 6.05 fait par Marc. Cependant, vu mon souhait de simplicité, j'ai remanié un peu ELIP pour qu'on n'ait pas besoin de l'accompagner de Make_Exe pour qu'il fonctionne: Make_Exe est inclus dans Elip_v6_05.exe, il suffit de lancer Elip_v6_05.exe et c'est tout.
Cette version d'ELIP est téléchargeable ici :
https://e-nautia.com/karma/disk/PANORAMIC/Elip_v6_05.exe

Attention, cette version est réduite par rapport à la version habituelle car comme je l'ai dit, je remanie Panoramic et je n'ai pas terminé.
Dans cette version, il n'y a pas:
- les objets SCENE2D, SERIAL, LED1, DIGIT1, SWITCH1
- le pilotage d'EXCEL (EXCEL_XXX)
- l'archivage (ARCHIVER_XXX),
- les sonorités (BEEP_XXX),
- la musique (MIDI_XXX),
- les entrées/sorties (PARALLEL_XXX).

J'ai sorti cette version pour montrer les 4 nouvelles fonctions qui donnent l'adresse des variables. (Klaus l'avait plusieurs fois demandé).
Ces nouvelles fonctions ne sont pas encore colorée dans ELIP.

Nouvelles fonctions :
ADR() qui retourne l'adresse d'une variable simple,
ADR1() qui retourne l'adresse d'une variable tableau à 1 élément,
ADR2() qui retourne l'adresse d'une variable tableau à 2 éléments,
ADR3() qui retourne l'adresse d'une variable tableau à 3 éléments.

Tout d'abord, je suis bien conscient que ces fonctions ne s'adressent qu'aux "spécialistes", à ceux qui veulent par exemple appeler des DLL avec des adresses passées en paramètre, et ce n'est pas le cas de la majorité des utilisateurs de Panoramic. Ces 4 nouvelles fonctions ne s'adressent donc pas à tous, mais à des  utilisateurs avertis, qui maitrisent les PEEK, les POKE, les PEEK_REVERSE et autres ADR_VARTAB, bref, à des utilisateurs qui jonglent avec les octets et les adresses.

Avant de comprendre les exemples de ces fonctions, il faut savoir que dans cette version:
- une variable entière occupe 4 octets en mémoire,
- une variable réelle occupe 8 octets en mémoire,
- une variable string est codée en Unicode UTF-16 à zéro-terminal, c'est à dire que si elle a n caractères, elle occupera 2xn+1 octets en mémoire et le dernier octet est un zéro.

Exemple d'utilisation de ADR() :

Code:

dim adrb%,adrc%,i%
dim a%,b,c,d$

peek_reverse:' Windows est de type Big Endian

' exemple avec un entier
a%=100:' un entier est codé sur 4 octets
print peek32(adr(a%)):' affiche le contenu de a% soit 100

' exemple avec un réel
b=111.222
c=0
adrb%=adr(b):' adresse du réel b
adrc%=adr(c):' adresse du réel c
' on recopie b dans c par des peek et poke
for i%=0 to 7:poke adrc%+i%,peek(adrb%+i%):next i%:' un réel est codé sur 8 octets
print c:' affiche 111.222

d$="Hello"
' affiche les 5 caractères de la chaine d$
' un caractère est codé sur 2 octets et on n'en utilise qu'un
print chr$(peek(adr(d$)))+chr$(peek(adr(d$)+2))+chr$(peek(adr(d$)+4))+chr$(peek(adr(d$)+6))+chr$(peek(adr(d$)+8))

Exemple d'utilisation de ADR1() :

Code:

dim a%(4),b$(4),c(4)
dim adrs%,adrc%,copy,i%

a%(3)=4:b$(4)="Hello":c(3)=4.4

adrs%=adr1(a%,3):' adresse de a%(3)
peek_reverse:' Windows est du type Big Endian
print peek32(adrs%):' affiche le contenu de a%(3) soit 4

adrs%=adr1(b$,4):' adresse de b$(4)
' affiche les 5 caractères de la chaine b$(4)
print chr$(peek(adrs%))+chr$(peek(adrs%+2))+chr$(peek(adrs%+4))+chr$(peek(adrs%+6))+chr$(peek(adrs%+8))

adrs%=adr1(c,3):' adresse de c(3)
copy=0.0
adrc%=adr(copy):' adresse de copy
' par des peek et poke, on recopie c(3) dans copy
for i%=0 to 7:poke adrc%+i%,peek(adrs%+i%):next i%:' un réel est codé sur 8 octets
print copy:' affiche 4.4

Exemple d'utilisation de ADR2() :

Code:

dim a%(4,3),b$(4,3),c(4,3)
dim adrs%,adrc%,copy,i%

a%(2,1)=10:b$(2,1)="Hello":c(4,1)=18.18

adrs%=adr2(a%,2,1):' adresse de a%(2,1)
peek_reverse:' car Windows est du type Big Endian
print peek32(adrs%):' affiche le contenu de a%(2,1) soit 10

adrs%=adr2(b$,2,1):' adresse de b$(2,1)
' affiche les 5 caractères de la chaine b$(2,1)
print chr$(peek(adrs%))+chr$(peek(adrs%+2))+chr$(peek(adrs%+4))+chr$(peek(adrs%+6))+chr$(peek(adrs%+8))

adrs%=adr2(c,4,1):' adresse de c(4,1)
copy=0.0
adrc%=adr(copy):' adresse de copy
' par des peek et poke, on recopie c(4,1) dans copy
for i%=0 to 7:poke adrc%+i%,peek(adrs%+i%):next i%:' un réel est codé sur 8 octets
print copy

Exemple d'utilisation de ADR3() :

Code:

dim a%(4,3,2),b$(4,3,2),c(4,3,2)
dim adrs%,adrc%,copy,i%

a%(3,2,1)=10
b$(3,2,1)="Hello"
c(3,2,1)=18.18

adrs%=adr3(a%,3,2,1)
' print adrs%
peek_reverse:' car Windows est du type Big Endian
print peek32(adrs%):' affiche le contenu de a%(3,2,1) soit 10

adrs%=adr3(b$,3,2,1)
' affiche les 5 caractères de la chaine b$(3,2,1)
print chr$(peek(adrs%))+chr$(peek(adrs%+2))+chr$(peek(adrs%+4))+chr$(peek(adrs%+6))+chr$(peek(adrs%+8))

adrs%=adr3(c,3,2,1)
copy=0.0
adrc%=adr(copy)
' par des peek et poke, on recopie c(4,1) dans copy
for i%=0 to 7:poke adrc%+i%,peek(adrs%+i%):next i%:' un réel est codé sur 8 octets
print copy:' affiche 18.18

Bien entendu, les variables peuvent aussi être des variables locales (déclarées par DIM_LOCAL).
Cependant, il y a encore un bug à résoudre: les variables tableaux ne fonctionnent pas. Pour le moment, seul ADR() fonctionne avec les variables locales.

A suivre ...

Bonjour à tous !

@Jack
Merci pour ton travail et le partage de ton langage de programmation Panoramic.

Le lien de téléchargement e-nautia dans ton post ci-dessus semble défectueux.

Editeur : Merci d’avoir testé et utilisé EliP. A ce sujet, n’hésite pas à modifier ou supprimer le nom d’EliP ainsi que l’à propos et le filigrane. L’éditeur étant en quelque sorte une vitrine pour un langage de programmation, les mots importants sont « Panoramic » et son créateur « Jack ». Donc si tu le souhaites, n’aie aucun scrupule à supprimer le nom d’EliP et bien sûr mon nom aussi.

Bon courage pour la suite !

Marc a écrit:

Le lien de téléchargement e-nautia dans ton post ci-dessus semble défectueux.

Le lien de téléchargement est corrigé.

Marc a écrit:

Editeur : Merci d’avoir testé et utilisé EliP. A ce sujet, n’hésite pas à modifier ou supprimer le nom d’EliP ainsi que l’à propos et le filigrane. L’éditeur étant en quelque sorte une vitrine pour un langage de programmation, les mots importants sont « Panoramic » et son créateur « Jack ». Donc si tu le souhaites, n’aie aucun scrupule à supprimer le nom d’EliP et bien sûr mon nom aussi.

Merci pour ta proposition.
ELIP est un éditeur qui n'a besoin d'aucune ressource pour fonctionner: aucune DLL, aucune image (les icônes sont tracées directement). Il est facilement transposable à d'autres OS comme Linux ou MAC OS X.
De plus, en utilisant un tel éditeur, je pourrai me consacrer uniquement à l'amélioration du langage Panoramic.

Bonjour Jack et bonjour à tous !

L'idée d'utiliser Elip comme éditeur par défaut me semble une bonne idée.
C'est une charge de moins pour toi.

Par contre il serai quand même pratique d'avoir la possibilité de changer les couleurs, la police et la taille de police.
Bon c'est un détail je sais... A voir pour les prochaines versions.

Concernant les nouvelles fonctions, je ne suis pas assez calé pour répondre. Attendons la réponse de Klaus.

Par contre comme tu indique intégrer MAKE.EXE est ce que tu continuera a faire une version séparée ?
Car mon éditeur de code l'utilise et je serai bloqué si tu ne le maintient pas.

Pour ma part je travaille sur l'éditeur d'objet qui est réalisé à 90%.
Donc il y aura bientôt un vrai éditeur d'objet pour Panoramic. Ce sera encore une belle avancée !

Encore merci pour ces nouveautés Jack.

Merci pour ces nouvelles fonctions, Jack ! Ce n'est pas exactement ce que j'avais suggéré, mais je pense que je peux faire avec... surtout si, comme c'est probable, les adresses de suivent, comme ceci:
si a%=adr2(tableau%,3,0), alors adr2(tableau%(3,1) = a%+4 et ainsi de suite.

Pour la part, j'avais suggéré quelque chose de plus simple. Il aurait suffi d'avoir une fonction retournant l'adresse du "tableau de base" que Delphi génère dans le cas de tableaux milti-dimensionnels. Comme ceci:

Code:

dim tab1%(3,5)
génère
tab1_integer: array [0..2] of array [0..4] of integer;

La valeur intéressante serait @tab1_integer.
Cette valeur pointe sur le premier élément d'un tableau deux éléments donnant les adresses de tab1_integer[0] et tab1_integer[1]. A partir de cette unique valeur, on a accès à l'ensemble des éléments du tableau. Idem pour les tableaux de 3 dimensions. Idem également pour les tableaux de chaînes de caractères, sachant que chaque élément d'un tel tableau contient, non pas la chaîne de caractères elle-même, mais un PString pointant sue la chaîne en question.

Avec ma demande initiale, je voulais justement pouvoir balayer l'ensemble d'un tableau multi-dimensionnel, à partir d'une seule adresse?

Cela aurait peut-être été plus simple à implémenter, ne requiert qu'une seule fonction et, surtout, est universel pour tous les tableaux.

Ce sont juste des réflexions à partir de mon point de vue personnel. Je m'adapterai...

J'ai retiré du téléchargement cette version de Panoramic basée sur ELIP, car comme je l'avais dit, c'était une version expérimentale et provisoire.
L'intérêt de cette version était qu'elle n'avait pas besoin de Make_Exe pour fonctionner.
J'espère que les nouvelles fonctions ADR(), ADR1(), ADR2() et ADR3() donnent satisfaction à Klaus.
A partir de maintenant, les versions de Panoramic qui sortiront seront basées sur ELIP et n'auront plus besoin de Make_Exe pour fonctionner.

Citation :

J'espère que les nouvelles fonctions ADR(), ADR1(), ADR2() et ADR3() donnent satisfaction à Klaus.

Ben... certes, c'est intéressant. Cependant, ce n'est pas ce que je cherchais. Regarde mon post juste au-dessus.

Je cherchais un accès à l'adresse de la table de basse construite par Delphi lorsqu'il construit un tableau dynamique. Il s'agit d'une liste de pointeurs, pointant chacun vers le premier élément d'une dimension. Ainsi, on peut avoir facilement accès dans une DLL à tous les éléments d'un tableau, quelque soit son nimbre de dimensions et la longueur de chaque dimension.

@Klaus:

J'ai bien compris ta demande, mais elle est pratiquement impossible à réaliser.
Parce qu'en Panoramic, les variables ne sont pas stockées comme tu l'imagines. Les variables tableau ne sont pas indépendantes, mais sont toutes stockées dans le même tableau.

Puisque tu prends un exemple de variables à 2 dimensions,
dim tab1%(3,5) ne génère pas array [0..2] of array [0..4] of integer; ( plus exactement array [0..3] of array [0..5] of integer; car tab1%(0,0) et tab1%(3,5) existent)
car toutes les variables entières à 2 dimensions sont stockées dans le même tableau dynamique TI2 défini par : array of array of integer;

Si on déclare tab1%(3,5), les valeurs de tab1% vont aller dans TI2[N,M] à TI2[N+3,M+5] avec N et M qui dépendent non seulement des tailles des tableaux déclarés avant tab1% mais des variables "temporaires" définies par DIM_LOCAL.
En effet, à chaque sous-programme qui déclare des tableaux locaux à 2 dimensions par DIM_LOCAL, ils vont aussi aller dynamiquement dans TI2, mais ils vont être retirés dynamiquement de TI2 lors du END_SUB ou du END_FNC, par retassement du tableau TI2.
N et M de mon exemple ne sont donc pas fixes: ils peuvent varier car le tableau TI2 peut être modifié en fonction des appels de sous-programmes ou de fonctions.

@Jack:
La, je ne comprends pas.

Chez moi, si, en Delphi 6, je déclare

Code:

var
  integerarray: array of array of iinteger;
  stringarray: array of array of string;
...
implementation
...
SetLength(integerarray,2);    // je crée un tableau A de deux éléments contenant des pointeurs nil
SetLength(stringarray,2);    // je crée un autre tableau B de deux éléments contenant des pointeurs nil
SetLength(iintegerarray[0],3);   // je crée un tableau A1 de 4 éléments (le nom est symbolique, bien sûr)
SetLength(iintegerarray[1],5);   / je crée un tableau A2 de 6 éléments (le nom est symbolique, bien sûr)
// je viens de créer deux nouveaux tableaux, l'un de 4 éléments, l'autre de 6 éléments.
// A[0] contient un pointeur vers le tableai A1
// A[1] contient un pointeur vers le tableau A2
...
// idem pour lstringarray.

La différence pour ces deux types de tableaux réside dans le fait que les éléments des tableaux A[x] contiennent les valeurs entières directement alors que les éléments des tableaux B[x] contiennent des pointeurs (pstring) vers les éléments strings individuels.

Donc, chez moi, en Delphi 6, si j'ai lavaleur @integerarray qui est l'adresse du tableau principal A, je peux facilement atteindre n'importe quel élément du tableau. Idem pour @stringarray.

Le même mécanisme d'ailleurs s'applique pour les tableaux de 3 ou plusieurs dimensions.

Est-ce que tu utilises une implémentation différente ? Si tel est le cas, alors j'abandonne dans dans ce cas, il s'agirait d'une gestion de mémoire "propriétaire" et je ne pourrai pas appliquer la même logique...

EDIT

D'ailleurs, je sais bien que des tableaux déclarés en DIM_LOCAL "disparaisssent" après la sortie de la SU ou de la fonction et que çé peut décaler l'emplacement des variables. Mais même des tbaleaux déclarés par DIM peuvent "bouger" lorsqu'un change leurs longueurs ou lorsqu'un modifie des variables string déclarées "avant" la création de ces tableaux. Je connais toutes ces contrraintes des allocations dynamiques et du garbadge collector de Delphi. Mais je peux maîtriser cela par des règles strictes d'usage du ou de ces quelques tableaux concernés pour éviter tout conflit.

Il n'est évidemment pas question de mémoriser de telles adresses et de les réutiliser plus tard. Elles serviront juste pour appeler unen fonction DLL, et encore uniquement comme résultat d'une de fonction ADR... directement comme paramètre à DLL_CALLx, jamais via une variable intermédiaire.

Klaus a écrit:

Est-ce que tu utilises une implémentation différente ?

Oui, et c'est ce que je t'ai expliqué.
Si on déclare par exemple 10 variables tableau à 2 dimensions, il n'y a en fait en mémoire qu'un seul tableau à 2 dimensions qui va contenir toutes les valeurs des 10 tableaux.
Je ne déclare pas un tableau par variable, mais il y a des tableaux dynamiques pour les entiers, les réels, les strings et qui contiendront tous les tableaux qui seront déclarés par DIM et DIM_LOCAL.

J'ai l'impression que tu demandes à nouveau ce que je t'avais fait il y a 3 ans avec la variable système ADR_VARTAB. Cette variable est un pointeur sur un tableau de pointeur, chaque pointeur de ce tableau contient l'adresse des tableaux de variables comme défini ici:
https://panoramic.1fr1.net/t5907-bug-off_activate-0-sans-effet#73873

Voici le code actuel de ADR_VARTAB:

Code:

    Ptr_Var := Addr(DNoyau.tv); // pointe sur TV
    VarTab[0] := Ptr_Var;
    Result := integer(Ptr_Var);  // ADR_VARTAB

    VarTab[1] := Addr(DNoyau.ti); // pointe sur TI
    VarTab[2] := Addr(DNoyau.tr); // pointe sur TR
    VarTab[3] := Addr(DNoyau.tc); // pointe sur TC
    VarTab[4] := Addr(DNoyau.ti2); // pointe sur TI2
    VarTab[5] := Addr(DNoyau.tr2); // pointe sur TR2
    VarTab[6] := Addr(DNoyau.tc2); // pointe sur TC2
    VarTab[7] := Addr(DNoyau.ti3); // pointe sur TI3
    VarTab[8] := Addr(DNoyau.tr3); // pointe sur TR3
    VarTab[9] := Addr(DNoyau.tc3); // pointe sur TC3

Bon, je comprends.

Je vais voir ce que je peux obtenur par ADR_VARTAB...

Oups... ADR_VARTAB n'est pas reconnu, ni par Panoramic via ELIB ni par PANORAMIC_EDITOR V0 9 29i11 du 07 11 2021 !

Bonsoir à tous !

@Klaus


Cela semble fonctionner en déclarant préalablement ADR_VARTAB comme une variable ordinaire...




A vérifier...

Merci, Marc ! Jamais je n'aurais pensé à cette astuce !