今後に期待すること

ここでは、サンプル試行や自作を通じて感じたことを、随時追加するつもりです。

テキストボックスに Inputable 属性が欲しい → 要望を取り下げます。2014/07/10
複数キーでソートしたい2014/06/04
ボタンをボタンらしくして欲しい → Beta3 で解消されたようです。2014/05/26
ブラウザフレーム・PDFフレームが欲しい2014/03/29
メモリ管理（解放）の改善2014/03/25
こんな関数が欲しい　[ Table(textwork) 関数 ]2014/03/25
ラベルにスライダー表示属性が欲しい → Beta3 で解消されたようです。2014/03/25
ギャラリーの縦横数指定属性が欲しい2014/03/25

テキストボックスに Inputable 属性が欲しい → 要望を取り下げます。

長文表示かつ入力不可にしたいとき、ラベルの Overflow 属性で scrollbar を指定できるようになったので、テキストボックスを使用する必要がなくなったように思います。ですので、この要望は取り下げます。 (2014/7/21)

長文表示かつ入力不可にしたいとき、テキストボックスを入力不可にして、スライダーだけ機能させたいと思いました。
これを実現するために、 Inputable 属性が欲しいと思った次第です。
この属性があれば、 Inputable=false にして、スライダー機能を生かすことが可能になりそうです。
現状では、 Disable=true にすると、入力もスライダーも不可になってしまいます。

以前「ラベルにスライダー表示属性が欲しい」でも似たようなことを指摘しましたが、これは、同じ問題への別提案です。

ちなみに、どうしても長文表示かつ入力不可にしたい場合、
テキストボックスを配置して、スライダーに重ならないギリギリまで透明のラベルを
文章にかぶせることにより、疑似的に長文表示かつ入力不可を実現できそうな気がしています。
ただ、この方法の場合、スライダーの上ならいいのですが、文章の上でマウスのホイールを動かしても文章が動かない、という欠点がありそうです。

複数キーでソートしたい

コレクションしたデータをソートして使用することはできるのですが、残念ながらソートキーが１項目しか指定できません。
ギャラリーに表示するとき、２項目でソート可能であれば、というケースがありました。
そんなに贅沢は言わないので、せめて２～３項目は指定できるようにして欲しい、と思いました。

ボタンをボタンらしくして欲しい → Beta3 で解消されたようです。

ボタンとラベルをスクリーンに貼り付けると、外見上の見分けがつきません。
フラットデザインなので仕方がない気もします。
ただ、ボタンの方は、マウスオーバーしたときに色が変わるとか、あるいは、縁取りをボタンらしくしておく等の工夫が欲しいなあ、という気がしています。

ブラウザフレーム・PDFフレームが欲しい

英語学習用のウェブキャスト（MPEGデータ）を再生するアプリを作っていて思ったのですが、英語のスクリプトが、ウェブページや PDF で提供されている場合、それを表示するフレーム部品が欲しい、と思いました。
結局、アプリの外でブラウザやPDF再生用リーダー（AdobeReader や、リーダーアプリなど）を起動することになり、アプリの一体感を損ねてしまうなあ、という気がしています。ただ、既に提供されているRSSリーダーアプリには、ブラウザ表示をアプリ内に取り込んでいるものもありましたので、案外、正式版では可能になるかも、と思っています。

メモリ管理（解放）の改善

「サンプルで気付いたポイント」の「注意事項」にも書きましたが、メモリ解放の機能が弱い、と感じています。
作業にふさわしいメモリ使用量を確保し、アプリを終了したら、不要なメモリを解放するように改善して欲しいと思います。

こんな関数が欲しい　[ Table(textwork) 関数 ]

こんな使い方ができる関数が欲しい、と感じました。

Filter(Table(textwork),id=3))

要するに、テーブル名を直接指定する代わりに、テーブル名を保管している"textwork"変数を Table 関数に指定することで、テーブルとして認識させたいのです。

なぜそう思ったのかというと、テーブル名を直接記述して、If 関数で分岐させる処理が結構多くなるからです。サンプルでも自作でも、それは同様でした。

もしこの Table 関数があれば、

使用する複数のテーブル名を、一意の id 項目等と一緒にエクセル表に入力し、テーブルに変換する。
作成したテーブルを、データソースとして読み込む。
一意の id でテーブル名を取得してワーク項目に保管する。
以降、テーブルを使用したいときは、ワーク項目と Table 関数を使用して、項目参照やFilter処理・First処理等を行う。

ということが可能だと思うのです。

保守性を考えても、テーブル名の直接記述を回避する方法が必要なのでは、と考えた結果です。
ただ、このアプリの発想の原点に立ち返ると、保守性とかコーディング効率の優先順位は、案外低いのかもしれません。
そもそもコーディングレスを謳っているだけに、いささか的外れな要望なのかもしれません。

ラベルにスライダー表示属性が欲しい → Beta3 で解消されたようです。

長文表示かつ入力不可にしたいときの表示方法に困っていましたが、 Overflow 属性で scrollbar を指定できるようになったので、この問題は解消されました。

テキストを表示するときには、ラベルを貼り付けてデータとリンクさせますが、このラベルにスライダーが出てこないので、やや長文の場合、表示領域自体を大きくしなければなりません。
そこで、ラベルにスライダー表示属性が欲しいです。そうすれば、長文のギャラリーを作成することも可能になると思います。
もしかしたら、その属性を私が見逃しているだけかもしれません。

ギャラリーの縦横数指定属性が欲しい

自作で「ファッションショップの購入シミュレーションアプリ」を作っているとき、洋服イメージのインデックスを4列×2段に作りたい、と思ったのですが、それがかなわなかったので、4列×1段のギャラリーを二つ並べました。
もし m × n のギャラリーが可能ならば、処理の記述がより少なくなったなあ、という感想があります。
スライダー機能との兼ね合いを考えると、結構面倒くさい属性なのかもしれませんが、あればうれしい属性だと思います。