4

私のいくつかのフォームでは、次の問題が発生することがあります。デザイナー（Visual Studio 2008、Windowsフォーム、.NET 2.0、VB.NET）を使用してフォームを編集し、コンポーネントを追加しましたが、後でいくつかの小さな調整があったことがわかりました。作成され（たとえば、フォームのサイズが突然数ピクセル変更された）、コントロールが削除されます。Handlesこれはサイレントに行われます。イベント処理メソッドのサフィックスも自動的に削除されるため、呼び出されることはなく、コンパイラエラーも発生しません。フォームの別の領域で作業しているため、気付くのはかなり後のことか、まったく気付かないことです。

例として、左側にSplitContainerインフラジスティックスを含み、右側にを含むフォームがあります。新しいタブとその中のコントロールを追加しましたが、正常に機能しました。後で、リストビューのスクロールバーのサイズがオフになっているために突然表示されなくなり、作業していない別のタブから少なくとも1つのコントロールが削除されたことがわかりました。UltraListViewUltraTabControl

これは、WinForms DesignerまたはInfragisticsの既知の問題ですか？もちろん、バージョン管理を使用しているので、変更を比較して削除されたコードをマージして戻すことができますが、これは面倒なプロセスであり、必要ないはずです。これを回避する方法はありますか？これが発生する正当な理由はありますか？

1つの手がかりは、削除されたコントロールにLoad、設計時ではなく実行時に実行されることを期待するコード（イベントハンドラーなど）が含まれている可能性があり、例外をスローしている可能性があることです。これにより、Visual Studioがコントロールを削除する可能性がありますか？

4

6 に答える 6

10

これはあなたの質問に対する答えではありませんが、ロードでは「DesignMode」を使用する必要があることを忘れないでください。これにより、設計時の予期しない奇妙な動作を回避できます。

private void EureFormAbm_Load(object sender, System.EventArgs e)
{
    if (!DesignMode)
    {
        // Your code
    } /* if */
}

また

private void EureFormAbm_Load(object sender, System.EventArgs e)
{
    if (DesignMode)
        return;
    // Your code
}
于 2010-04-20T22:18:26.437 に答える
2

問題を再現できる場合は、原因が例外であるかどうかを判断できます。Visual Studioの2番目のインスタンスを起動し、[ツール]->[プロセスにアタッチ]を使用して最初のインスタンスにアタッチします。次に、問題の再現に進みます。未処理の例外がスローされると、コードが破損するはずです。他の例外（おそらく処理される）に関する情報は、[出力]ウィンドウに表示されます。

于 2010-04-21T01:06:24.320 に答える
1

それはあなたにとって本当の答えではありませんが、ここに私が役立つと思ったいくつかのポインタがあります。

A） @DanielDolzの回答を参照してください。UI以外のコード（または任意のコード）をForm_Load完全に挿入しない場合を除いて、常に彼が推奨していることを実行することを心からお勧めします。これは実際には多くの問題を解決しますが、特にデザイナーに現れる例外やデザイナーのパフォーマンスの低下を解決します。

B）人間的に可能な限り：

Windowsフォームでdesigner.csを編集しないでください。

OK、時々あなたはそうしなければなりません、しかしそれは定期的な開発をする場所ではありません。サードパーティのコントロールには、そうする必要のあるバグがありますが、デザイナーファイルを直接変更するのは非常にまれな日です。これを管理するのに役立つ1つの方法は、デザイナーが何かを自動的に調整したくない場合は、それを通常の.csファイルにコピーすることです。それがすべてを網羅しているわけではありませんが、覚えておいてください。

C）また、IDEを介してレイアウトをロックし、マウスの迷いのクリックがすべてを台無しにするのを防ぐことができることを知っていますか？これにより、発生しているこれらの「自動更新」の一部が優先されます。

別れのショット私は現在のプロジェクトの直前に2年以上大規模なWindowsフォームプロジェクトに取り組んでいました。私が言えるのは、ごくわずかな編集を除いてデザイナーを編集する人々に終止符を打ち、彼らにDesignModeチェックでは、問題しかありませんでした。Webプロジェクトから離れて、マークアップの編集に慣れているため、このアイデアに苦労していますが、designer.csマークアップと同じではありません。

于 2010-04-21T00:38:45.987 に答える
1

DesignModeプロパティが予期しない結果を生成することがあることがわかりました（Danielの回答）。以下は、基本コントロールクラスにあるプロパティです（作成したほとんどのコントロールはこれを継承しています）。コメントは、ハッキーコードのように見える理由を示す必要がありますが、基本的に、これはDesignMode自体よりもはるかに信頼性があります。

    /// <summary>
    /// Indicates if the current view is being utilized in the VS.NET IDE or not.
    /// </summary>
    /// <remarks>The DesignMode property for a UserControl object will show that it is in DesignMode
    /// only if the immediate parent is viewed in the IDE; if it is a grand child of the object that is being viewed in the IDE,
    /// then the DesignMode property will not be true.
    /// This is a workaround</remarks>
    public bool InDesignMode
    {
        get
        {
            // Site.Design mode sometimes produces a better result.
            if (DesignMode || Site != null && Site.DesignMode)
                return true;
            Control parent = Parent;
            while (parent != null)
            {
                if (parent.Site != null && parent.Site.DesignMode)
                    return true;
                parent = parent.Parent;
            }

            // Note: I am not 100% sure about this one; I need to double check
            // if in design mode then entryAssembly will be null. This check is 
            // needed because DesignMode property is only true for the control
            // that is actively being designed, so child controls will be false...
            // We do check the Parent heirarchy in InDesignMode but in some 
            // cases Parent will not be set before the check is required.
            var entryAssembly = Assembly.GetEntryAssembly();
            if (entryAssembly == null)
                return true;

            return false;
        }
    }
于 2010-04-21T02:44:15.823 に答える
0

これは、OSに問題があったときにVisualBasic6.0と初期の.NETで発生するのを見てきました。再起動して修復する必要がありました。

于 2010-04-20T18:41:06.710 に答える
0

もう1つの良い習慣は、デフォルトのフォームコンストラクターを削除しないことです。ロジックが使用しない場合でも、IDEはそれらを使用します。ロックも便利です。

于 2010-04-21T13:26:13.940 に答える