__declspec(dllexport) visual c++ Objecte übergeben.

Hallo zusammen,
vielleicht wisst ihr Rat auf mein Problem.
Ich möchte mit __declspec(dllexport) eine Windows Forms Panel funktion erstellen.
Aber der Compiler sagt mir das dies nicht mögich ist.
Beispiel:

__declspec(dllexport) System::Windows::Forms::Panel^ paneldlltest()
{
...
return panel
}

Mfg

Postings ohne cpp tags werden hier nur sehr ungern beantwortet. Passe dich an oder zieh Leine.

asc

Davon abgesehen das die Frage ins C++/CLI-Forum gehört, das ist keine Frage zu MFC (noch zu C++), und Mitleid mal etwas freundlicher sein könnte (Ein Hinweis zu den Tags reicht in der Regel, man muss sich nicht gleich im Ton vergreifen).

C++ Forumbot

Dieser Thread wurde von Moderator/in Martin Richter aus dem Forum MFC (Visual C++) in das Forum C++/CLI mit .NET verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Jochen Kalmbach

Du kannst keine Managed Datentypen per dllexport exportieren. Verwendet dazu "unmanaged" code...

Wie verwende ich den:

Jochen Kalmbach schrieb:

"unmanaged" code...

Können Sie mir vielleicht ein ein Beispiel geben?

Jochen Kalmbach

__declspec(dllexport) void Test();

Also ist es nicht möglich Windows Forms Objecte als Function zu verwenden?

LordJaxom

Du scheinst da etwas grundlegend misszuverstehen.

Windows Forms und alle Klassen, die im System-Namespace liegen, gehören zu DotNET, einem Framework mit eigener Intermediate Language, virtueller Maschine, Garbage Collector usw. Die Sprache mit den Hütchen ^ nennt man C++/CLI, eine Erweiterung von C++ um DotNET-Code zu schreiben (naja, eigentlich um native Code mit DotNET zu verheiraten). Wenn Du eine DotNET-Referenz auf ein Form aus einer DLL zurückgeben möchtest, brauchst Du keine dllexport-Angaben, das macht der Compiler dann schon vollautomatisch für Dich, vorausgesetzt Dein Projekttyp ist eine DotNET-Klassenbibliothek und die Funktion/Klasse ist öffentlich (public). Mit solchen Funktionen/Klassen kannst Du dann aber in "reinem" C/C++ nichts anfangen (mit Einschränkungen).

dllexport brauchst Du, wenn Du eine "reine" (native, unmanaged) C- oder C++-Funktion oder -Klasse exportieren willst. Da kannst Du dann aber keine DotNET-Referenzen zurückgeben.

Also, was willst Du genau machen?

Jochen Kalmbach

Da muss ich meinem vorherigen Poster wiedersprechen...

Man kann sehr wohl eine DLL bauen, die "reine" dllexport Funktionen exportiert und intern trotzdem .NET vollständig verwendet.

Man muss wie gesagt einfach eine "normal" Funktion mit "_declspec(dllexport)" markieren und in dieser Funktion kann man dann beliebige .NET Dinge anstellen.
Es muss als keine "native" FUnktion sein, sondern nur eine, welche eine "native" Schnittstelle hat (also keine .NET Datentypen in den Parametern / Rückgabewerten).

LordJaxom

Jochen Kalmbach schrieb:

Man kann sehr wohl eine DLL bauen, die "reine" dllexport Funktionen exportiert und intern trotzdem .NET vollständig verwendet.

Das schließt sich ja nicht aus. Ich sprach ja im ersten Absatz explizit von der Rückgabe einer DotNET-Referenz. Der letzte Absatz ist tatsächlich missverständlich formuliert, es müsste heißen "dllexport brauchst Du, wenn eine Funktion einen nativen Typ zurückgeben und in nativem Code zur Verfügung stehen soll. Da kannst Du dann aber keine DotNET-Referenzen zurückgeben".

Danke schon mal für die Hilfe und Tipps.
Ich würde dann mit DotNET-Referenz arbeiten.

Das was ich programmieren möchte sieht so aus, das es ein Forms-Programm gibt welches ein leeres Panel enthält. Beim start des Programms wird dann die DLL
"BeispielPanel.dll" aufgerufen. In der Dll ist dann eine Function:

Forms::Panel^ GibPanelZurueck()
{
... return PANEL;
}

In dem Programm wird diese Function aufgerufen und das leere Panel in der Forms anwendung bekommt die eigenschaften des Panels welches durch "GibPanelZurueck()" zurückgegeben wird.

Jochen Kalmbach

1. Es macht für mich keinen Sinn, dass Du C++/CLi machst; oder warum willst Du das?
Siehe auch:
http://blog.kalmbach-software.de/de/2010/03/05/ccli-und-winforms-macht-keinen-sinn/
2. Wenn Du mit .NET direkt arbeitest, dann musst Du einen Namespace und eine Klasse verwenden. Darin kannst Du ja eine statische Methode anlegen, wenn Du keine Instanz erzeugen willst.
3. Warum willst Du die DLL "dynamisch" laden?
4. Du solltest Dir vielleicht ein PlugIn-System/Interface anschauen

Zu 1. Ich programmiere c++ schon etwas länger und habe erst kürzlich angefangen visual studio zu benutzen. Ich komme mit v.s. auch gut klar.
zu 3. Mich hat es interrsiert ein programm zu schreiben welches externen /dynamischen code/dll laden kann. Und ich würde gern mit Forms::Objects^ arbeiten.
Zu 4. Ich kam noch nicht dazu mir dieses anzuschauen aber werde es in der nächsten zeit machen.

Jochen Kalmbach

zu: Assembly dynamisch laden:
Assembly::Load*
und
Activator::CreateInstance...