問題タブ [pinning]

古いAPIを使用していて、構造体のポインターを非同期で実行されるアンマネージコードに渡す必要があります。

つまり、構造体ポインターをアンマネージコードに渡した後、アンマネージコードはポインターをコピーして、すぐに戻ります。アンマネージコードは、別のスレッドでバックグラウンドでその構造体にアクセスできます。別のスレッドで実行されるアンマネージコードやスレッド自体を制御することはできません。

固定{}ステートメントは、非同期のアンマネージドピン留め用に設計されていないため、ピン留めには使用できません。

GCHandleは参照のみを固定できるため、GCHandleを使用するには構造体をボックス化する必要があります。私はそれを試しました、そしてそれは働きます。それに関する主な問題は、マネージコードから構造体を更新できないことです。構造体を更新するには、まずボックスを解除し、次に更新してから、もう一度ボックス化する必要がありますが、...おっと...ボックスをもう一度？！？これは、メモリ内の以前のポインタがまだ古い非最新の構造体を指していることを意味し、新しい構造体には別のポインタがあります。これは、新しいポインタをアンマネージコードに渡す必要があることを意味します...場合。

固定{}ステートメントなしで構造体をメモリに固定し、ポインタを変更せずにマネージコードから構造体を更新できるようにするにはどうすればよいですか？

ありがとう。

編集：

考えただけです...構造体を含む親オブジェクトを固定してから、コンテナオブジェクトではなく構造体のポインタを取得する方法はありますか？

メインアプリがバックグラウンドでロードされている間、きれいなUIを備えた「ランチャー」アプリを持つアプリケーションがあります。これらのアプリはどちらも VB6 で作成されています (ため息)。

Windows 7 では、ユーザーがランチャー プログラムを固定すると、タスクバーに 2 つの異なるアイコンが表示されます (1 つはメイン アプリ用で、次に固定されたアイコンはランチャー プログラム用です)。これは非常に奇妙に見えます。

次の関数を使用してみました: http://msdn.microsoft.com/en-us/library/dd378422%28VS.85%29.aspx今のところ役に立ちません。

ドキュメントでアドバイスされているように、UI がポップアップする前に、両方に同じ名前 (Company.Product) を付けました。実行中にランチャー アプリをピン留めすると、問題なく動作します。実行可能ファイルをランチャーに固定すると、2 つのアイコンが表示されます。

ユーザーがランチャーexeを固定するだけで問題ないように修正する方法についてのアイデアはありますか?

ガジェット サイドバーのように、フォームをデスクトップに固定しようとしています。

Win+D および [デスクトップの表示] ボタンの影響を受けません。

これに最適な方法はどれですか？

Progman を見つけてフォームの親をこれに設定することはできますが、これは最善の方法ではないと読みました。

任意のランクの配列を反復処理する必要があります。これは読み取りと書き込みの両方に使用されるため、機能しGetEnumeratorません。

Array.SetValue(object, int)多次元配列では機能しません。 Array.SetValue(object, params int[])多次元空間を反復処理するには、過度の演算が必要になります。paramsまた、署名の一部を回避するために動的な呼び出しが必要になります。

配列を固定してポインターで反復したいのですが、多次元配列が連続していることが保証されているというドキュメントは見つかりません。ディメンションの最後にパディングがある場合、それは機能しません。また、安全でないコードは避けたいと思います。

単一のインデックスのみを使用して多次元配列を順番にアドレス指定する簡単な方法はありますか？

GridSplitterを何らかの方法で拡張して、クリックするとコントロールをスプリッターの指定された側の1つに展開または折りたたむボタンを追加しようとしています。

Silverlight 4で機能するソリューションを見つけましたが、.NET 3.5の標準WPFで機能するには、これが必要です。つまり、GridSplitterは、Shemeshのソリューションで使用されるVisualStateManagerのものを実装していません。.NET 3.5のWPFでは機能しないことを除けば、Shemeshのソリューションは、スムーズなアニメーショントランジションと、折りたたまれた状態から拡張したときの最後の拡張サイズを覚えていることで、おそらくまさに私が探しているものだと思います。

