Les fleches comme raccourcis clavier
Philippe49
Membre
Bonjour à tous
The problem : >:(
et là , patratas, les flèches de déplacement dans le texte sont court-circuitées par les flèches du menu du diaporama, ce qui est désagréable.
Comment faire pour que lors de l'existence du panel les NSTextField soient prioritaires sur les options du menu ?
The problem : >:(
- Je fais actuellement une application de diaporama, les flèches décalent les vues une à une.
- Mais j'utilise également un panel via beginSheet: modalForWindow: ... dans lequel se trouve des NSTextField où l'utilisateur doit écrire ce qu'il veut
et là , patratas, les flèches de déplacement dans le texte sont court-circuitées par les flèches du menu du diaporama, ce qui est désagréable.
Comment faire pour que lors de l'existence du panel les NSTextField soient prioritaires sur les options du menu ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Essayés:
1. [NSApp makeFirstResponder:myPanel];
2. [NSApp runModalForWindow:myPanel]
Le premier ne fait rien
Le deuxième bloque les options du menu, mais également les réactions du textfield avec les flèches
Comment captures-tu les touches fléchées ?
.
Ils sont en raccourcis clavier du menu principal.
Je pourrais intervenir dans la méthode qui ouvre le panel en désactivant ces raccourcis, mais cela me semble de la bidouille.
Et pour le textfield je voudrais conserver le comportement standard de déplacement par les flèches
Les raccourcis clavier du main menu sont gérés par NSApp : donc les événements sont capturés au tout début de la chaine d'événement (et ne sont pas transmis au fenêtres ou panels ouverts).
Le problème est que l'utilisation de touches multi-usage (comme les touches fléchées) an tant que raccourci clavier, c'est un peu jouer avec le feu.
Tu peux effectivement "bidouiller" pour suspendre ces raccourcis lorsque ta fenêtre "diaporama" n'est pas la key-window (ça se gère bien avec le NSNotification qui va bien).
Tu peux aussi gérer ces touches autrement : ne pas les mettre en raccourci clavier, mais les capturer en tant qu'événement reçu par ta fenêtre "diaporama" (ce qui n'interfèrera pas avec les autres fenêtres de ton appli).
Bref, tu as plusieurs solutions : à toi de voir laquelle te botte le mieux.
.
Elle consiste à rajouter un modificateur dans une fonction qu'on appelle à l'ouverture et à la fermeture du panel
Une nouvelle question
Ici je rétablis le modifierFlag par NSFunctionKeyMask, qui est validée par les flèches.
Le plus simple aurait été de mettre une constante "inactive" du modifierFlag mais NSEvent.h ne définit pas cette constante ( la valeur 0 marche cependant )
Modifier Flags
The following constants (except for NSDeviceIndependentModifierFlagsMask) represent device-independent bits found in event modifier flags:
enum {
NSAlphaShiftKeyMask = 1 << 16,
NSShiftKeyMask = 1 << 17,
NSControlKeyMask = 1 << 18,
NSAlternateKeyMask = 1 << 19,
NSCommandKeyMask = 1 << 20,
NSNumericPadKeyMask = 1 << 21,
NSHelpKeyMask = 1 << 22,
NSFunctionKeyMask = 1 << 23,
NSDeviceIndependentModifierFlagsMask = 0xffff0000U
};
Dans ton cas, il faut retenir 2 choses essentiels (qu'un "vieux" du C comprendra immédiatement) :
et
Cela signifie que modifierFlag est un champ de bits (chaque bit correspond à une fonction précise, indépendamment des autres). L'opérateur << (décalage) nous précise même quel bit est affecter à quelle fonction.
On peut donc déduire tout logiquement que tous les bits à 0 (donc la valeur 0 pour modifierFlag) signifie "aucune des valeurs".
Ceci est par ailleurs confirmé par la description de la méthode modifierFlags plus haut dans la doc :
Les mots "individual flag settings" ou "C bitwise AND operator" sont sans ambiguà¯té.
.
Le C je pense connaà®tre un peu après avoir écrit ce bouquin ...
http://web.mac.com/philippe.robinet/iWeb/Le Langage C/Le livre.html
(un peu seulement, ce n'est pas ma formation)
Quant à être vieux, cela me fait de la peine ...
C'est pour cela que j'ai essayé 0.
"The lower 16 bits of the modifier flags are reserved for device-dependent bits".
Si on traduit, cela signifie que les bits de 1<<0 à 1<<15 sont utilisés par Apple à des fins d'adaptations matérielles.
On peut imaginer que le modifierFlag devrait être quelque chose comme standardFlag | userFlag , où
Maintenant, peut-on en être sur ?
(A l'essai c'est bien "ou")
Une erreur classique : le langage courant dit "et" là où la logique dit "ou" ...
Hum, non ils ne se sont pas trompés.
Dans mon message, je cite la méthode modifierFlags qui renvoie un int de flags.
C'est donc bien le AND qu'il faut utiliser pour "masquer" (forcer à 0) les bits qu'on ne teste pas, afin de ne laisser "visible" que le bit à tester.
D'autre part, le OR est utilisé pour mettre à 1 un bit dans le int (chaque bit à 1 dans le masque force à 1 le bit correspondant du résultat).
Par contre, on utilise AND pour forcer à 0 le bit (chaque bit à 0 dans le masque force à 0 le bit correspondant du résultat).
.
Au temps pour moi.
Je ne crois pas : quand on met
[menuItem setKeyEquivalentModifierMask:NSAlternateKeyMask | NSCommandKeyMask | NSControlKeyMask];
cela donne la première image les trois modificateurs (Image 1.png)
sinon pour
[menuItem setKeyEquivalentModifierMask:NSAlternateKeyMask & NSCommandKeyMask & NSControlKeyMask];
on obtient aucun modificateur (Image 2.jpg)
Je viens de comprendre ce que tu veux dire. C'est lorsque l'on veut tester si un modificateur est présent (méthode modifierFlag) on utilise le &
[Fichier joint supprimé par l'administrateur]
Tout à fait... Philippe !
.