■記事リスト / ▲上のスレッド
| ■446 / 親記事) |
Thin_INF_Framework のご案内
|
□投稿者/ ONnoji -(2024/09/04(Wed) 14:21:25)
| ジェダイの桐さん
添付ファイルをアップしました。
■解凍について
zip形式のファイルを、ＡまたはＢのフォルダに解凍（展開）してください。
Ａ #204 INF_Framework 第3.3版 改訂版(MkII) 基本セット for 桐10ｓ / 桐ｓSL が展開されているフォルダ
または、
Ｂ 任意のフォルダ ※注意参照
（注意）任意のフォルダに解凍（展開）した時には、#204 INF_Framework 第3.3版 改訂版(MkII) 基本セット に含まれている
INF_Framework.cmx
IPS_Framework.cmx
の２つのファイルを同じフォルダにコピーしてください。
※#204 は【多遊】さんのＨＰのダウンロードコーナーの作品番号です。
＜同梱ファイル一覧＞
NO_FLD_EZW.kex ┐
NO_FLD_EZW.tbx ├─ 標準サンプル
NO_FLD_EZW.wfx ┘
NO_FLD_EZW_Plus.kex ┐
NO_FLD_EZW_Plus.tbx ├─ 拡張サンプル
NO_FLD_EZW_Plus.wfx ┘
Thin_INF_Framework_ガイド.txt
ユニットINF_3-3MkII_INFprcStartup_NO_FLD_EZW.txt
ユニットINF_3-3MkII_名札メイン.txt
ｐ．ｓ．
これは、INF_Framework の機能制限版なので、難しい所はどこにもありません。
とりあえず、NO_FLD_EZW.wfx を開いてみてください。
ファイルの説明と注意点は Thin_INF_Framework_ガイド.txt にまとめてありますので必ずお読みください。
ｐ．ｐ．ｓ．
さて、これでジェダイの桐さんに泥沼を泳ぐためのシュノーケルが手に入ったことになります。
なんでも良いですから、ジェダイの桐さんがお使いのフォームに Thin_INF_Framework を組み込んでみてください。
組み込み方で分からないことがあれば、お尋ねください。
組み込みが完了したならばお知らせください。
その際には、ハンドルを使って何をしたいか具体的に教えてください。
テーマは幾つあってもＯＫですが、１つ１つずつテーマを取り上げて、具体的な利用法をご案内したいと思います。
|
|
|
▽[全レス58件(ResNo.54-58 表示)]
| ■501 / ResNo.54) |
Re[3]: Thin_INF_Framework のご案内
|
□投稿者/ ジェダイの桐 -(2024/09/12(Thu) 12:21:12)
| 2024/09/12(Thu) 12:21:54 編集(投稿者)
ONnojiさん
こんにちは！
通しで、sample_入荷トランザクション.kex と sample_発注トランザクション.kex を 落ち着いて読みました。
私が一番やりたかった事は HDLCOMprcMacroSend だったんです。
正に他フォームへの値 送信 ですね。
◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
感想
HDLLNCprcWindowAppear について
開きたい対象が
既に開いている → &openStatus = 0
新規に開いた → &openStatus = 1
シンプルに凄いと思いました。
トレース出力で対象表を 開いた状態 と 閉じた状態 の両方でトレース出力をして
&openStatus の値を実際に確認しました。
表が 開いている 閉じている を調べて 対応を変更しているという意味なんだと思います。
----------------------------------------------------------------------------
HDLLNCprcHdlSeek について
調べたい対象の ウィンドウハンドルを探索する
これも凄く便利です。
&targetFileName に フルパスのファイル名を代入すると
&found
&status
&multi それぞれに状態が入ってくる
本当に良く出来た仕組みだと思いました。
&mode は裏で動かす フラグなのでしょうか？？
それとも &mode も状態のお知らせなのですか？？
----------------------------------------------------------------------------
HDLCOMprcMacroSend について
フォーム間で 値の送信が出来る素晴らしい仕組みです。
何故、フォーム間での 値送信 がやりたかったか思い出しました。
私の シックリくる こない の全てのスタート地点が
■14365 モジュール化はフォームのレベルでも必要
なのです。
相手側で 主 に直接影響を与えるアプローチは良くない の概念がここで生まれたのでした(^^ゞ
あの時は、プログラムを書くこと自体がほぼ初めてでした。
下手に固定概念が着く前に上記の概念を教えて頂いた事が私にとって物凄い幸運でした(^^♪
それで 解決方法 &gAnswer を使ったアプローチサンプルをご提案頂きました。
この時に "ピタゴラスイッチ" を覚えました。
同一の ○○.kex 内であれば 手続きで 値渡し 若しくは 戻り値でピタゴラスイッチが作れます。
複数のフォーム間であった時、 値渡し が出来れば 相手側に直接影響を与えず、
ピタゴラスイッチ によって プログラム発動有無が決めれるのにな・・・
という思いが 値送信 に固執したのです。
明らかに、幅が広がりますよね(^^♪
結果
>>そうです、まさしく「こんにちは。モードレスA」でしょ。ガハハハha
> はい！
> これが一番やってみたかったのです。
> これを具体的に利用する想定は無いのですが、値を 送信 したかったのです。
> 常々思っている事なのですが、↑こういう発想をする人って案外と少ないと思いますよ。
私の送信発想のは ONnojiさん がプログラム作成初期の私に教えてくれて、これが出来たら便利だと感じた事が原点なのでした(^^ゞ
具体的に何かに使う想定が現時点ではありませんが、
HDLCOMprcMacroSend によって ピタゴラスイッチ を送信出来る事が分かったので
凄く有難いです。
ありがとうございますm(__)m
◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
質問
HDLCOMprcMacroSend で 整数 を送信したい場合は
送る側
&sendMacro = "手続き実行 prc整数を受け取る( " + &WQ + "m伝票番号" + &WQ + &comma + &WQ + #文字列( &int ) + &WQ + " )
受け取る側
手続き定義開始 prc整数を受け取る( 文字列 &variableName, 整数 &int )
・
・
・
&setInt = #set( &variableName, &int )
の様に &string を &int へ置き換えれば 対応可能でしょうか？？
◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
ｐ.ｓ.
> つまり、キモは一番核心になる部分を一番最初に解決するということですよ。
> ・・・・・・・・・・・・・・・・・・・・・・・・・・・
> その部分が解決したら、枝葉の部分を付け足してゆけば良いのです。
>
> だから、枝葉の部分から始めては駄目なのでした。
> ・・・・・・・・・・・・・
> これが、最も大切なコツですよ。
アドバイスありがとうございます！
このコツを念頭において、プログラム作成を行っていきます！
> 後は、プログラムが正しく動いているかをテストするために［トレース出力］コマンドを挿入して、
> トレース出力の内容をチェックして作業を進めればＯＫです。
これは必須でやっています。
トレース出力 で確認すると 流れ と その時の変数の値 が良く分かるので
間違えた時 特定がし易くなります。
ｐ.ｐ.ｓ.
> ここで、大事なのは、
> オペレータが［コマンドボタン：cmdＣＳＶ読み込み処理］を実行する意思を持って押したのか？という事です。
> 案外と押すつもりが無かったのに、うっかり押しちゃったということもあるんですよね。
> だから、先回りする僭越な行為は要らないのです。
> 何よりも大事なのは、オペレータが押したボタンが即応答する事なのです。
> ・・・・・・・・・・・・・・・・・・
ONnojiさん のプログラムが凄いなと思う事は
作業者がきっかけを与えるまで、単なる文字列 なんです。
作業者がきっかけを与えた瞬間に、単なる文字列 に 意味が初めて生まれ
しかも、ケースバイケースで 動いて行っている。
上手く表現できないですが、意味を究極まで先送りして 結論を最後の最後で出しているイメージです。
だから、結果の精度 が高いのだろう・・・
と勝手に思っています。
素人が思う事なので、全く見当違いかもしれませんが(T_T)
今回も本当にありがとうございましたm(__)m
|
|
|
| ■502 / ResNo.55) |
Re[4]: Thin_INF_Framework のご案内
|
□投稿者/ ONnoji -(2024/09/12(Thu) 14:39:00)
| 2024/09/12(Thu) 18:54:11 編集(投稿者)
ジェダイの桐さん
■ HDLLNCprcWindowAppear
> HDLLNCprcWindowAppear について
> 開きたい対象が
>
> 既に開いている → &openStatus = 0
> 新規に開いた → &openStatus = 1
>
> シンプルに凄いと思いました。
>
> &openStatus の値を実際に確認しました。
> 表が 開いている 閉じている を調べて 対応を変更しているという意味なんだと思います。
&openStatus は、新規に開いたか否かという情報があった方が良いかなと思ったのですが・・・
案外と使い道がありません。
無いよりはあった方がいい程度ですね。アハハハha
■ HDLLNCprcHdlSeek
> HDLLNCprcHdlSeek について
> 調べたい対象の ウィンドウハンドルを探索する
> これも凄く便利です。
> &targetFileName に フルパスのファイル名を代入すると
> &found
> &status
> &multi それぞれに状態が入ってくる
> 本当に良く出来た仕組みだと思いました。
>
> &mode は裏で動かす フラグなのでしょうか？？
> それとも &mode も状態のお知らせなのですか？？
&mode は、整数：&found のハンドル番号のウィンドウの編集状態です。
この値は、フォームの［更新モード取得］メソッドが返す値に準拠しています。
代入値 更新モード
0 表示モード
2 訂正モード
4 行挿入モード
6 行追加モード
8 項目訂正モード（レコード更新を伴わない訂正も含む）
33 グループ検索モード
34 グループ値訂正モード
36 グループ追加モード
■ HDLCOMprcMacroSend
> HDLCOMprcMacroSend について
> フォーム間で 値の送信が出来る素晴らしい仕組みです。
> 何故、フォーム間での 値送信 がやりたかったか思い出しました。
> 私の シックリくる こない の全てのスタート地点が
> ■14365 モジュール化はフォームのレベルでも必要
> なのです。
HDLCOMprcMacroSend は、&hdl で指定したフォームに桐で実行できるコマンドを送信する機能です。
・・・・・・・・・・・・・・・・・・
従って、変数を代入する静的なものではなく、コマンドまたはメソッドを実行する動的なものです。
・・・・・・・・・・・・・・・・・・・・・
例えば、変数：&hdl で指定したフォームに［確認］コマンドを送るには次のようにします。
変数宣言 自動，文字列｛ &targetFileName ｝
変数宣言 自動，文字列｛ &sendMacro ｝
変数宣言 自動，整数 ｛ &found, &status, &multi, &mode ｝
変数宣言 自動，整数 ｛ &hdl, &done ｝
&targetFileName = #一括パス名 + "hoge.wfx"
手続き実行 HDLLNCprcHdlSeek( &targetFileName, &found, &status, &multi, &mode )
if ( &found .and &status ) /* フォームのウィンドウが見つかった */
&sendMacro = "確認"
&hdl = &found
手続き実行 HDLCOMprcMacroSend( &hdl, &sendMacro, &done )
end
＜重要＞
［メッセージ（コマンド）送信器］があるのですから、［メッセージ（コマンド）受信機］もあります。
センダーに対する、レシーバーですね。
INF_Framework を組み込んだフォームでは、レシーバーは受信を許可した状態でセットアップされます。
そして、INF_Framework を組み込んでいないフォームには、レシーバーがありませんから。
当然ですが、メッセージ（コマンド）を送信できません。
この場合には、桐のエラーにならずに、INF_Framework からメッセージでご案内します。
つまり、あくまでも［ハリウッドの原則］が適用されているというわけです。(^^ゞ
■ ［イベント駆動型］のアプローチに関して
> 相手側で 主 に直接影響を与えるアプローチは良くない の概念がここで生まれたのでした(^^ゞ
> あの時は、プログラムを書くこと自体がほぼ初めてでした。
> 下手に固定概念が着く前に上記の概念を教えて頂いた事が私にとって物凄い幸運でした(^^♪
> それで 解決方法 &gAnswer を使ったアプローチサンプルをご提案頂きました。
> この時に "ピタゴラスイッチ" を覚えました。
> 同一の ○○.kex 内であれば 手続きで 値渡し 若しくは 戻り値でピタゴラスイッチが作れます。
> 複数のフォーム間であった時、 値渡し が出来れば 相手側に直接影響を与えず、
> ピタゴラスイッチ によって プログラム発動有無が決めれるのにな・・・
> という思いが 値送信 に固執したのです。
> 明らかに、幅が広がりますよね(^^♪
> 結果
> >>そうです、まさしく「こんにちは。モードレスA」でしょ。ガハハハha
>>はい！
>>これが一番やってみたかったのです。
>>これを具体的に利用する想定は無いのですが、値を 送信 したかったのです。
>>常々思っている事なのですが、↑こういう発想をする人って案外と少ないと思いますよ。
> 私の送信発想のは ONnojiさん がプログラム作成初期の私に教えてくれて、これが出来たら便利だと感じた事が原点なのでした(^^ゞ
ＤＯＳ桐から桐ver.7までの相当長い期間、桐の利用者は［フロー駆動型］の一括処理でプログラムを書いていたのです。
そして、桐ver.8で［イベント駆動型］の「フォーム＋イベント処理」が作れるようになっても、
決して、一括処理でプログラムを書くことを止めようとはしなかったのですね。
理由はいろいろありますね。
桐ver.8では
・「フォーム＋イベント処理」で使用するコマンド・メソッド・イベントハンドラ等に虫が多かった
・これらの虫の多くが fix されたのは、ようやく桐ver.8 sp6 になってからです
・従って虫が多いので使用を躊躇した人が多い
という技術的な側面↑と
以下↓の
・［フロー駆動型］の一括処理に慣れていたので、［イベント駆動型］を理解出来ない人が多かった
・従って「フォーム＋イベント処理」でアプリケーションが作れると思わなかった人が多かった ※コレ、本当なんですよゾ～
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
という具合に、［フロー駆動型］から［イベント駆動型］へのパラダイムシフトに追従できない人が多かったと思いますよ。
脳の思考が［フロー駆動型］なのですから、フォームやフォーム上のオブジェクトが［ピタゴラ装置］として目に映らないんですよ。
［ピタゴラ装置］に見えないのですから、力ずくで何とかしようと悪戦苦闘するんですね。
それだったら、最初から［フロー駆動型］の一括処理の方がマシでしょう的な「フォーム＋イベント処理」を作っちゃうのですよ。
これは悲劇ですよね。(T_T)
そうならない為には、脳の思考を［フロー駆動型］から［イベント駆動型］へ大転換しなければなりません。
私( ONnoji )は、その事をパラダイムシフトと呼んでいるのです。
そして、ＤＯＳ桐からの桐のユーザには、このパラダイムシフトが上手に出来ない人が多いのですよ。
しかし、Ｗｉｎ桐から始めた桐のユーザはむしろ［フロー駆動型］の方が分かり難いと思います。
また、最近のＷｉｎ桐では、一括処理のサンプルは添付されなくなりました。
これも、時代の移り変わりを反映していると思いますよ。
＜つづく＞
|
|
|
| ■503 / ResNo.56) |
Re[5]: Thin_INF_Framework のご案内
|
□投稿者/ ONnoji -(2024/09/12(Thu) 16:33:25)
| 2024/09/12(Thu) 17:15:48 編集(投稿者)
ジェダイの桐さん
> 質問
>
> HDLCOMprcMacroSend で 整数 を送信したい場合は
>
> 送る側
> &sendMacro = "手続き実行 prc整数を受け取る( " + &WQ + "m伝票番号" + &WQ + &comma + &WQ + #文字列( &int ) + &WQ + " )
>
> 受け取る側
> 手続き定義開始 prc整数を受け取る( 文字列 &variableName, 整数 &int )
> ・
> ・
> ・
> &setInt = #set( &variableName, &int )
>
> の様に &string を &int へ置き換えれば 対応可能でしょうか？？
なんと、&m伝票番号 は文字列型変数だとお伺いしていましたが？？？
伝票番号というのは、足したり引いたり掛けたり割ったり（四則演算）の対象ではないでしょ。
ただ数字を使っているからという理由で数値として扱うのはどうでしょうかね。
私( ONnoji )は、日頃から合計や平均を求めたりしない符丁（コード）の類は文字列であると説明していますが・・・
大抵の場合、入力時のチェックの都合だけなんですよね。
・・・・・・・・・・・・・・・・・
フォームのテキストボックスに入力された文字が、すべて数字なのか否かのようなチェックはイベントで簡単なんですけれどねぇ～。
まあ、表に直接入力するからという切実な理由も分からないでも無いですが、基本的に感心しませんねぇ～。
・・・・・・・・・・・・・・・・・・
よく考えてください、
もしも、伝票番号が文字列型であれば、先頭からｎ文字めまでを指定して絞り込み（検索）ができますよね。
しかし、伝票番号が文字列型であれば、面倒な式を使わなければならないでしょう。
まあ、プログラムの作り方は自由ですから、これ以上余計な事は申し上げませんけれど・・・ (ーー;)--------------> ※遠い目線
× &sendMacro = "手続き実行 prc整数を受け取る( " + &WQ + "m伝票番号" + &WQ + &comma + &WQ + #文字列( &int ) + &WQ + " )"
〇 &sendMacro = "手続き実行 prc整数を受け取る( " + &WQ + "m伝票番号" + &WQ + &comma + #文字列( &int ) + " )"
もしも、整数型 &int の値が、123456 だったとすると
× &comma + &WQ + #文字列( &int ) + &WQ + " )" → ,"123456" )
〇 &comma + #文字列( &int ) + " )" → ,123456 )
と文字を連結するだけですから、難しく考える必要はありませんよ。
でもこの手の連結は初級者が一番不得意とするものの一つなんですね。
&comma は コンマ( , )
&WQ は 二重引用符( " )つまり、ダブル・クォーテーション 本当は &DQ なんでしょうけれど、私は &WQ を使います
もしも、変数を使わないで記述すると・・・
リテラルで書くと &sendMacro = "手続き実行 prc整数を受け取る( ""m伝票番号""," + #文字列( &int ) + " )"
変数を使うと &sendMacro = "手続き実行 prc整数を受け取る( " + &WQ + "m伝票番号" + &WQ + &comma + #文字列( &int ) + " )"
リテラルで書くと、失敗する人が後を絶たないんですよね。ガハハハ
なお、
&setInt = #set( &variableName, &int )
の変数：&setInt は整数型ですね。もちろんでしょ。アハハハ
ちなみに、なぜ #set 関数を使用したのかを説明しましょう。
それは、もしも、変数：&m伝票番号 が存在しなかった場合でも、エラーにならないようにしたからです。
もしも、間違いなく、&m伝票番号 が存在するのであれば、
&setInt = #set( &variableName, &int )
は
&m伝票番号 = &int
でも結果は同じです。
後者の方がそのものズバリ、直感的で分かり易いでしょうね。
・・・・・・・・・・・・・・・・・・・・・・・・・・・
>>ここで、大事なのは、
>>オペレータが［コマンドボタン：cmdＣＳＶ読み込み処理］を実行する意思を持って押したのか？という事です。
>>案外と押すつもりが無かったのに、うっかり押しちゃったということもあるんですよね。
>>だから、先回りする僭越な行為は要らないのです。
>>何よりも大事なのは、オペレータが押したボタンが即応答する事なのです。
>> ・・・・・・・・・・・・・・・・・・
> ONnojiさん のプログラムが凄いなと思う事は
> 作業者がきっかけを与えるまで、単なる文字列 なんです。
> 作業者がきっかけを与えた瞬間に、単なる文字列 に 意味が初めて生まれ
> しかも、ケースバイケースで 動いて行っている。
> 上手く表現できないですが、意味を究極まで先送りして 結論を最後の最後で出しているイメージです。
> だから、結果の精度 が高いのだろう・・・
> と勝手に思っています。
> 素人が思う事なので、全く見当違いかもしれませんが(T_T)
当たり前ですが、アプリケーションはユーザに満足感を与えるようなデザインにするべきだと思っています。
私( ONnoji )は、オペレータを無視した開発者の独りよがりのアプリケーションを嫌と言うほど見てきました。
最悪の例としては、これはＤＯＳ桐の一括処理でしたが、月次の支払い業務を行う一括処理でしたね。
経理の担当者が、この一括処理を実行するワケですが、一度でも実行開始すると、途中で止められないんですよ。
信じられないでしょう。
途中で休憩して続きを行うなんて事は、想定外の更に外なんですね。
もちろん、この一括処理を作った人は、ずぶの素人さんです。その会社の経営者ですよ。
当時、書店で市販されている「桐の参考書」を購入して、ほぼ丸写して出来上がった一括処理です。
とにかく、すごいんですヨ。もちろん良い意味ではなく正反対の意味でスゴイ！
経営者自らが作ったアプリケーションを引き継いだ経理担当者は、文句が言えずにそのまま使うしかないんですね。
今だったら、パワハラですね。
そして、内容を拝見すると、［手続き実行］コマンドが一切使われていなくて、［名札］と［分岐］だけで茹で上がったスパゲッティプログラムなんですよ。
このような悲惨な事例はきっと世の中に星の数ほどあるだろうなと思ったワケです。
おそらく、今でも「プロセス（処理）中心」でアプリケーションを設計して、
さらにユーザインタフェースが劣悪なアプリケーションが山のようにあるのではないでしょうかね。(>_<)
これは、桐だけに限りませんよ、アクセスでもエクセルでも、高額な開発費をつぎ込んだソフトウェアでも同じです。
だいぶ脱線しましたが・・・(^^ゞ
月並みではありますが
良いアプリケーションを開発するには
・スパゲッティではないプログラムを心掛けること ⇒ ネットや書籍でプログラムの制御構造の正確な知識を学習する事
・データ中心の設計をすること
・良いユーザインタフェースを作る ⇒ ネットや書籍でユーザインタフェースの学習をする事
が大事だろうと思いますね。
ちなみに、もっともおろそかになり易いのは、ユーザインタフェースの学習です。
その中で、古典中の古典として
ベン・シュナイダーマン｜フリー百科事典『ウィキペディア（Wikipedia）』
https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%B3%E3%83%BB%E3%82%B7%E3%83%A5%E3%83%8A%E3%82%A4%E3%83%80%E3%83%BC%E3%83%9E%E3%83%B3
の「インターフェースデザインの8原則」くらいは覚えておいてください。
最近では、ネットで秀逸なページが閲覧できるので、以下のキーワードでググってみてください。
対話設計における８つの黄金律
Eight Golden Rules in Dialogue Design または Eight Golden Rules of Interface Design
例えばこちら 英語のページですが日本語に切り替えれば読めますよ
↓
HOME / ブログ / シュナイダーマンのインターフェースデザインの8つの黄金律
https://userpeek.com/blog/shneidermans-eight-golden-rules-of-interface-design/
ちなみに、私( ONnoji )がベン・シュナイダーマンの翻訳書籍に出会ったのは３０年以上前のことでしたっけ。アハハハha
|
|
|
| ■504 / ResNo.57) |
Re[6]: Thin_INF_Framework のご案内
|
□投稿者/ ジェダイの桐 -(2024/09/12(Thu) 17:05:12)
| ONnojiさん
こんにちは！
すみませんm(__)m
上手く説明が出来ていませんでした。
&m伝票番号 は 文字列型であっています。
例えば 整数 &mAns を送信する場合は どうしようかなと思って質問したんです。
あの質問の仕方であれば、&m伝票番号 が 整数型 だと思われます。
誤解を与えてしまい申し訳ありませんでしたm(__)m
> 〇 &sendMacro = "手続き実行 prc整数を受け取る( " + &WQ + "m伝票番号" + &WQ + &comma + #文字列( &int ) + " )"
> 〇 &comma + #文字列( &int ) + " )" → ,123456 )
> と文字を連結するだけですから、難しく考える必要はありませんよ。
> 変数を使うと &sendMacro = "手続き実行 prc整数を受け取る( " + &WQ + "m伝票番号" + &WQ + &comma + #文字列( &int ) + " )"
> &setInt = #set( &variableName, &int )
> の変数：&setInt は整数型ですね。もちろんでしょ。アハハハ
> ちなみに、なぜ #set 関数を使用したのかを説明しましょう。
> それは、もしも、変数：&m伝票番号 が存在しなかった場合でも、エラーにならないようにしたからです。
> もしも、間違いなく、&m伝票番号 が存在するのであれば、
>
> &setInt = #set( &variableName, &int )
>
> は
>
> &m伝票番号 = &int
>
> でも結果は同じです。
>
> 後者の方がそのものズバリ、直感的で分かり易いでしょうね。
> ・・・・・・・・・・・・・・・・・・・・・・・・・・・
非常に分かりやすい解説 ありがとうございますm(__)m
> 良いアプリケーションを開発するには
>
> ・スパゲッティではないプログラムを心掛けること ⇒ ネットや書籍でプログラムの制御構造の正確な知識を学習する事
>
> ・データ中心の設計をすること
>
> ・良いユーザインターフェースを作る ⇒ ネットや書籍でユーザインターフェースの学習をする事
>
> が大事だろうと思いますね。
こちらを念頭に置いて、勉強してきます。
アドバイスありがとうございます。
> ちなみに、もっともおろそかになり易いのは、ユーザインターフェースの学習です。
>
> その中で、古典中の古典として
>
> ベン・シュナイダーマン｜フリー百科事典『ウィキペディア（Wikipedia）』
> https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%B3%E3%83%BB%E3%82%B7%E3%83%A5%E3%83%8A%E3%82%A4%E3%83%80%E3%83%BC%E3%83%9E%E3%83%B3
>
> のインターフェースデザインの8原則くらいは覚えておいてください。
>
> 最近では、ネットで秀逸なページが閲覧できるので、以下のキーワードでググってみてください。
>
> 対話設計における８つの黄金律
>
> Eight Golden Rules in Dialogue Design または Eight Golden Rules of Interface Design
>
> 例えばこちら 英語のページですが日本語に切り替えれば読めますよ
> ↓
> HOME/ ブログ / シュナイダーマンのインターフェースデザインの8つの黄金律
> https://userpeek.com/blog/shneidermans-eight-golden-rules-of-interface-design/
ご紹介ありがとうございますm(__)m
記事を読ませて頂きます！
|
|
|
| ■505 / ResNo.58) |
Re[7]: Thin_INF_Framework のご案内
|
□投稿者/ ONnoji -(2024/09/12(Thu) 19:16:00)
| ジェダイの桐さん
> 最近では、ネットで秀逸なページが閲覧できるので、以下のキーワードでググってみてください。
>
> 対話設計における８つの黄金律
>
> Eight Golden Rules in Dialogue Design または Eight Golden Rules of Interface Design
８つの黄金律 でググると日本語のページが見つかりますね。
例えばこちら
↓
Shneiderman氏の「インターフェイスデザインの８つの黄金律」とは | UX MILK
https://uxmilk.jp/64295
日本語と翻訳された日本語では、微妙に違うことがありますが、
元々はインターネットもスマホも無い時代のものですから、
・・・・・・・・・・・・・・・・・・・・・・・・
時代と共に、解説が少しづつ変化しているようです。
・・・・・・・・・・・・・・
もちろん大枠では何も変わっていないのですが、
具体例が、コンピュータ → スマホ、
アプリケーション → ｗｅｂブラウザ
といったように変化していることがありますよ。
|
|
|
■記事リスト /
レス記事表示 →
[親記事-9]
[10-19]
[20-29]
[30-39]
[40-49]
[50-58]
|
で表示されます。
で表示されます。
ダブルクリック考(3)
