Accès Violation....

Pour info,

je viens de faire une découverte qui pourrait rendre service.

En programmant j'ai créer un FORM 10000 et des Objets 10001, 10002
Et là, bingo "Accès Violation..." au lancement
J'ai donc changer mes numéros d'objets par 9100, 9101, 9102
Et là plus de problème.
Une remarque importante: dans ce même programme, j'ai 3 DLIST 100001, 100002, 10003 et je n'ai pas changer leurs numéros. Et cà marche.

J'en conclus que Windows n'accepte pas de "Printer" des objets dont le numéro depasse 9999. Sauf pour les objets invisibles comme DLIST.

à creuser, A+

Complément d'information

J'ai insérer ce petit bout de code

Code:

a=number_objects
caption 0,str$(a)

Et comme par hasard a=100.
J'ai donc ajouté un ALPHA pour dépacer 100 Objets. Et au lancement, il n'y a pas de Violation. Ce qui est normal, vu que le nombre d'objets n'est pas limité.
C'est juste pour info...

Effectivement, il y a un problème avec les numéros d'objet > 9999. Pour la form, ça a l'air de marcher aussi, mais dès qu'un ajoute un autre objet d'un numéro > 9999, ça plante. Voici une petite mise en évidence:

Code:

label click_1, click_1002

button 1: top 1,10: left 1,10: caption 1,"Montrer": on_click 1,click_1

form 10000: hide 10000: command_target_is 10000

' edit 1001: top 1001,10: left 1001,10    : ' ça marche ainsi
' edit 10001: top 10001,10: left 10001,10  : ' ça plante ainsi
edit 9999: top 9999,10: left 9999,10      : ' ça marche ainsi
button 1002: top 1002,40: left 1002,10: caption 1002,"Fermer": on_click 1002,click_1002
command_target_is 0

end

click_1:
show 10000: return

click_1002:
hide 10000: return

Et bien sûr, si on transforme 1002 et 10002, le problème s'aggrave...

Hé Bé Non,

essais çà

Code:

label click_1, click_1002

button 1: top 1,10: left 1,10: caption 1,"Montrer": on_click 1,click_1

form 10000: hide 10000: command_target_is 10000

 edit 1001: top 1001,10: left 1001,10    : ' ça marche ainsi
 edit 10001: top 10001,10: left 10001,10  : ' ça plante ainsi
alpha 100003:caption 100003,"XXXX"
edit 9999: top 9999,10: left 9999,10      : ' ça marche ainsi
button 1002: top 1002,40: left 1002,10: caption 1002,"Fermer": on_click 1002,click_1002
command_target_is 0

end

click_1:
show 10000: return

click_1002:
hide 10000: return

Chez moi çà plante pas ???????? et j'ai ajouté alpha 100003:caption 100003,"XXXX"
Va comprendre quelque chose....

J'ai trouvé, il faut 3 objets > 9999 pour que çà plante

Je pense que la limite dépend de la configuration du PC utilisé.
Car si on déclare un objet de numéro 1000, il s'alloue de la memoire pour 1000 objets même si seulement le 1000ème est utilisé.
Il me semble que j'en avais déjà parlé sur le forum au moment où j'ai levé la limitation sur le nombre d'objets.

Dans l'exemple proposé on obtient:

Code:

form 10000: rem il se crée 10000 objets
edit 1001: rem il se crée 1001 objets
edit 10001: rem le nombre d'EDIT passe à 10001
alpha 100003: rem il se crée 100003 objets
button 1002: rem il se crée encore 1002 objets

C'est vrai que ce n'est pas économique en mémoire, et qu'on a donc intérêt à se cantonner à des valeurs raisonnables pour les numéros d'objets... ce qui laisse quand même suffisamment de possibilités.

On peut aussi, mais c'est moins parlant, numéroter les objets avec une variable "N°dobjet" qu'on incrémente à chaque déclaration, en notant au passage dans une variable les numéros d'objets auxquels on va faire appel par la suite.
Ca évite de manipuler des numéros qui ne parlent pas du tout par eux-mêmes, et ça facilite grandement la mise au point, dans ce sens qu'on peut facilement intercaler des objets ou en supprimer sans se soucier de la numérotation, ça s'ajuste automatiquement.

Inconvénient (peut-être): ça multiplie le nombre de variables (la plupart des objets sont 'nommés'), mais pas tellement, et là on n'est pas limité.
Par exemple si on a un LIST avec une liste de fichiers, ça parlera plus si on l'appelle ListFich plutôt que 42 ou 1257.

Et là l'encombrement mémoire est minimum, puisque tous les numéros d'objets se suivent (à partir de 1) et les tables réservées par Panoramic sont au minimum possible.

Par exemple:

Code:

DIM nobj, ListFic, Memo1
LABEL Sousprog1, Sousprog2
...
nobj = 0
...
nobj=nobj+1: BUTTON nobj: TOP nobj, ......
            CAPTION nobj, "Bouton 1": ON_CLICK nobj, Sousprog1
nobj=nobj+1: LIST nobj: TOP nobj, ....
            ListFich = nobj
nobj=nobj+1: MEMO nobj: ...
            Memo1 = nobj
nobj=nobj+1: BUTTON nobj: TOP nobj, ......
            CAPTION nobj, "Bouton 2": ON_CLICK nobj, Sousprog2
