Unmanaged DLL

BitConverter**

Das hört sich alles leider nicht überzeugend an - eine .NET Klasse kann man nicht global oder statisch anlegen!

Jochen Kalmbach

Hab ich irgendwas von einer statischen Klasse geredet?
Du solltest mal bei mir einen C++/CLI Kurs machen
http://blog.kalmbach-software.de/de/2009/04/16/schulung-in-ccli/

ref class Test
{
internal:
  static Form1^ s_form1;
};

void Show()
{
    if (Test::s_form1 == nullptr)
    {
        Test::s_form1 = gcnew Form1();
        Test::s_form1->Show();
    }
}

void Change(int val)
{
    if (Test::s_form1 != nullptr)
    {
        Test::s_form1->PublicProperty = val;
    }
}

BitConverter**

Das werde ich mal ausprobieren.

Gestern abend habe ich folgende Lösung hinbekommen:

msclr::auto_gcroot<DotNetClass^> pDotNetClass = gcnew DotNetClass();

Zumindest läuft es so wie gewünscht.

Jochen Kalmbach

So geht es natürlich auch... dann hast Du die Referenz jetzt ganz in den Unmanaged Code verlagert. Das ist aber etwas Zeitaufwenidiger; zumindest aus Performance-Sicht, da der Unmanaged-Pointer zuerst wieder das richtige Element auf dem GC-Heap suchen muss. Wenn Du die Referenz gleich als solche abspeicherst, dann fällt dieser Vorgang weg.

BitConverter**

So, hab´s wie beschrieben probiert - läuft ebenfalls. Ob performanter kann ich so nicht feststellen.

Sowohl mit gcroot als auch mit der neuen Methode habe ich noch ein seltsames Problem. Solange ich Komponenten aus der normalen Toolbox im Form verwende läuft alles prima. Sobald ich aber eigene Controls (in C# geschrieben) verwende, dann gibt´s eine Exception.

Irgendeine Idee woran das liegen kann? Zumal diese C# Controls auf anderen Forms funktionieren. Nur in dieser DLL Form knallt´s.

Jochen Kalmbach

Es wäre natürlich hilfreich, wenn Du uns verraten könntest, WAS für eine Exception da kommt...
Vermutlich greifst Du auf die Oberfläche aus verschiedenen Threads zu, oder der Thread wurde nicht mit STA initialisiert.
Aber das hat mir jetzt nur meine Kristallkugel gesat; die wird aber auch immer dunkler...

BitConverter**

Naja, die Exception von der Anwendung ist nicht wirklich informativ: Externe Exception E0434F4D

Wenn es an verschiedenen Threads liegen sollte, dann verstehe ich nicht warum die C# Controls auf einem "normalen" C++/CLI Form Anwendung einwandfrei laufen.

Auch wenn der letzte Schliff noch fehlt, möchte ich mich für die bisherige Unterstützung schon mal bedanken.

Jochen Kalmbach

Warum kannst Du nicht debuggen?
WinForms kann man nur von *einem* Thread aus verwenden! Das ist aber auch in C# so!

BitConverter**

So wird z.B. eine LED aus meiner Assembly MDControls eingebunden

private: MDControls::Displays::Led^ led1;

Ich habe mal einen Breakpoint im Constructor auf InitializeComponent() gesetzt.

Wenn ich in der Methode InitializeComponent() diese Zeile auskommentiere,

this->led1 = (gcnew MDControls::Displays::Led());

dann kann ich mit Einzelschritt in die Methode InitializeComponent() reingehen und einzeln durchlaufen. Mit dieser Zeile führt bereits der erste Einzelschritt im Constuctor (der eigentlich in InitializeComponent() landen sollte) bereits in der Anwendung zu dieser Exception.

Jochen Kalmbach

VIelleicht wirft ein statischer Konstruktor in der Displays-Klasse ein Fehler?
Da kann ich leider auch nur Raten...
Oder wurde die C#-Assembly für x64 übersetzt und Du verwendest ein x86 Projekt?

Möglichkeiten gibt es viele...

BitConverter**

Ich hab´s

Ein try/catch im Constructor hat die überraschende Erleuchtung gebracht.

System.IO.FileNotFoundException: Die Datei oder Assembly "MDControl, Version..." konnte nicht gefunden werden.

Dann habe ich die DLL MDControls ins Verzeichnis der Anwendung kopiert - das war´s. Damit habe ich nun überhaupt nicht gerechnet.

Nochmals Danke für den Support.