problème avec une variable

[Zorro]

Entre "Global a.s" et "a.s =""", tu n'as pas non plus la même porté de variable non plus.

vérification faite , tu as raison ,
si la variable est initialisé sans le mot "Global" , alors elle n'est pas accessible dans les procedures ..
mais est accessible de partout dans le listing ...
c'est l'une des particularité du Purebasic
car en principe en "Basic" toute variable declarée en dehors d'une procedure est réputé Global ...

[GallyHC]

Heuu la j'ai un doute pour exemple si je fait :

Code : Tout sélectionner

a.s = "test"

Procedure f()
  Debug a
EndProcedure

f()

Ce n'est pas le même résultat que si je fait :

Code : Tout sélectionner

Global a.s = "test"

Procedure f()
  Debug a
EndProcedure

f()

Les variables n'ont aucunement les mêmes portées.

GallyHC

PS: tu as corriger ton post, pendant que j'écriais le mien ^^.

[Zorro]

oui j'avais corrigé mon propos .. pendant que tu ecrivait sans doute

[Zorro]

en fait en y reflechissant, c'est plutot normal que la variable a.s=""
ne soit pas accessible dans une procedure

vue qu'une procedure installe son contexte LOCAL (sa propre PILE)
un a.s="" dans la procedure ne doit pas entrer en conflict avec un a.s="" a l'exterieur de celle ci ...


je suppose que l'ajout du mot GLOBAL a pour but de modifier ça ....

[Marc56]

Même si ça peut paraitre contraignant au premier abord, j'aime bien cette possibilité d'obliger à ̶d̶é̶c̶l̶a̶r̶e̶r̶ définir les variables selon un des 5 modes (Define, Global, Protected, Shared, Static)

La définition obligatoire des variables est ce qui fait la stabilité et la vitesse des programmes en Pascal depuis des dizaines d'années (et encore, en Pascal il faut déclarer à des endroits précis).

Quand on s'oblige à définir à l'avance l'usage d'une variable on s'oblige aussi à bien gérer la mémoire (donc penser à "vider" ce qui ne sert plus). Sans cela on faisait souvent presque tout en variable globale pour la facilité, et les programmes enflaient d'une manière démesurée en RAM

Vive EnableExplicit il faudrait qu'il s'inscrive par défaut dès qu'on fait CTRL+N
(oui, on sais t'aime pas donc c'est bien que ce soit optionnel)

[GallyHC]

Oui, j'ai écris pendant que tu été en train de modifier ton post ^^.
Cela est normal et justement de mémoire ce problème en GFABasic par exemple avait été corriger par la suite et tout langage Basic évoluer avait cette évolution (VisualBasic par exemple).

Tout de même merci, ça a permis de remettre les choses en places, même si le sujet principal a un peu dériver (mais pas de beaucoup) ^^.

@Marc56 > les langages très utilisé en milieu professionnel comme java (Jakarta, même si cela risque de rapidement baissé), oblige les déclarations "variable/type" et une mal faite est considérer comme une erreur par les vérificateurs de code (comme "sonarlint").

GallyHC

[Micoute]

En fait Define.<type> devrait plutôt s'appeler Define_Type.<type>

[GallyHC]

Pas faux ou juste Declare, même si cela est deja utiliser autrement ^^.

Après, c'été juste une question de non compréhension avec ce problème, je ne critique pas PB, car il est fait pour que l'on en fasse le moins possible et aide beaucoup l'utilisateur pour faire un développement simple. Il manque quelques trucs comme par exemple les conditions ternaires (le IIF en visualbasic) et surement d'autre choses, mais il permet déjà beaucoup de chose.

Aussi la choses qui m'aurait éviter de faire ce truc, c'est déclarer un tableau et lui affecter automatiquement des valeurs du style "dim tableau.l() = {0,1,2,3,4,5,6}" pour un tableau à taille non fixe et "dim tableau.l[] = {0,1,2,3,4,5,6}" pour un autre avec une taille fixe ou des trucs comme cela, je ne serais pas passer par "DataSection" pour alimenter ces mêmes tableaux .

Et d’ailler avec cette discussion cela m'a permis de me dire, vu que j'utilise toujours les mêmes tableaux dans la méthode au lieu de les déclarés à chaque appel, je vais les mettre en static pour que si il sont déjà affecter ne pas devoir le refaire .

