Google Code Prettify

2008年2月23日

Leopard 上の NSTreeController は挙動不審?

Leopard において NSTreeController の挙動が素直でない現象に出くわした。 Tiger で同じバイナリは素直な動作をするので、バグなのか、仕様の変更なのか。。。さっぱいり分からない。

途中まで Tiger 上で開発して放り投げておいたものを、Leopard 上で再開した途端、地雷原に突っ込みまくっている。。。

でだ、問題は NSTreeController は、childrenKeyPath の先のモデルを、Array として扱うのか、Set として扱うのか?

簡単なサンプルを作ってみた。

MoiView.zip

  1. モデルに Core Data を使わずにNSMutableDictionary を使い、newObject/newChildObject で単純な初期を行う。このとき children には NSMutableArray のインスタンスを割り当てている。
  2. NSTreeController と NSOutlineView を一般的な binding をしてある。
  3. 五つのボタンのそれぞれのアクションに、NSTreeController のadd:/addChild:/addInsert:/addInsertChild:/remove: を接続して、同時に、それぞれのボタンの enabled に canXXX をbindingする。
  4. 別のボタンに、NSTreeController に rearrangedObjects を実行するアクションを接続する。
  5. こちの挙動の対処の有無のチェックボックスをつける。

トップレベルに追加(add:)や挿入(insert:)を沢山した後、rearrangedObjects を呼び出しても、項目の順序は変化しない。これは、Tiger でも Leopard でも同じ。

トップレベルよりしたの階層で、追加(add:/addChild:)や、挿入(insert:/insertChild:)を沢山した後、rearrangedObjects を呼び出すと、項目の順序は変化しないはずなのだが、僕のLeopard の環境では変化する。

再現性もある。モデル上では insert:はadd:として、insertChild:はaddChild:として振る舞う。。。

でだ、問題は insertObject:atArrangedObjectIndexPath:でも同じように、モデル上では indexpathで指定された階層の最後尾に追加される。。。

ビューとモデルでは違うのは分かるが、Core Data を使わずに適当なクラスを使っているのだから、childrenKeyPath の先を Array として扱って、挿入位置もモデルに反映してほしいのだが、、、。

困った。 仕様なのか、バグなのか、環境なのか、分からん。 最初の話だが、childrenKeyPath の先は、Core Data のエンティティを使う場合は Set であり、クラスを使う場合は出来る限りArray であると思うのだが、違ったのか? まぁ、抜け道はあるから良いのだけども。 そのうち、なんか出てくるかぁ。

追記 (2008/06/21)

MacOSX 10.5.3 になって直ぐには確認していないので、どの時点で改良されたか分からないが、近々の最新状態で確認したところ、insert系のビューとモデルの操作の奇妙な差異が改善された。

どうもバグだったらしい。

要求条件が 「MacOSX 10.5.3 以上」とか見るが、どうもこれらの原因なのかなぁ。。。

よきことかなぁ。

0 件のコメント:

久しぶりの投稿

かなり期間が空いてしまったが、ブログを再開してみようと思う。 2013年3月が直前の投稿だったが、頻繁に更新していた時期が 2011年11月までなので、8年間ぶりとなる。 8年間なにをしていたのかと言えば、2回転職して未だにIT技術者の職を得ている。 その...