C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

掲示板トップ C# と VB.NET 入門 新規作成 利用方法 ツリー表示 トピック表示 ランキング 記事検索 過去ログ
ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

No.86416 の関連記事表示

<< 0 >>
■86416 　Re[5]: Listを使ったクラスへのアクセスについて
□投稿者/ 魔界の仮面弁士 -(2018/01/26(Fri) 17:29:50)
    ■No86393 (MTK さん) に返信
    > BasicButton　とか　ManagerMenu　といった命名の方がいいということですよね？

    非英語圏の単語を並べる場合はさておき、
    「英単語」を並べる場合には、英語の語順が良いと個人的には思います。

    ただ重要なのはむしろ、プロジェクト全体で統一の取れた命名規約を保つことですね。


    ちなみにスーパークラス専用となる基底クラスでは、
    しばしば「〜Base」と命名されることがあります。

    　System.Windows.Forms.ButtonBase　← Button / CheckBox / RadioButton など
    　System.Windows.Forms.TextBoxBase　← TextBox / RichTextBox / MaskedTextBox など

    と言っても、すべてのスーパークラスがそういう命名になるわけでは無いのですが。

    　System.Windows.Forms.ListControl　← ComboBox / ListBox など
    　System.Windows.Forms.CommonDialog　←　FolderBrowserDialog / FontDialog など


    ■No86411 (MTK さん) に返信
    >> ボタンを押せば、その機能を使うための別ウインドウが開くようにしたいと考えています。
    >> ボタン毎の画像や挙動を分けるためにも、分けています。
    > 昨日の回答を頂いて色々考えた結果、現在はbuttonをbuttonBasicクラスに継承して

    Form クラスを継承して Form1 クラスを作るのが一般的であるように、
    「Button クラスを継承した buttonBasic クラス」を継承して buttonA クラスを
    作るという設計にするのも一つの方針ですし、要件次第ではありますね。

    ボタンから呼び出される個別の処理を定義する場合は、ボタンクラスへの実装ではなく、
    ボタンのインスタンスに対してイベントを割り当てて実装するようにし、
    ボタンそのものの汎用的な振る舞いを定義する場合（長押しとかトリプルクリックとか）は、
    ボタンクラスへの実装にすることが多いです、私は。

    なお、継承を用いて実装する場合は、自クラスのイベントに処理を書くのではなく、
    イベントを呼び出すためのメソッド(OnClick など)をオーバーライドする方が望ましいです。
    https://opcdiary.net/?p=3966


    > Enabled か Visuble かは、どちらにするかちょっと悩んでみます。
    Visuble ではなく Visible ですね。


    > Enabledで管理すると、一般ユーザに管理者用機能名が知られてしまう（これが問題になりうるか）

    特定のユーザーしか使わない機能は、例えば、Office 2007 以降の「開発者リボン」のように、
    タブページやサブメニューなどを用いて、分けてしまうのも手です。

    そうすれば、その管理者向けサブメニューを開けない一般ユーザーの目から、機能名を隠せます。
    メニューを分けることで、呼び出すまでのクリック数が増えることになるのが難点ですが。



    > Visubleで管理すると、権限がないボタンが消えて、見た目が穴ぼこみたいになりそう
    > ということで、後は設計方針の部分になってくるかと思うので、検討をしてみます。

    関連性のあるボタンなら、まとまって配置されていた方が使いやすい面もありますので、
    必ずしも単純に均等配置すれば良いというもので無いのが、デザインの難しいところですね。

    また、「機能」をアイコンや文字ではなく、『位置』で覚える人もいるので、
    歯抜けな配置になったとしても、位置を大きく変えないほうが良い場合もあります。
    （もちろん、その逆もありえるのですが）


    異なる権限のアカウントでログインする必要が生じる運用形態がありえる場合、
    権限によってボタンの位置が変わってしまうことに、使いにくさを覚えるかもしれません。
    たとえば「休職者に対する代行処理」とか「他店舗の臨時支援」などといったケースです。


    似たような話は、Microsoft Office のメニューでも起きていました。
    バージョン 2000 あたりから、「利用頻度の低いメニュー項目が自動的に非表示となる」機能が
    追加されたのですが、人によってはこれを邪魔に感じることがあったようです。

    もちろん、使わない機能は見えない方が分かりやすい、という考えの人もいるので、オプション設定で
    　「最近使用したコマンドを最初に表示する」(Office 2000)
    　「常にすべてのメニューを表示する」(Office 2002/2003)
    を切り替えられるようにはなっていましたけれどね。
記事No.86386 のレス / END /過去ログ148より / 関連記事表示
削除チェック/



<< 0 >>
パスワード/

- Child Tree -