C # Add-In für die Anwendung (über COM) friert ein, wenn ein Steuerelement zum Formular hinzugefügt wird?

8

Ich entwickle eine Erweiterung für bestehende Anwendungen über COM.

Die aktuelle Schnittstelle der zu erweiternden Anwendung ermöglicht es , benutzerdefinierte Eigenschaftenfenster zu erstellen und sie innerhalb dieser Anwendung zu verwenden.

Jetzt verwende ich .NET für diesen Zweck und habe seltsame Probleme:

%Vor%

Wie Sie unten sehen können, werden die Eigenschaftenblätter tatsächlich erweitert , aber danach beginnt etwas Seltsames.

Grundsätzlich, wenn ich zum Ololo Tab und dann wieder zu einem der anderen 3 Tabs ( Attributes , Drawing oder Services ) wechsle, dann friert die Anwendung ein. Ich weiß auch dass das Einfrieren innerhalb eines nicht verwalteten Codeblocks stattfindet.

Eine weitere interessante Tatsache ist, dass, wenn ich nicht extensionForm.Controls.Add(new Button()) (mit oder ohne Suspend / Resume Layout-Aufrufe) schreibe, alles gut funktioniert. Also Wenn das kürzlich erstellte Formular keine Steuerelemente (Schaltflächen oder andere) enthält, wird es nicht eingefroren.

Hier ist ein Spy++ Protokoll im Fenster Ololo direkt vor dem Einfrieren (die letzte Nachricht ist WM_CTLCOLORBTN , gleich danach wurde die Anwendung eingefroren):

Alles zusammen kombinieren:

  • Das Einfrieren erfolgt nur, wenn ich von Ololo zu einem anderen Tab wechsle und dann wieder zum Tab Ololo zurückwechsle.
  • Einfrieren kommt nur vor, wenn das integrierte Formular mindestens ein Steuerelement enthält, Formulare ohne Steuerelemente nicht einfrieren.
  • Die Anwendung führt derzeit keinen verwalteten Code aus und verbraucht keine CPU-Zeit.

Also - irgendwelche Ideen / ähnliche Probleme gelöst / etc helfen mir in diesem Fall?

    
Yippie-Ki-Yay 05.01.2012, 05:30
quelle

4 Antworten

4

Die Win32 HWND -Handles für die Formulare in .NET werden faul initialisiert. Und ich denke, das ist hier ein Problem.

Sie können argumentieren, dass das Handle in Ihrer Zeile ExApplAPI.AddCustomPropertyWindow(extensionForm.Handle.ToInt32(), "Ololo"); erstellt wurde, weil Sie auf die Eigenschaft Handle zugegriffen haben. Es ist wahr und was Dokumentation bestätigt.

Erzeugt jedoch das Handle für Form selbst, aber Handles für untergeordnete Steuerelemente (in diesem Fall Button ) werden nicht erstellt. Dies kann erzwungen werden, indem CreateControl method aufgerufen wird. Weitere Informationen finden Sie Dokumentation .

Ich weiß nicht, ob nicht ein Griff für den Knopf eine Ursache für Ihr Problem sein könnte, aber das ist definitiv etwas, das ich untersuchen würde.

Zusammenfassend schlage ich vor, den Code folgendermaßen zu ändern:

%Vor%     
Krizz 10.01.2012, 21:28
quelle
1

Gibt es Ausnahmen? Wir hatten ein ähnliches Verhalten bei der Verwendung von WPF und COM, es wurde durch Aufrufen der Double-Reset-Berechnung mit

gelöst

[DllImport ("msvcr70.dll", CallingConvention = CallingConvention.Cdecl)] public static extern int _fpreset ();

    
NPehrsson 11.01.2012 15:36
quelle
0

Es ist möglich, dass das Ressourcenhandle nicht richtig ist. Wie Sie bereits erwähnt haben, geschieht dies nur, wenn das integrierte Formular mindestens ein Steuerelement enthält. Die Ololo-Registerkarte kann ihre Ressourcen nicht finden, wenn sie wieder aktiv ist. Versuchen Sie, das Ressourcenhandle zum ersten Mal zu speichern und es dann jedes Mal wiederherzustellen, wenn die Registerkarte aktiv ist.

    
Shiva 10.01.2012 21:13
quelle
0

Um zu verstehen, warum die Anwendung hängt, gibt es zwei Dinge, die helfen können:

  1. Können Sie eine Stapelverfolgung des UI-Threads veröffentlichen, während die Anwendung hängt?
  2. Welcher Thread ruft Ihren Code auf und erstellt tatsächlich die Fenster?
Ran 12.01.2012 13:31
quelle

Tags und Links