Tout est parti d'un code du forum anglais sur des code à barre "https://www.purebasic.fr/english/viewto ... 63#p533663". Ayant pas mal de compétence dans le domaine et ne voulant pas refaire ce que d'autres on surement fait et bien fait, j'ai cherché et trouvé ce code.
Il été pas mal intéressant car il y avait une seul routine d'affichage et je n'avais pas penser a faire comme cela et après avoir localiser un problème sur le code-128, j'ai ajouter déjà 3 autres type de code-barre. Maintenant je m'attaque a un autre type de code-barre beaucoup plus complexe (pourquoi? juste que ce soit compatible X32 et X64, ce qui n'est pas forcement vrai avec les Dll) et donc pour le moment, je suis sur le "DataMatrix" et j'espère par la suite le faire pour du "QR-Code" (Si j'arrive déjà avec le datamatrix).

Pour le moment le code modifier du site anglais permet d'encoder "EAN-8, EAN-13 (UCPA), 2of5, Code-11, Code-39, Code-93, Code-128 et PostNet) et c'est déjà pas mal.

Voila vous savez tout lollllllll,
Cordialement,
GallyHC

[Micoute]

Code : Tout sélectionner

;TABLEAU DE CHAINES
;===============
Declare AddArray(Array idTableau.s(1),var.s)

Global Dim MonTableau.s(0)

AddArray(MonTableau(),"10,1,2,42,13,21,420,24,3,1")

; vérification 
For i = 0 To ArraySize(MonTableau())
  Debug MonTableau(i)
Next i  

Procedure AddArray(Array idTableau.s(1),var.s)
  For i = 0 To CountString(var.s,",")
    ReDim idTableau(i)
    idTableau(i) = StringField(var.s,i + 1,",")
  Next i
EndProcedure

;TABLEAU D'ENTIERS
;==============
Declare AddArray(Array idTableau.i(1),var.s)

Global Dim MonTableau.i(0)

AddArray(MonTableau(),"10,1,2,42,13,21,420,24,3,1")

; vérification 
For i = 0 To ArraySize(MonTableau())
  Debug MonTableau(i)
Next i

Procedure AddArray(Array idTableau.i(1),var.s)
  For i = 0 To CountString(var.s,",")
    ReDim idTableau(i)
    idTableau(i) = Val(StringField(var.s,i + 1,","))
  Next i
EndProcedure

;TABLEAU DE FLOTTANTS
;=================
Declare AddArray(Array idTableau.f(1),var.s)

Global Dim MonTableau.f(0)

AddArray(MonTableau(),"10.0,1.1,2.2,42.3.3.4,21.5,420.6,24.7,3.8,1.9")

; vérification 
For i = 0 To ArraySize(MonTableau())
  Debug StrF(MonTableau(i), 1)
Next i

Procedure AddArray(Array idTableau.f(1),var.s)
  For i = 0 To CountString(var.s,",")
    ReDim idTableau(i)
    idTableau(i) = ValF(StringField(var.s,i + 1,","))
  Next i
EndProcedure

Pense aux balises CODE vieille branche. (Ar-S)

[GallyHC]

merci Micoute, je fais presque la même chose avec les "datasection", mais j'aime bien ta méthode aussi, je vais voir ce qui serait le plus "propre" (question de point de vu ^^, peu être le tienne, même si a la base je ne voulais justement pas passé par une méthode ^^.

Je vais tester et peu être généraliser ta méthode. Merci pour ces exemples fort instructif (comme quoi en développement, il n'y a pas une résolution a une problématiquement) et j'aurais vu une autre façon de voir les choses, ce que j'adore avant tout dans le dev. Je note bien l'idée et je vais voir ce qui est le mieux.

Cordialement,
GallyHC

[Naheulf]

Personnellement, lorsque j'ai le choix, j'évite la méthode de Micoute qui consiste à passer une chaîne constante à une procédure pour initialiser un tableau.
Les raisons sont les suivantes :
- Temps de chargement augmenté
- Taille de l'exécutable final augmenté (quoique ça dépends des chaînes)

Bon, si mes valeurs initiales sont forcement dans une chaîne de caractères (fichier csv) ya pas d'autre solution...

[GallyHC]

Auto-Correction c'est bien possible en fait ^^

Cordialement,
GallyHC

[Zorro]

@micoute , heu.... faire attention a l'utilisation des chaines de caracteres
c'est vraiment plus long que l'utilisation d'entier ou de flottant ...

le passage par chaine de caractere est pratique , mais dans le cadre de nombreuses données numérique
faut éviter .... sinon pour le coup ça va etre long ... et plus gros en RAM , un caractere prends plus de place qu'un entier (surtout en UNICODE )

et pourquoi pas utiliser les Liste-chainée ?
je les trouves bien plus pratique que les tableaux .. (plus rapide ??? )
les tableaux, maintenant, j'evite... trop restrictif .. meme si REDIM apporte une facilité

[Micoute]

Oui, je suis d'accord, mais c'était surtout pour l'aspect ludique, une idée en apporte souvent une autre.

[Zorro]