No more Death March

あるSEのチラシの裏 C# WPF

WPF TextBoxのIsReadOnlyとIsEnabledの組み合わせについて

WPFに関するちょっとしたメモ、TextBoxを修正させたくない場合基本的にはIsReadOnlyプロパティにTrueを設定するかIsEnabledにFalseを設定すると思われる。

が、IsReadOnly=False、IsEnabled=Trueの場合に限って、少し困ったことになる場合がある。それは、確かにキーボードによる文字入力自体は出来なくなるのだけど、既にテキストが入っている状態だと右クリックによるテキストの変換が動いてしまうということ。

TextBoxをカスタマイズして数字入力コントロールを作ったりした時、この仕様を理解していないとコードビハインドの制約をすり抜けて数字が漢数字に変換されてしまったりする。なので、TextBoxにIsEnabled=Falseと指定するのであれば、合わせてIsReadOnly=Trueを設定するようにしたい。

他にもコンテキストメニュー自体を無効化したり、入れ替えたりとやり方は色々あるのだけど、とにかくこういう動きが「仕様」ってことを抑えて置かないと意図しない文字が設定されることがあるので注意が必要だ。

ソースの記事自体はどこで見たか忘れたしまったのだけど確かMSDNでもこれに関して説明があってIsEnabled=Falseにするなら一緒にIsReadOnly=Trueにしましょう、という旨の解説がされていたと思う。

直感的にはIsEnabled=Falseであればコードで直接Textプロパティを操作する以外、テキストが変更されるようなことはないと思うが、これは「仕様」らしい・・・

WPF StackPanelとScrollVIewerの不思議な動き

StackPanelとScrollViewerを組み合わせた時、
思った通りにScrollViewerが機能せずに引っ掛かることがある。

普通に動く場合

f:id:nomoredeathmarch:20190120174203p:plain

StackPanelをScrollViewerでラップすると、
画像のようにスクロール操作が出来るようになる。

機能しない場合

f:id:nomoredeathmarch:20190120174207p:plain

先の例とほとんど変わらないのだが、
ScrollViewerの親要素の大きさがAutoで指定されていると、
スクロールバーが見切れた状態になりスクロール操作が出来ない。

じゃあどうする?

f:id:nomoredeathmarch:20190120174211p:plain

ScrollViewerのサイズが特定出来るよう、Autoではなく*で高さを指定するとスクロール操作が出来るようになる。

なにが原因なのか?

はっきりとした理由は不明、なので予想だけ。

StackPanelは列挙する方向に対して無限長の領域をとると思われる。
ので、ScrollViewerでラップしてやるとStackPanelから返ってくる要求サイズは無限長となりScrollViewerの要求サイズも無限長となる。

本来であれば更に親の要素に要求サイズを渡したとき、
親の要素が具体的に決まっていればその大きさに合わせてScrollViewerのサイズも調整されるが
GridのAuto指定の場合だと子要素のサイズが採用されるのでScrollViewerとStackPanelのサイズは不定となる。

結果、画面には収まらないが要求された通りの描画が行われScrollViewerから見ても子要素が全部収まってるという判断がされるので、
スクロール操作は出来ないよね、という具合に判断されている。

MSDNによるとRowDefinition.Heightプロパティの既定値はstarなので、
最初のサンプルと最後のサンプルではWindowの高さに合わせた調整が行われ、
ScrollViewerのサイズもレイアウト時に調整されたのだろう。

docs.microsoft.com

つまり、ScrollViewerが自分の高さがわからないという状況にならなければ良いわけで、
ScrollViewerのMaxHeightプロパティに値を指定してもスクロールバーは動くようになる。
が、動的に配置を調整してくれるXAMLの強みが無くなってしまうのでこの方法は微妙だと思う。


StackOverFlowでも「ScrollViewerが上手く動かない」というトピックが散見され、
みんな同じとこで嵌ってる様子。

この辺りは仕様上の挙動と直感的な挙動が剥離してるよなぁ。。。

WPF 不明な型 ~ を作成できません。

XAML関係で引っ掛かりやすいところ。

XAMLの中で名前空間を指定する際に、同じアセンブリ内であればアセンブリ名を省略して記述することが出来る。

次の画像がアセンブリ名を省略したもの。
f:id:nomoredeathmarch:20190114164547p:plain

省略せずに記述したものは次の画像のようになる。
f:id:nomoredeathmarch:20190114164551p:plain

省略した方が記述が短いので良いのだが、
前者のディクショナリを外部のアセンブリから利用し、その名前空間内で宣言された型を生成しようとすると。

不明な型 ~ を作成できません。

と実行時に例外が出てしまう。

後者のようにアセンブリ名を省略しなければ例外は発生せず、ちゃんと動いてくれる。
XAMLはパースされた側が解決出来るか否かではなく、パースした側が解決出来るかどうかという問題ということだろうか???
(その割にはリソースディクショナリをマージする記述は相対パスだけでも大丈夫だったりするのだけど・・・)

WPF 外部ライブラリに宣言されているリソースディクショナリの使用方法

いつも書き方を忘れるのでメモ。

下の画像のようにプロジェクトResourceDictionaryServe内にリソースディクショナリMyResourceDictionaryがあったとして
f:id:nomoredeathmarch:20190113230301p:plain

これをResourceDictionaryClientで使いたいとなった場合の記述は以下の通り
f:id:nomoredeathmarch:20190113230305p:plain

ResourceDictionaryのSourceプロパティに
"/{アセンブリ名};component/{リソースディクショナリ名}"
と記述する。

StackOverFlowExceptionの原因

忘れないうちにもう一つ、

ほとんどが記述ミスによるメソッドやプロパティの無限ループが原因だが、
Linqの遅延評価が多用されている場合も呼び出し時に発生することがある。

自分の場合、かなり頻度の高い処理の中で
同じ変数にLinqの遅延評価される戻り値を代入、
実行時まで大量のデリゲートが積み上がり呼び出し時に例外が発生していた。

無限ループと同様ただの記述ミスなのだけどレアケースなのでメモ。

WPFのVisibilityとIsVisibleの違い

twitterではぶつぶつ独り言を呟いているけど、
ブログの方は半年以上なにも書いてなかったのか・・・

ここしばらくWPFやC#で色々と痛い思いをしてるので、
忘れないように少しずつブログに吐き出す習慣をつけるようにしたい。

ソースやXAMLも載せた方が良いのだろうけど、
手間かけるとどうせ飽きるので適当に書きます。

で、掲題の話、
以前この違いをはっきり意識せずにコーディングしてて成大にバグったのでメモ

端的にいうと

Visibility→この要素の可視状態

IsVisible→この要素が表示されているか否か

ということ。