2008-05-08-01-【Scrooge】クラス 設計 - 3 - project-enigma

2008-05-08-01-【Scrooge】クラス 設計 - 3

>> Site top >> weblog >> 月別アーカイブ >> 2008年05月のlog >> 2008-05-08-01-【Scrooge】クラス 設計 - 3

最終更新日付:2014/01/02 00:00:00


【Scrooge】クラス 設計 - 3

2008 年 05 月 08 日

前回、リソースのロックという Palm OS の制約に関連して、KeyList が保有する名称はこのクラス自身に描画させる必要がある、ということを書いた。その後リストコントロールの内容描画に関するインタフェイスにあわせた結果、できあがったのは以下のようなKeyList クラスだ。

class KeyList {
public:
    virtual UInt16 GetSize( ) const = 0;
    virtual UInt32 GetRecID( UInt16 idx ) const = 0;
    virtual void DrawListItem( Int16 itemNum,
                               const RectangleType* pBounds ) = 0;
};

リストの内容コールバック関数で描画する場合、インデックスと描画領域の矩形が渡されるため、それをそのまま KeyList 派生クラスオブジェクト DrawListItem メソッドに渡すわけだ。これで一件落着...と、思ったのだが。

実装してみると、当然ながらポップアップトリガーに CtlSetLabel せねばならない。この API によって設定される文字列のポインタはユーザーコード側で有効性を保証しなければならないから、レコード上のアドレスを渡した後に平気な顔でアンロックするわけにもいかない...というわけで、一応名称を取得するメソッドを別途用意することにした。もちろん乱用注意で。目的は明確なので、POL の CString を返すようにしてしまおう。

class KeyList {
public:
    virtual UInt16 GetSize( ) const = 0;
    virtual UInt32 GetRecID( UInt16 idx ) const = 0;
    virtual CString GetName( UInt16 idx ) const = 0;
    virtual void DrawListItem( Int16 itemNum,
                               const RectangleType* pBounds ) = 0;
};

こういう現実的な理由だけでもインタフェイスというのは乱雑になっていくものだ...続きは明日以降。

 

コメント

このページにコメントする

 

このページのタグ

Page tag : Palm

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.