[cocoa-java] NSUserDefaults NSMutableArray et Float
8 réponses
une.bevueVOTEZ
bon, je souhaite enregistrer dans les prefs de l'user la largeur des
colonnes d'une NSTableView.
(d'après mon expérience l'autosave ne marche pas quand on change le
nombre de colonnes)
les widths sont en float que je converti en Float et que je met dans une
NSMutableArray (le nombre de colonnes varrie car je permet à l'user de
supprimer) .
quand je récupère mes widths, j'ai un truc très très étrange :
bah, c'est un problème que nous n'auront bientôt plus puisque nous allons tous devoir passer à Obj-C
;-)
une.bevueVOTEZ
Fabien Conus wrote:
bah, c'est un problème que nous n'auront bientôt plus puisque nous allons tous devoir passer à Obj-C
j'ai commencé à regarder Obj-C...
je me suis "fait" le bouquin "Coca par la pratique"...
ça m'aide en ce qui concerne cocoa-java, quand à switcher sur obj-c c'est autre chose deux pré-riquisit pour moi :
- qu'aviendra-t'il d'Apple après passage à Intel ie. vont-ils y laisser des plumes ou augmenter (toward 10 %) la clientelle ? - j'en sais pas assez à propos de core)data mais il m'a semblé (SQL Lite oblige ?) que c'est basé sur une bd standard sql, càd relationnelle, bon moi j'utilise db4objects, conceptuellement supérieur, il me semble...
déjà cocoa-java, à la place de swing-java, m'oblige à ré-écrire le code de mon arbre des appellation s because une NSOutlineView ne se manipule pa du tout comme une JXTreeTable... -- une bévue
bah, c'est un problème que nous n'auront bientôt plus puisque nous
allons tous devoir passer à Obj-C
j'ai commencé à regarder Obj-C...
je me suis "fait" le bouquin "Coca par la pratique"...
ça m'aide en ce qui concerne cocoa-java, quand à switcher sur obj-c
c'est autre chose deux pré-riquisit pour moi :
- qu'aviendra-t'il d'Apple après passage à Intel ie. vont-ils y laisser
des plumes ou augmenter (toward 10 %) la clientelle ?
- j'en sais pas assez à propos de core)data mais il m'a semblé (SQL Lite
oblige ?) que c'est basé sur une bd standard sql, càd relationnelle, bon
moi j'utilise db4objects, conceptuellement supérieur, il me semble...
déjà cocoa-java, à la place de swing-java, m'oblige à ré-écrire le code
de mon arbre des appellation s because une NSOutlineView ne se manipule
pa du tout comme une JXTreeTable...
--
une bévue
bah, c'est un problème que nous n'auront bientôt plus puisque nous allons tous devoir passer à Obj-C
j'ai commencé à regarder Obj-C...
je me suis "fait" le bouquin "Coca par la pratique"...
ça m'aide en ce qui concerne cocoa-java, quand à switcher sur obj-c c'est autre chose deux pré-riquisit pour moi :
- qu'aviendra-t'il d'Apple après passage à Intel ie. vont-ils y laisser des plumes ou augmenter (toward 10 %) la clientelle ? - j'en sais pas assez à propos de core)data mais il m'a semblé (SQL Lite oblige ?) que c'est basé sur une bd standard sql, càd relationnelle, bon moi j'utilise db4objects, conceptuellement supérieur, il me semble...
déjà cocoa-java, à la place de swing-java, m'oblige à ré-écrire le code de mon arbre des appellation s because une NSOutlineView ne se manipule pa du tout comme une JXTreeTable... -- une bévue
lucsky
Une bévue wrote:
- j'en sais pas assez à propos de core)data mais il m'a semblé (SQL Lite oblige ?) que c'est basé sur une bd standard sql, càd relationnelle, bon moi j'utilise db4objects, conceptuellement supérieur, il me semble...
Ca n'a *strictement* rien à voir.
CoreData supporte plusieurs format de stockage: XML, binaire, SQLite ou en RAM. Le fait que la persistence se fasse avec tel ou tel type de stockage n'est qu'un **détail d'implémentation**.
Alors si SQLite te pose un problème quelconque, tu peux toujours passer en stockage binaire, par exemple, et ton "conceptuellement supérieur" n'aura alors vraiment plus aucun fondement (déjà qu'à la base...) :>
-- Luc Heinrich -
Une bévue <une.bevueVOTEZ@NONfree.fr> wrote:
- j'en sais pas assez à propos de core)data mais il m'a semblé (SQL Lite
oblige ?) que c'est basé sur une bd standard sql, càd relationnelle, bon
moi j'utilise db4objects, conceptuellement supérieur, il me semble...
Ca n'a *strictement* rien à voir.
CoreData supporte plusieurs format de stockage: XML, binaire, SQLite ou
en RAM. Le fait que la persistence se fasse avec tel ou tel type de
stockage n'est qu'un **détail d'implémentation**.
Alors si SQLite te pose un problème quelconque, tu peux toujours passer
en stockage binaire, par exemple, et ton "conceptuellement supérieur"
n'aura alors vraiment plus aucun fondement (déjà qu'à la base...) :>
- j'en sais pas assez à propos de core)data mais il m'a semblé (SQL Lite oblige ?) que c'est basé sur une bd standard sql, càd relationnelle, bon moi j'utilise db4objects, conceptuellement supérieur, il me semble...
Ca n'a *strictement* rien à voir.
CoreData supporte plusieurs format de stockage: XML, binaire, SQLite ou en RAM. Le fait que la persistence se fasse avec tel ou tel type de stockage n'est qu'un **détail d'implémentation**.
Alors si SQLite te pose un problème quelconque, tu peux toujours passer en stockage binaire, par exemple, et ton "conceptuellement supérieur" n'aura alors vraiment plus aucun fondement (déjà qu'à la base...) :>
-- Luc Heinrich -
une.bevueVOTEZ
Luc Heinrich wrote:
Ca n'a *strictement* rien à voir.
je n'en suis pas persuadé, pour l'instant. -- une bévue
Luc Heinrich <lucsky@mac.com> wrote:
Ca n'a *strictement* rien à voir.
je n'en suis pas persuadé, pour l'instant.
--
une bévue