Charger des menu déroulants popup
muqaddar
Administrateur
Salut,
Je voulais savoir pour quelle technique vous optiez dans vos programmes pour charger des menus popup avec disons 200 lignes.
Simple tableau ? Fichier texte (plus facile à mettre à jour), si oui, sous quelle forme et format ?
merci
Je voulais savoir pour quelle technique vous optiez dans vos programmes pour charger des menus popup avec disons 200 lignes.
Simple tableau ? Fichier texte (plus facile à mettre à jour), si oui, sous quelle forme et format ?
merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
dans un de mes projets, il s'agit d'une petite liste gérée par les préférences, et le NSPopupButton est rempli avec [NSPopupButton addItemsWithTitles: (NSArray*) titles].
dans un autre projet, je le remplis avec le contenu (filtré) d'un répertoire, en utilisant [NSPopupButton addItemsWithTitle: (NSString*) title] si l'item me convient...
maintenant, si tu as 200 lignes, un NSTableView ne serait-il pas plus adapté pour afficher le contenu ?
Mais je me suis mal exprimé, en fait, je vais gérer la liste ds un tableview ds les prefs et là j'activerai ou pas des lignes de cette liste. Le résultat des lignes activées arrivera dans le popup ensuite.
Mais supposons que je veuille vraiment importer ds un popup ou un tableView une liste d'un fichier texte, quel doit être le format de ce dernier pour gérer accents, espaces...etc ? Et qu'on ait un élément par ligne...
cet nsarray peut ensuite être utilisé dans le datasource de la nstableview ou pour remplir le nspopupbutton:
Merci cbrandt.
Sinon, le fichier texte doit avoir une extension ? txt ? autre ?
concernant un de tes posts précédents concernant les accents, si par exemple le fichier texte vient d'un pc windows, tu peux essayer quelque chose comme ça:
NSISOLatin1StringEncoding est à adapter en fonction de l'origine du fichier. Si le fichier a été créé avec [NSString writeToFile:atomically:] tu n'en a bien sûr pas besoin et tu utilises la version de mon post précédent; de même si tu crées le fichier dans TextEdit, enregistré avec un codage Unicode...
Merci pour toutes ces précisions !
S'il y a 200 entrées, il vaut mieux mettre un ComboBox, avec une option d'autocomplétion, c'est assez pénible les menus à plus de 20 entrées.... En plus les ComboBox peuvent avoir un datasource, ce qui rend particulièrement facile la synchronisation entre la table et le champ.
En fait, c'est quoi les principales différences entre comboBox et popup, mis à part l'auto-complétion ?
Et on peut mettre une image à côté des entrées d'un combo box ?
De toute façon, même s'il y en a 20, c'est déconseillé... J'aurais même tendance à dire que si on peut en avoir 200, tu dois penser l'interface pour que la personne qui en a 200 puisse être à l'aise. (En plus la navigation dans un menu est particulièrement lente sur les petites configs quand il y a beaucoup d'éléments ...surtout quand il y a des images)
Même s'il est précisé qu'on peut les utiliser à la place d'une liste, l'utilisateur qui fait tout à la souris n'est pas gêné par les combo (et c'est même mieux, car ce n'est pas un menu, mais une tableview qui est affichée, donc la navigation est plus facile), et celui qui préfère le clavier sera gêné par les PopUps...
On ne peut pas mettre d'image dans un combo (normal c'est une classe qui hérite de NSTextField...). À toi de voir si tu préfères le cosmétique ou le fonctionnel... (en attendant de sous classer NSComboBox :P)
La question des accents et autres caractères spéciaux n'est pas une limitation du format, mais plutôt une de l'encodage. Si tu fais un fichier texte, fais le en unicode...
Me voilà moins bête maintenant.
Je vais certainement opter pour la combo. :trinque:
Qd je NSLog le tableau test, il est vide. Le fichier Pays est en Unicode...
Pour ton problème de chargement je ne sais pas, peut-être un mauvais chemin.
Ce que je voulais te signaler, c'est que le dossier Resources n'est pas le bon endroit pour y mettre un ficher suceptible d'être modifié (c'est ton cas si j'ai bien compris) car le prg peut-être démarré d'un CD ou d'un volume/dossier en lecture seule.
Mais ce fichier ne pourra être modifié en fait.
En revanche, j'en ai d'autres qui le seront et je les mettrai dans le dossier User soit ds les documents (un dossier pour mon app), soit ds Application Support.
Du coup, je comprends pas bien l'interêt d'utiliser un fichier texte plutôt qu'un NSArray de string ???
De plus, il y aura des versions localisées de ce fichier.
Justement c'est la question que je me posais.
Puisque tu as un tableau static, des fichiers .strings classiques conviennent parfaitement pour la localisations. Les termes utilisées dans ton fichier texte seront-ils uniques, apparaitront-ils ailleurs dans ton appli ? (localisation en double?)
Bon , je chippote un peu, les fichiers textes ça marche aussi
En fait, je veux écrire la liste de 200 pays dans mon fichier et charger cette liste dans les prefs de l'appli dans un tableView, et là , activer par défaut une vigntaine de pays qu'on retrouvera dans un popup dans l'appli. Ce fichier initial est susceptible d'être modifié (par moi uniquement), et c'est pour faciliter son éventuelle mise à jour que je voulais mettre ces pays dans un fichier texte.
Maintenant, mon soucis est de localiser au moins en anglais cette liste de pays, pour le nib anglais. Et là , je m'interroge, je voulais faire effectivement un autre fichier avec les noms des pays en anglais et le charger qd le nib anglais est chargé. Mais y'a p-e plus simple ou mieux ? Avec un fichier de strings, cela me paraà®t plus galère non ?
Donc une solution est d'avoir pour chaque pays un tableau à deux éléments: un identifiant unique qui ne change pas suivant les localisations, et le nom du pays.
Pour ce qui est du dossier par défaut:
Je dirais même plus : 3 élements avec une clé image du drapeau lié.
L'identifiant pourrait être une courte chaine de caractères ou un nombre ?
Quand au drapeau associé, il pourrait prendre le nom de l'identifiant, il n'y aurait plus qu'à tous les mettre ds le bundle et de les charger ds la tableview avec NSImage.
Il ne me reste donc plus qu'à construire un fichier plist avec les 3 clés et mes enresgistrements.
J'ai bon ?
J'ai un soucis de "logique" avec mon fichier plist.
Dans les prefs, je vais chercher ce fichier qui contient les noms de pays et leurs clés. Je voulais le mettre dans le bundle de l'appli. Or, dans les prefs et ma tableView qui liste ces pays, il y a un champ checkBox pour activer ou pas les pays. Par défaut, une vingtaine sera activée. Seulement, cet "état" doit être enregitré quelque part. La logique voudrait que je l'enregistre dans le même fichier or il est dans le bundle... Sauf si je le mets dans une Library du sytem (du dossier user). Mais dans ce cas, il faut le mettre à l'installation de l'appli et donc de créer un installeur ? Bon, je patauge un peu alors qu'il y a sûrement quelque chose de simple à faire. Enregistrer l'état des preferences dans un autre fichier, lui même bien dans le dossier Application Support du User ? Cela implique de reprendre les clés du fichier plist livré avec le bundle ?
Que de questions !
Et comment faire pour connaà®tre la langue sélectionnée dans le système ? Cette langue choisit les bons nibs automatiquement, mais il faut que je la connaisse pour choisir les bons fichiers ressources et les copier dans Application Support au démarrage de l'appli.
merci.
Une autre solution serait de définir un mot clef dans les fichiers .string, ex:
CLEF_LANGUE="FR";
et
CLEF_LANGUE="US";
et de tester la valeur retournée pour cette clef par localizedString("CLEF_LANGUE")
J'ai plutôt prévu de copier le fichier pays par défaut dans Application Support et d'éditer ce fichier ensuite, avec une BOOL sur les pays activés (checkbox ds les prefs).
J'ai l'impression que je merdouille encore dans ma logique.
Il faudrait que ce fichier ne contienne pas le nom localisé du pays mais que l'iD et mon BOOL comme tu dis Renaud, mais que le nom du pays localisé reste dans le bundle.
Au final, j'ai donc :
- 1 fichier copié ds App Support et éditable avec paysId et BOOL
- 2 fichiers langues ds le bundle avec paysId et paysName OU BIEN sous forme de fichier strings ?
Chaque élément de ta liste est stocké dans un dico, chaque info peut être retrouvée à la clé qui correspond à l'identifier de la colonne. et tu rajoutes une clé ID (qui ne sera pas affichée dans le tableau), ce qui permet de faire la correspondance entre un nom localisé et et l'ID du pays. Quand tu construis ton dico, tu mets pour la clef name la valeur de NSLocalizedStringFromTable([dict objectForKey:@ID],nil,@Countries);