問題タブ [elementname]

名前によるバインディングの自己参照と RelativeSource による自己参照の違いは何ですか?

例えば：

対

私のプロジェクトでは、それらは同じように動作するように見えますが、ウィンドウで直接使用しています。これは、入力が少ないため、前者をすぐに好むことを意味します。

RelativeSource の唯一の利点は、(たとえば) 広く使用されているスタイルで自己参照できることですか? または、追加のセマンティックの違いがありますか?

を持っ{Binding ElementName=foo}ている場合、視覚ツリーまたは論理ツリーを検索しますか?

WPF の論理ツリーとビジュアル ツリーについて | データを見る、データする

論理ツリーが重要になるのはいつですか?

{Binding ElementName=Foo} などで名前を検索すると、継承可能なプロパティの場合と同じように、名前の範囲を検索するために祖先が検索されます。

アタッチされた動作による Silverlight での ElementName バインディング

これを有効にするために、WPF は ElementName および RelativeSource バインディングを提供し、ビジュアル ツリー内の他の要素を見つけてバインドするための強力なメカニズムを提供します。

編集：

によるバインドに使用される論理ツリーのように見えますElementName。

引数＃1。

MSDN の記事FrameworkElement Classによると:

FrameworkElement は UIElement を拡張し、次の機能を追加します。

• データ バインディングと動的リソース参照のサポート: データ バインディングとリソースのプロパティ レベルのサポートは、DependencyProperty クラスによって実装され、プロパティ システムに具体化されますが、式 (プログラミング構造) として格納されているメンバー値を解決する機能データ バインディングと動的リソースの両方の基盤となる) は、FrameworkElement によって実装されます。詳細については、「データ バインディングの概要」および「リソースの概要」を参照してください。

引数＃2。

ElementNameを指してx:Nameいるので、この名前は何らかの方法で見つける必要があります。NameScopeの概念があります。

ほとんどのシナリオでは、FrameworkElement および FrameworkContentElement で公開されている FindName メソッドは、名前で要素を検索するために呼び出すより適切なメソッドです。FrameworkElement および FrameworkContentElement によって公開される Name プロパティは、初期名をマークアップ属性として設定するために使用するより適切なプロパティです。また、FrameworkElement および FrameworkContentElement で公開されている RegisterName メソッドは、名前を特定の名前スコープに確立するために必要です (これを直接実行できる NameScope メンバーはありません。RegisterName を使用するには、最初に現在の名前スコープを設定する必要があります)。

一方、Visual クラスにはメソッドがなく、 INameScopeFindNameも実装されていません。

上と左の位置を取得した要素の名前または ID を検索したい。

jqueryを使用して要素の位置を見つける方法を知っています（divにカーソルを合わせると、その位置のテキストが画面に表示されます）：

MenuItemオブジェクト内に含まれるオブジェクトに対して、ElementName を持つバインディングが正しく解決されないことに気付いた人はいContextMenuますか? このサンプルをチェックしてください:

ContextMenu 内に含まれるバインディングを除いて、すべてのバインディングが適切に機能します。実行時に出力ウィンドウにエラーを出力します。

回避策を知っている人はいますか？何が起きてる？

重複の可能性：
jQueryはタグ名を提供できますか？

やあ！

この質問はとても基本的なもので、私は尋ねるのが恥ずかしいですが、結果が得られずに30分間答えを見つけようとしました。

以下のコードでクリックされた要素の種類を確認するにはどうすればよいですか。

私が探しているのは、this_element変数をリンクの場合は「a」に設定し、段落の場合は「p」に設定することです。

ありがとう！

まず私の英語でごめんなさい。ElementName が最初のケースでは機能せず、2 番目のケースでは機能する理由を尋ねたかったのです。

コードの 2 つのセクションを示します。最初は機能しません

しかし、それは機能します

Storyboard.TargetName を使用できることはわかっています。

ListBoxの高さをStackPanelの高さにバインドして、ListBoxが垂直方向に伸びるようにし、緑色の領域が表示されないようにします。

リストボックスにアイテムがない場合、そのアイテムは非表示になります。アイテムが1より大きい場合、リストボックスはそれ自体を追加/削除ボタンまで拡張する必要があるため、追加/削除ボタンは常にスタックパネルの下部にあります（そのためにドックパネルを使用したくない）

どうやってやるの？拘束力のあるエラーは発生しませんか？

次の TextBlocks の Bindings のうち、より多くのパフォーマンスを犠牲にするものはどれですか:

TextBlocks が多くの兄弟と祖先を持つ高いネストレベルにある場合、私の質問は異なる場合があると確信しています。

考慮事項

(個人的な考えのみに基づいているため、それぞれの特定の点で間違っている可能性があります!):

• ElementName:

  • 現在の要素を検索して比較し、そのすべての子、兄弟、叔父、祖先を含む大叔父 (登録されているすべての名前の HashTable があるのではないでしょうか?)
  • コントロールのプロパティを取得するNameと、 を呼び出すよりもパフォーマンスが低下しますGetType。
  • 文字列を比較する方が、型を比較す​​るよりも安価です。特に、ほとんどのコントロールにセットがないことがわかっている場合はなおさらNameです。

• FindAncestor:

  • 兄弟の「叔父」、「いとこ」などではなく、祖先を介してのみ反復します。
  • GetType先祖の型を決定するために使用される可能性が最も高いです。GetType は、単純なNameプロパティ ゲッターよりもパフォーマンスが高くなります (DP が異なる可能性がありますか?)

同じ量のアイテム（動的な量）を含む2つのコントロールを作成する必要があります。最初のコントロールはキーを表し、2番目のコントロールは値を表します。

ユーザーが上の列の幅のサイズを変更したときに、（値の）下の行の同じ列に影響を与えるようにするために必要です。

これが私が望むものの例です：

結果：

繰り返しになりますが、セルの境界線をサポートするDataGridのようなコントロールを作成できるようにしたいので、セルの幅と高さを他のコントロールの幅に接続してサイズを変更できるようにする必要があります。

私はそれがxamlyに行われることを好みます。注：これはカスタムコントロールなので、必要に応じて適切なプロパティを宣言できます。ただし、セルの高さと幅は動的で、特定の列/行に対して個別である必要があることに注意してください。

この質問を参照して、少し異なる方法で作成しました（セルの3番目のコントロールがあります）が、質問は同じです。列とセルの高さの幅を動的にし、ユーザーに能力を与えたいです。それらのサイズを変更して、相互に影響を与えます。

アップデート

デサイクロンの答えは私が実装したいものですが、彼が提供した例を試してみましたが、ItemsControlsのGrid.IsSharedSizeScopeプロパティをtrueに設定しましたが、機能しませんでした。結果は次のとおりです（トリミング）。

2つの異なるコントロール間で共有サイズスコープを適用することは可能ですか？

MultiDataTrigger.Conditions をラジオ ボタンにバインドしたいのですが、うまくいきません。これが私のシナリオです。

wpfには、ラジオボタンがあると思われるGridPanelがあります。

次のように、動的ラジオボタンを GridPanel に生成します。

私のxamlには、このラジオボタンの選択と別のコントロールのプロパティに基づいて変化する画像ボタンがありました。

ここに私のコードがあります:

プログラムを実行すると、エラー コードが表示されます:「参照を使用してバインドするためのソースが見つかりません」、条件は 2 番目の条件 (elementName=allAccountsBtn) に対して false を返します。

なぜこれが起こるのですか？

動的に名前が付けられ、生成された RadioButton から IsChecked プロパティを取得する方法はありますか?