InputEvent: événements invisibles
13 sujets de 1 à 13 (sur un total de 13)
-
Bin, contrairement à la position du curseur, tu peux être informé des changements de taille et emplacement de tes fenêtre sans passer par un inputhandler… donc quel est le problème ?
Bin, contrairement à la position du curseur,
J’ai l’impression que tu lis très vite les posts
J’ai besoin de connaitre la position du pointeur sur l’écran car je teste toutes les fenêtres Feelin pour voir si le pointeur ne serait pas en train de survoler un object. De plus, j’ai besoin du timer pour le pophelp, et là encore j’ai besoin des coordonnées de la souris, puis je cherche la fenêtre sous laquelle est le pointeur pour lui envoyer l’événement FF_EVENT_POPHELP avec FV_EVENT_POPHELP_OPEN, si le pointeur à bougé alors que le pophelp est actif j’envoie FF_EVENT_POPHELP avec FV_EVENT_POPHELP_CLOSE.BREF, si tu ne sais pas, dis le. Crois moi, si j’avais pas besoin de l’InputHandler je m’en passerai volontier. HORS j’en ai besoin, alors je ne cherche pas à comprendre
si tu as une idée je suis preneur !Pour le moment j’utilise une méthode combinée, mais ça me plait pas, je voudrais vraiment me débarrasser de ça et avoir une gestion centralisée.
Je ne peux pas tout faire avec les IDCMP. Et tant pis si je me répète, mais si aucune application Feelin n’a de fenêtre active, comment je peux savoir si le pointeur survole les objets, autrement qu’en utilisant les InputEvents ? Vu que les IDCMP ne sont envoyé qu’aux fenêtres actives.
Il en va de même pour les pophelp, pas de fenêtre active, pas d’INTUITICK, et j’ai pas envie que chaque application implemente cette fonction dans son coin avec le timer, ce serait stupide.
IDCMP c’est sympa, mais c’est beaucoup trop limité, et mal organisé surtout, quel gachit de bits !
J’ai envie que mes bouttons frémissent quand on les approches avec convoitises, même si leur fenêtre n’est pas active. J’ai pas envie de me retrouver avec une interface frigide. Sinon à quoi ça sert que ducros se décarcasse ?
Une fenêtre inactive qui réagit au passage de la souris, je trouve justement énervant et j’essaye toujours de désactier la fonction si c’est possible
En plus cela t’oblige à faire un inputhandler méchamment compliqué qui va manger pas mal de perfs lorsque l’on bouge la souris.
Enfin… si tu veux vraiment faire cela, je pense que tu n’as pas le choix.
Tu as déjà regardé pour utiliser un ih à travers la commodities.library ? Après tout, c’est la méthode recommandée et Magellan le fait
Pour le timer et vu que tu clones tout l’OS dans Feelin, j’imagine que tu va de toute façon rajouter une nouvelle API dédiée
Pourquoi ne sommes nous que deux dans cette discussion ?
Bouge toi yomgui.
C’est pas la fenêtre qui réagit au passage de la souris, mais les objets qu’elle contient. Comme le font touts les autres systèmes pour montrer qu’une action est réalisable. C’est très bien pour guider l’utilisateur. Et comme on m’a demandé si je pouvais l’ajouter, sympa comme je suis, je l’ajoute ! Et j’en profite au passage pour gommer un peu plus le système
Quand au InputHandler, il risque pas de manger les performances du système, puique c’est moi qui l’écris
(auto-jetage-de-fleurs). Comme en plus il se substitue aux routines qu’aurait utilisé Intuition, tout le monde est content.« méthode recommandée« , c’est la chose la plus drôle que j’ai entendu depuis 1992 !! En plus, je ne « clone » pas le système, je fais les choses à ma façon : simple, puissant, efficace, maléable (auto-jetage-de-fleurs-bis)
Quand à Yomgui, il est très occupé en ce moment le pauvre. Mais je pense à lui chaque fois que je vois une macro « __MORPHOS__ » ! Mais c’est cool de faire la conversation tous les deux, sans tous ces newbies
PS: YOMGUI TU ME MANQUES !!
PS2: Henes, tu bosses sur quelque chose en ce moment ?
Les autres systèmes sont énervants à l’utilisation
La méthode est recommandée par cbm dans la doc de la cxlib :
Custom input handlers do have their drawbacks, however. Not only are these handlers hard to program, but because there is no standard way to implement and control them, multiple handlers often do not work well together. Their antisocial behavior can result in load order dependencies and incompatibilities between different custom input handlers. Even for the expert user, having several custom input handlers coexist peacefully can be next to impossible.
Et puis comme ça mon post est aussi gros que le tiens.
PS: Toujours.
Et puis comme ça mon post est aussi gros que le tiens.
C’est pas la taille qui compte, c’est la façon de s’en serv… Oups.
BREF, « cbm » c’est qui ?
Ils y connaissaient rien, faut voir comment est foutu BOOPSI ! De toute façon j’aurais besoin d’un InputHandler à un moment ou à un autre, surtout lorsque je commencerai à mettre des menus partout ! Et ui, comment faire sinon, pour que quand je clique sur mon sublime menu, la fenêtre qui est censée rester active ne l’est plus tout à coup…Les InputHandlers c’est bien, mangez-en !
Raaaaa, ayé c’est fini. 8H25… encore une bonne nuit de sommeil… que je n’aurais pas. M’enfin c’est pour le bonheur de la communauté (et mon plaisir tout personnel) alors
@Henes: J’ai bien fais de faire comme je voulais, ça marche drôlement mieux et c’est *beacoup* plus rapide que de passer par Intuition. Je suis tétu, mais des fois c’est bien
13 sujets de 1 à 13 (sur un total de 13)
- Vous devez être connecté pour répondre à ce sujet.
