過去の桐井戸端ＢＢＳ　（桐ver.９）

26343	改行キーを押してもカーソルがある項目が移動しないようにしたい	ＡＢＺ研究所	2004/05/17-12:53
No.26251（更新モードの維持）でお世話になりました。 この件の対応策を検討していますが，また困っています。 変な質問かもしれませんが，次のような動作が欲しいのです。 ・改行キーを押してもカーソルがある項目が移動しないようにしたい。 　改行方向の設定はありますが，「移動しない」設定がなく，悩んでいます。 　カーソルの移動は矢印キーのみで行いたいのです。 よろしくお願いいたします。
26347	Re:改行しても動かないで！	佐田　守弘	2004/05/18-00:13
記事番号26343へのコメント ＡＢＺ研究所さん イベントでフォーカス移動を制御する方法で何とかできるかも知れません。 それぞれのテキストオブジェクトに対して、ソース値更新イベントを使い、 ソース値が更新されたら(つまり値が入力されたら)、現在のオブジェクトに フォーカスを移動する様にすれば、Enterキーを押しても、カーソルは移動しなくできると思います。 なおテキストオブジェクト全体に対して、ファミリを設定すれば、 そのファミリに対するソース値更新イベントを１つ作るだけで、全体の制御ができると思います。 しかし、本当にこの様な形が操作性の上で良いのでしょうか。 そのあたりがどうも解りにくいのですが。 佐田守弘(KS-00119)
26348	Re:改行しても動かないで！	悲しげ	2004/05/18-00:37
記事番号26347へのコメント どもっ、佐田さん v9ではファミリにもソース値更新が使えるようになっていたんですね。 私は今日初めて知りました。(^^;) >ソース値更新イベントを使い、ソース値が更新されたら(つまり値が入力 >されたら)、現在のオブジェクトにフォーカスを移動する様にすれば、 ソース値更新は、[Enter]キーを押した時以外でも発生しますから（例えば[Tab]とか）、 押されたキーが[Enter]であるかどうかを調べる必要もありえます。 と云う訳で、極めて直接的なやり方ですが(^^;)、 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 手続き定義開始　フォーム::キーダウン(長整数　&仮想キーコード，・・・・ 　条件(&仮想キーコード=13) &処理中止=1 手続き定義終了 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 のようにしても、期待する挙動にはなると思います。 ただ、ここまでしちゃっていいのかどうかも含めて、佐田さんの次の疑問に同意です。 >しかし、本当にこの様な形が操作性の上で良いのでしょうか。 >そのあたりがどうも解りにくいのですが。
26351	ファミリでのソース値更新	佐田　守弘	2004/05/18-00:56
記事番号26348へのコメント 悲しげさん 　>v9ではファミリにもソース値更新が使えるようになっていたんですね。 　>私は今日初めて知りました。(^^;) 実は、私もコメントを書きながら今日初めて確認しました。 確かだめだったかもしれないと思って、調べてみたら、ファミリのイベントにソース値更新が入っていました。 でも実際には使った事はありません。 佐田守弘(KS-00119)
26354	Re:改行しても動かないで！	ONnoji	2004/05/18-11:01
記事番号26343へのコメント ＡＢＺ研究所さん、こんにちは。 それぞれのテキストボックスをファミリに登録して、 ファミリの(以下の例ではファミリ_1と仮定する)、 ［編集開始］イベントと［ソース値更新］イベントを利用すれば可能だと思います。 もちろん、［キーダウン］イベントも必要です。 ファミリの使い方はヘルプをご参照ください。 なお、掲示板では半角カナが全角カナに変換されていますのでご注意ください。 *------------------------------------------------* 名札 メイン 　変数宣言　局所，文字列｛ &mEditObjectName ｝ 　変数宣言　局所，長整数｛ &mVKRETURN, &mEditMode ｝ 　 　&mVKRETURN = 13 　 　* 更新モード取得( <変数名> ) 　*代入値 更新モード 　* 0　　表示モード 　* 2　　訂正モード 　* 4　　行挿入モード 　* 6　　行追加モード 　* 8　　項目訂正モード（レコード更新を伴わない訂正も含む） 　* 33　　グループ検索モード 　* 34　　グループ値訂正モード 　* 36　　グループ追加モード 　 ＊ 　 手続き定義開始　フォーム::キーダウン( …省略… ) 　 ┌if ( &仮想キーコード = &mVKRETURN ) │ │　メソッド呼び出し @フォーム.更新モード取得( &mEditMode ) │ │┌if ( &mEditMode = 0 ) ││　&処理中止 = 1 │└end │ └end 　 手続き定義終了 手続き定義開始　ファミリ_1::編集開始() 　&mEditObjectName = &this 手続き定義終了 手続き定義開始　ファミリ_1::ソース値更新() 　変数宣言　自動，長整数｛ &return ｝ 　 　メソッド呼び出し @フォーム.更新モード取得( &mEditMode ) 　 ┌if ( &mEditMode = 2 .or &mEditMode = 8 ) │ │　メソッド呼び出し 戻り値 = &return，&mEditObjectName.フォーカス設定( ) │ │┌if ( &return = 1 ) ││　メソッド呼び出し　戻り値 = &return，@フォーム.更新モード設定( 0 ) │└end │ └end 手続き定義終了 *------------------------------------------------* ＜追伸＞ まことに僭越ながら、私の個人的な感想を述べさせていただきます。m(__)m お尋ねのようなユーザインターフェースデザインが好ましいのか否かに関しては、 これからお作りになるアプリケーションの利用者の意見を尊重されたらいかがでしょうか？ 「こんなの嫌いよ！」と言われるのか、 「今までと同じでとても使い易いわ」と言われるの判りませんが、 いずれにしても、利用者を中心にデザインを決められたらいかがでしょうか。 出来あがったものを使うのは利用者ですから、利用者の意見を尊重してください。 ただし、製作側と利用者の意見が食い違う場合には、 十分話し合ってデザインを決めた方がいいですね。 必要があれば、利用者を説得する勇気も必要になります。 逆に利用者に説得されちゃったりすることもありますけれどね(^^ゞ
26356	解決しそうです	ＡＢＺ研究所	2004/05/18-16:03
記事番号26354へのコメント ONnoji様 アドバイスありがとうございます。 まずは，「ファミリ」のヘルプ一読して・・便利な機能があるのだなあと感心し， 続けてレスいただいたとおりのコードをアレンジしながら，作成中のコードに移植したところ， カーソルの動きは希望通りの動作をしました。 ありがとうございます。 引き続き，アドバイスのコードの中身を解読させていただき，他の制御との関係を確認したいと思います。 さて，この件の目的ですが，ご指摘の通り操作はアプリケーションの作成しやすさではなく， 使用者にとっての使いやすさが重要と私も考えています。例えばコマンドボタンを配置する場合においても， 機能的にはどこにあってもいいですが，大きさや配置位置，視線の動きなどが違えば 操作性もかなり違うと思います。 まさに「できる」と「使える」は違うって感じです。 そのため，現在色々なデモを作成し，使用者と確認しながら作業を進めています。 そのなかで，「表示モード」と「更新モード」の切り替えについて，通常の「桐」での仕様より 操作性を使用目的に特化して向上させるため，No.26251（更新モードの維持）などで，皆様にアドバイスを頂きました。 ちなみに，今作成しているアプリケーションを使用する業務は，数字の入力が大半を占めるため 極力テンキーから手を離さないような操作を基本としています。（例えばＹＥＳ／ＮＯも１／０などとする）そのため， 「表示モード」と「更新モード」の切り替えについても次のような操作を考え，デモにより操作性を確認することにしました。 　・カーソルの移動は「表示モード」でカーソル（矢印）キーで移動させる。 　・「ＥＮＴＥＲ」で「カーソル位置」が「更新モード」になる。 　　＊このとき，制御しないと次項目が入力状態となってしまいました。 　・再度入力確定（「ＥＮＴＥＲ」）で「表示モード」に復帰する。 このような操作がいいか悪いかを判断するために，とりあえず実現したかったのが理由です。 たぶん，これからも「行挿入」や「行削除」などの操作でも「ＩＮＳ」や「ＤＥＬ」キーで行う など色々な問題にブチあたると思います。 妙な質問ばかりかもしれませんが，よろしくお願いいたします。
26357	Re:解決しそうです	ONnoji	2004/05/18-16:39
記事番号26356へのコメント ＡＢＺ研究所さん、こんにちは。 桐ver.9以降から［編集開始］が追加されました。 さらに［編集開始］と［ソース値更新］イベントはファミリで使えるようになったので、 便利になりましたね。 ［編集開始］［入力前］［入力後］［ソース値更新］というイベントは、 桐が表示モードとその他のモードを持っているために、 用意されたイベントのようです。 したがって、アクセスにはこんなものはありませんね。 ［編集開始］［入力前］［入力後］はテキストボックス（またはグループ項目）に キャレットが現れた時に発生すると覚えると良いですよ。 キャレットが表れている間はをエディタに入っていると言います。 この状態では直接項目を編集しているのではなく、 メモリにコピーされた文字列を編集しているというイメージです。 そのため、エディタは一種のバッファと思うといいだろうと思います。 入力を確定すると、バッファから項目に値が複写されるわけです。 一方［ソース値更新］というイベントは、 エディタの外へ出たとき、つまりバッファがクリアされた時に発生します。 なお、［ソース値更新］はＥＳＣキーを押したときには発生しないのでご注意ください。 ［ソース値更新］では、他のオブジェクトへフォーカスを移せます。 これは、エディタ（バッファ）の中に閉じ込められていないためだと思います。 以上は正確な用語を並べたわけではありませんけれど、 大体のイメージをご理解いただけると思います。 アクセスのイベントとはこの辺りが大きく違うと思います。 現在はプロトタイピングという段階ですね。 利用者と十分打ち合わせていいアプリケーションを作ってください。 >ちなみに，今作成しているアプリケーションを使用する業務は，数字の入力が大半を占めるため >極力テンキーから手を離さないような操作を基本としています。（例えばＹＥＳ／ＮＯも１／０ >などとする）そのため，「表示モード」と「更新モード」の切り替えについても次のような操作 >を考え，デモにより操作性を確認することにしました。 なるほど！、数字ばかり打ちこむ入力は確かにありますね。 早撃ちのオペレータさんは要求がきつい事が多いですね。 とんでもない要求もあるでしょうけれど、頑張ってください。 失礼しました。(@^^)/~~~

戻る