...

on peut insérer (ou supprimer) une déclaration d'objet n'importe où, tous les numéros d'objets qui suivent vont changer automatiquement, mais on s'en fiche, le numéro d'objet lui-même n'a aucun intérêt, sauf pour l'interpréteur Panoramic.

Non, le diagnosyic n'est pas bon. Le code suivant plante:

Code:

label click_1, click_1002

button 1: top 1,10: left 1,10: caption 1,"Montrer": on_click 1,click_1

form 10000: hide 10000: command_target_is 10000

 edit 1001: top 1001,10: left 1001,10    : ' ça marche ainsi
 edit 10001: top 10001,10: left 10001,10  : ' ça plante ainsi
' alpha 100003:caption 100003,"XXXX"
' edit 9999: top 9999,10: left 9999,10      : ' ça marche ainsi
button 1002: top 1002,40: left 1002,10: caption 1002,"Fermer": on_click 1002,click_1002
command_target_is 0

end

click_1:
show 10000: return

click_1002:
hide 10000: return

D'abord, on voit qu'il n'y a que 2 objets dont le numéro est >9999. Même ceci plante:

Code:

label click_1, click_1002

button 1: top 1,10: left 1,10: caption 1,"Montrer": on_click 1,click_1

form 10000: hide 10000: command_target_is 10000

' edit 1001: top 1001,10: left 1001,10    : ' ça marche ainsi
 edit 10001: top 10001,10: left 10001,10  : ' ça plante ainsi
' alpha 100003:caption 100003,"XXXX"
' edit 9999: top 9999,10: left 9999,10      : ' ça marche ainsi
button 1002: top 1002,40: left 1002,10: caption 1002,"Fermer": on_click 1002,click_1002
command_target_is 0

end

click_1:
show 10000: return

click_1002:
hide 10000: return

alors que ceci passe:

Code:

label click_1, click_1002

button 1: top 1,10: left 1,10: caption 1,"Montrer": on_click 1,click_1

form 10000: hide 10000: command_target_is 10000

' edit 1001: top 1001,10: left 1001,10    : ' ça marche ainsi
' edit 10001: top 10001,10: left 10001,10  : ' ça plante ainsi
alpha 100003:caption 100003,"XXXX"
' edit 9999: top 9999,10: left 9999,10      : ' ça marche ainsi
button 1002: top 1002,40: left 1002,10: caption 1002,"Fermer": on_click 1002,click_1002
command_target_is 0

end

click_1:
show 10000: return

click_1002:
hide 10000: return

maisnsi l'on remplace alpha 100003 par edit 100003 en remplaçant caption par text, ça plante à nouveau. C'est à coup sûr lié au edit d'un numéro plus grand que 9999. Ce n'est pas un problème de taille mémoire car le alpha 100003 passe alors qu'il devrait réserver de la place pour 100003 objets.

Citation :

C'est à coup sûr lié au edit d'un numéro plus grand que 9999. Ce n'est pas un problème de taille mémoire car le alpha 100003 passe alors qu'il devrait réserver de la place pour 100003 objets.

Je regarde dès ce soir d'où vient cet important problème. Jusqu'à présent, ma réponse est basée sur une hypothèse. C'est vrai que si on fait button 10000, il y a de la réservation mémoire, mais ce n'est pas de la mémoire qui contient des objets, c'est de la mémoire allouée par Panoramic pour stocker quelques caractéristiques d'objets.

Je vois que le problème n'est pas aussi simple. Je ne pensais pas que si l'on déclare un objet avec le N° 100000 il y a réservation pour 100000 objets.
Je vais donc étudier le système de JL35. Cela dit mon système de numérotation est fait justement pour m'y retrouver. Je m'explique:

de 0 à 9 => réservé aux éventuels objets de FORM 0
de 10 à 99 => réservé pour MAIN_MENU
de 1000 à 99999 => réservé aux FORM 1000, 2000, etc...
de 100000 et plus => DLIST et autres objets qui ne sont pas liés à un FORM

Ainsi je déclenche par SUB_MENU 11 (par exemple) un branchement sur une section de programme xxx dont le FORM est 1000 et tout les objets 1001, 1002, 1003 etc... (ce qui me réserve 999 objets par form possible)
Donc dans mon code je sais que tout les objets qui commence par 1 sont liés au SUB_MENU 11 et à FORM 1000. Ce qui Fait que vais rapidement dans la partie du code qui m'intéresse.

Maintenant s'il est avéré qu'un objet de N° 1000000 déclenche une réservation mémoire proportionnelle, ce système de numérotation n'est pas bon. Je pensais que l'allocation de mémoire était proportionnelle au nombre réel d'objets + les DIM + les LABEL.

Affaire à suivre,

Effectivement, c'est ce que je pensais aussi. Dans ma DLL, j'utilise un mécanisme comparable pour stocker les données pour mes oblets TValueListEditor et TMaskEdit. Je suis en train de donner la possibilité de créer 10 objets de chaque type, mais je laisse le libre choix du numéro de l"objet qui de ce fait, peut être un numéro d'objet Panoramic, pour garder la logique. Je passe par une table contenant la liste des objets créés, avec une variable donnant le nombre d'objets créés. La table contient les numéros d'objet; en cas de nouvelle création, elle se rallonge, et en cas de suppression, elle est tassée automatiquement.