NSSearchField
GG
Membre
Bonjour à tous,
dans une application, j'ai une NSSearchField, mais j'aimerai savoir s'il existe un moyen de savoir si la stringValue a été modifiée en dehors de la fonction qui effectue la IBAction ?
dans une application, j'ai une NSSearchField, mais j'aimerai savoir s'il existe un moyen de savoir si la stringValue a été modifiée en dehors de la fonction qui effectue la IBAction ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
- Utiliser le "delegate"
- Sous-classer NSSearchField
Existe t'il une méthode qui retourne juste un booléen ?
Car textDidChange retourne void .
Attends, je doute que l'utilisation du delegate ou de la notification te soient utiles si c'est pour interrompre le "chargement" d'un NSTableView.
Et ceci pour 2 raisons :
- un NSTableView, ça ne se charge pas.
- l'affichage du contenu d'un NSTableView via son datasource se fait (plus que probablement) dans une boucle qui ne sera pas interrompue par la notification ou par l'appel du delegate.
Précise ce que tu veux faire plus précisément.
.
Grillé par Bru, merci..
En gros la NSSearchField envoie une requête spotlight et le résultat s'affiche dans une nstableview.
Le hic c'est que la requête me renvoie des NSString qui me permettent de créer mes propres objets, et qui servent à l'affichage de la NSTableView.
Le truc c'est que le seul moyen que j'ai trouvé pour éviter des exceptions, est de créer mes objets dans "- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn row:(int)rowIndex"
Mais je les crée dés la première entrée dans cette méthode.
En gros
Autrement je ne sais pas comment faire pour charger au fur et à mesure mon NSMutableArray _tableValues.
Et le soucis est que si la requête retourne un grand nombre de résultat, le temps que cette boucle charge tout en mémoire, les modifications de ma NSSearchField ne sont pas pris en compte tout de suite.
L'idée était d'ajouter un test dans cette boucle qui teste l'état de la NSSearchField et si elle est modifiée, arrêté la boucle.
Sur spotlight tu vois bien que tu peux taper taper et taper dans la recherche ça se charge toujours.
Pour éviter que ton programme bloque, tu détaches un nouveau thread, un sous-programme si tu préfères.
Dans ce thread, tu t'occupes d'effectuer le trie.
Si ta recherche abouti à des fichiers, tu les rajoutes tout simplement dans ta array que tu retourne à chaque fois à ta tableview.
Il faudra juste la vider à chaque fois au début du chargement et arrêter l'ancien thread qui s'occupait de la recherche précédente.
Sinon tu peux faire une vraie recherche continue mais dans ce cas ça devient compliquer car il faudra supprimer les éléments qui ont été ajoutés mais qui ne correspondent plus à la nouvelle recherche, ainsi que supprimer les doublons
Elle ne doit jamais renvoyer un nombre supérieur à la taille de ton "_tableValues"
De plus, tant qu'il n'y a pas de scroll ou autre actions sur la tableView ou un appel à "reloadData", tu peux y toucher sans que l'affichage ne change.
J'ai du mal à voir le problème.
Par contre à quel moment tu effectues le remplissage de la NSMutableArray qui contient l'objet à afficher dans la NSTableView ?
Ou plus exactement et idéalement dans la méthode de ton thread (que tu auras détaché pour séparer le processus de recherche du thread principal) qui trouve les résultats ; thread qui sera lancé lors du textDidChange, et arrêté quand la recherche est terminée, ou qu'un autre textDidChange survienne entre temps, interrompant le thread de recherche en cours pour en lancer un nouveau avec le nouveau critère de recherche.
- créer un thread pour créer ma class :
ET ça fonctionne bien, mais comment l'arrêter lorsque une nouvelle requête arrive ?
Pour le reste, c'est une bonne question, qui a été déjà plus ou moins traitée ici.
Recherche "thread" dans les titres des sujets du forum...
Voici un petit exemple de ce que je pense tu cherches à faire : http://mic3d.free.fr/TbVSearch.zip
Exemple à critiquer bien sur !
Edit - c'est certainement plus malin (cocoa) d'utiliser NSMetadataQuery et ses copains en fait...