誰かがこれが通常のWPFで行われている例がありますか？

私はよくテストを実行し、テスト結果ペインを固定する必要があります。それ以外のときは、主にコードを書いてコンパイルします。コンパイル中に出力ペイン(テスト結果ペインと同じスペースを共有) を自動的に表示し、完了したら折りたたむ (固定を解除する) ことを好みます。

ペインを固定/固定解除状態にすばやく切り替えるホットキーが必要です。どうやってやるの？

CL_MEM_ALLOC_HOST_PTR呼び出しでフラグを使用しましたclCreateBufferが、Compute Profiler はすべての「ホスト mem 転送タイプ」をページング可能として表示します。2 つの異なるカーネル設定で試してみましたが、プロファイラーは固定メモリを使用していることを示しませんでした。

カーネルが固定メモリを使用するようになるのは本当にランダムですか? 何かに拘束されているのでしょうか？バッファのサイズが重要だと推測しています。サイズが 10,000 フロートのバッファを 1 つ試してみましたが、まだページング可能なメモリがありました。皆さんの考えを教えてください。

ハンス・パッサンが 望むようにこれが私のシナリオです。私は、パフォーマンスを尊重しながらネイティブ コードがすべてのハードワークを実行し、マネージ コードが GUI のみを担当する混合モード アプリケーションを使用しています。また、ユーザーは独自の C# コードを作成して参加します。ネイティブ クラスには C++、GUI とユーザー コードには C#、その間にラッパー クラスには C++/Cli があります。私のすべての C++ クラスの中には、計算の %90 を実行し、毎回異なるパラメーターが作成されるクラスがあります。それを NativeClass と呼びましょう。約あります。この NativeClass のインスタンスは 2000 個あり、計算を行う前に、いくつかのパラメーターに関連する適切なインスタンスを見つける必要があります。そこで、この目的のために、パラメーターがハッシュ コードである hash_map を考案しました。パラメータを取得したら、hash_map で適切なインスタンスを探し、それを見つけて、そのメソッドのいくつかを呼び出します。
ユーザーが C# コードを記述して計算に貢献すると、このクラスはコールバックによってこれらのコードを実行します。これは些細なことですが、ユーザーが作成した .Net クラスに関する情報が必要になることがあります。したがって、その特定の ManagedClass を NativeClass に何らかの方法でアタッチする必要があります。私の最初の解決策は、GChandle.Alloc() を使用してハンドル アドレスを転送することです。しかし、GC が適切に機能しないという懸念もあります。Hans は、Marshal.AllocCoTaskMem() と Marshal.StructureToPtr() を使用してアンマネージド メモリにマネージド オブジェクトを割り当てることを推奨しましたが、これは値型のクラスまたは構造体に有効であると私は信じています。refクラスはどうですか？GC が収集されるのを防ぎながら、NativeClass への参照を渡し、同時に GC を適切に機能させるにはどうすればよいですか?

サンプルコードは次のとおりです。

長くなりすぎて、まだわかりにくくてすみません。

次のコードでは、client.Connect.Receive が "byte[] 結果" を永久にピン留めしているように見えますが、メモリは解放されません (常にピン留めされているため)。this.OnReceive での使用後に結果を固定する必要がなくなったことを C# に伝える方法を探していますが、これを行うための組み込み関数またはキーワードが見つかりません。

C# で byte[] 配列の固定を解除する方法を知っている人はいますか? (これは、私の C# アプリケーションでのメモリ リークの原因の 1 つです)

ファイル コピーの進行状況に関する通知を取得するために、LPPROGRESS_ROUTINE パラメーターに匿名デリゲートを渡して C# アプリケーションから CopyFileEx を呼び出しています。

私の質問は、匿名のデリゲートを固定する必要があるかどうか、およびその理由 (またはそうでない理由) です。

さらに、次の場合、答えは変わりますか?

1. CopyFileEx はブロックされませんでした。
2. 匿名ではないデリゲートを渡した場合。

ありがとう！