大幅修正
いかに実験バージョンとはいえ、データのモデル構造だけはしっかりと作っておきたいのでやり直しをした。
ver2ではデータは完全なツリー構造になり、JTreeも大活躍する。
そのため、実装モデルはDefaultMutableTreeNodeを継承した形で作っていた。
しかし、これだと、やはりクラスの独立性が確保できないので作り直しにした。
DefaultMutableTreeNodeのUserObjectにデータのノードを設定する方法を採用。
これだと、ツリー構造を２重に持たなければならず、追加や削除などの際に同期を取るのが面倒な印象があったが、そんなことは同一のルーチンを使えば解決する。
それとデータノードに様々な機能を持たせていたが、これも廃止。
基本的なもの以外の機能はユーティリティークラスで行うことにした。
こうする方が、インターフェースの実装時も楽だし、そういうのっていろいろな場面で使うから、こっちの方が便利。
しかも、同じ処理をあちこちで定義しなくて済む。
例をだすと、ノードAをノードBの子ノードとして追加していいかの判定。
こういうのはユーティリティークラスで実装。
残るのはプロパティへのアクセスメソッドくらいか。
データ構造の設計は一番大事な部分だから、しかっりと行わないと、後でどうしようもなくなるからね。
ver2ではデータは完全なツリー構造になり、JTreeも大活躍する。
そのため、実装モデルはDefaultMutableTreeNodeを継承した形で作っていた。
しかし、これだと、やはりクラスの独立性が確保できないので作り直しにした。
DefaultMutableTreeNodeのUserObjectにデータのノードを設定する方法を採用。
これだと、ツリー構造を２重に持たなければならず、追加や削除などの際に同期を取るのが面倒な印象があったが、そんなことは同一のルーチンを使えば解決する。
それとデータノードに様々な機能を持たせていたが、これも廃止。
基本的なもの以外の機能はユーティリティークラスで行うことにした。
こうする方が、インターフェースの実装時も楽だし、そういうのっていろいろな場面で使うから、こっちの方が便利。
しかも、同じ処理をあちこちで定義しなくて済む。
例をだすと、ノードAをノードBの子ノードとして追加していいかの判定。
こういうのはユーティリティークラスで実装。
残るのはプロパティへのアクセスメソッドくらいか。
データ構造の設計は一番大事な部分だから、しかっりと行わないと、後でどうしようもなくなるからね。
Comments
↓PAR3が使われている例
ttp://www.msnusers.com/GranTurismoTheSagaContinues/gt4arcodes.msnw
理由はこのPCEでPAR3のドングルUSBのデータを
PCEに移植すれば、ドングル壊れても使えるのではないか…と思って。
まぁ僕にはどうすることもできず、
ugnagさんがメールして、問い合わせて見ないと…
まぁムリですがね。
前にも書いてありましたが…
ちなみに、3.5が出ていました。
対応機種にPSX…
PSXって？
PSXのゲームに対応したんでしょうか?
でも、PS2で起動した場合、PSXのソフトに対して
使用できないという落ちじゃ…？
しかも値段が「希望小売価格：\10,290（税込）」
てか、PC上でコードを編集できるようになぜしないんだ?ｗ
PS2で起動したときにPSXのゲームが起動できる場合こっちも対応する必要があるのではないかと…
（まぁugnagさんの自由ですがねw）
どなたかPS2で起動したときにPSXのゲームが起動できるかどうか詳細希望です。m(__)m
PCEに移植すれば、ドングル壊れても使えるのではないか
PAR3はUSBのVID、PIDをチェックしています。
こちらのソフトでどうにかなる問題ではありません。
やるとするなら、USBのVID、PIDを書き換える事が考えられますが、特殊なハードが必要らしいです。
（１万円程度）
そんなことをするくらいなら、PAR3.5を買った方がいいでしょう。
VID、PIDのチェックが外されているらしいです。
>PSX
単純に、PSXでPS2のゲームをする場合の話です。
>PC上でコードを編集できるようになぜしないんだ
メーカーはDML3を発売しています。
以前からそうですが、自分の思いこみで、勝手な解釈をする癖があるようですね。
気をつけて下さい。
気をつけて下さい。
はい。(´・ω・`)