Manipulation de la gestion des évènements

Est-que l'on pourrait imaginer les commandes suivantes:

EVENT_OFF : ' désactive TOUS les évènements, les évènements sont perdus
EVENT_SUSPEND : ' met TOUS les évènements en file d'attente SANS les exécuter
EVENT_NEXT : ' permet l'exécution de l'évènement suivant dans la file d'attente
EVENT_ON : ' réactive la gestion des évènements; ceux en file d'attente seront exécutés
EVENT_SKIP : ' elimine le prochain évènement de la file d'attente
EVENT_CLEAR : ' effacer tous les évènements de la file d'attente

et une variable système retournant le type du prochain évènement dans la file d'attente:
type$ = EVENT_TYPE$
et une variable système retournant le numéro de l'objet ayant généré l'évènement:
n% = EVENT_OBJECT%

Ceci pourrait permettre de gérer les évènements d'une façon différente,

J'ai voulu revoir une question que j'ai publié à Jack, pour laquelle il ne m'a pas répondu concernant NUMBERS_EVENT, et qui était en rapport tes questions.

Or et cliquant sur mon pseudo et en regardant les messages que j'ai publié pour retrouver ce grand moment où j'ai publié ce post, je suis arrété à la page 24 sur 24, le 29 janvier 2010
Que sont devenus les autres pages?

Quoi qu'il en soit, je trouvais très curieux que dans un edit avec ON_CHANGE, je me retrouvais en faisant un essaye avec NUMBERS_EVENT à plus de 5000 (et j'étais arrété là) et je trouvais cela bizarre. J'avais fais un essai dans une boucle de dépiler les RETURN jusqu"à cela s'arrète à un, et cela fonctionnait.
Je demandais pourquoi, et savoir si cela était logique, parce que si on peut dépiler ou non les RETURN dans une boucle, et que cela ne plante pas, il y a quelque chose d'incompréhensible, ou alors c'est avec ON_CHANGE, il doit bien y avoir une limite dans les appels.

Finalement savoir où en sont les évènements, ça sert à quoi, si on peut faire n'importe quoi.

Sans précisions su Jack, je reste comme on dit sur ma fin.
@+.