Guten Abend Liebe Community.

Mein Problem ist, wie man am Quelltext-Ausschnitt schon merken wird, etwas speziell. Hängt mit dem Projekt zusammen, mit dem ich arbeite.

Ich versuche es mal zu erklären.

In meiner Form.h geschieht folgender Aufruf:

Code cpp:

1 2 3 4 5 6 7

//Connect to the Wiimote //********************** //add event listeners to changes in the wiiremote //fired for every input report - usually 100 times per second if acclerometer is enabled     this->wm->WiimoteChanged += gcnew WiimoteLib::WiimoteChangedEventHandler(); //fired when the extension is attached on unplugged     this->wm->WiimoteExtensionChanged += gcnew WiimoteExtensionChangedEventHandler();

wm ist ein Objekt der Klasse Wiimote, die wiederum in dem WiimoteLib namespace aus der WiimoteLib.dll implementiert ist.

so nun wollte ich den Namespace in einer anderen datei (Events.h) erweitern. Etwa so:

Code cpp:

1 2 3 4 5 6 7 8

namespace WiimoteLib { ... public delegate void WiimoteChangedEventHandler(System::Object^ sender, WiimoteChangedEventArgs^ args); ... public delegate void WiimoteExtensionChangedEventHandler(System::Object^ sender, WiimoteChangedEventArgs^ args); ... }

Nun meldet der Kompiler folgendes:

Code :

1 2 3 4

error C2039: 'WiimoteChangedEventHandler': Ist kein Element von 'WiimoteLib' error C2061: Syntaxfehler: Bezeichner 'WiimoteChangedEventHandler' error C2039: 'WiimoteExtensionChangedEventHandler': Ist kein Element von 'WiimoteLib'  error C2061: Syntaxfehler: Bezeichner 'WiimoteExtensionChangedEventHandler'

Die Syntaxfehler sind "Folgefehler", aber die eigentliche Ursache kann ich leider nicht nachvollziehen.

Interessant ist auch, dass Wenn ich im Kompiler die Zeile schreibe:
---->WiimoteLib
und danach die zwei "::" setze wird im PopUp die o.g. Funktion gelisstet, dennoch erscheint die Meldung.

Was mach ich falsch? Hoffe mir kann jemand helfen.

MfG Marschal

Hi.

Warum willst du denn unbedingt den Event-Handler in dem fremden Namensraum erstellen?

Wo wird denn der Fehler angezeigt? Welche Dateien sind da jetzt beteiligt und wo wird welche Datei include'd?

Gruß

Hi, danke für deine schnelle Antwort,

Der Eventhandler wird ja nicht im fremden Namespace deklariert, oder?!

Also.
Ich habe die Form1.h, in der Auch der Fehler entsteht.

Dan die Main, in der auch alles includet wird, also die form1.h und die events.h.

In der Events.h ist der Namespace "WiimoteLib", in dem die zwei delegate Funktionen sind.

Der eigentliche Namespace "WiimoteLib" ist in einer externen managed DLL (WiimoteLib.dll)

Zitat von Marschal

Der Eventhandler wird ja nicht im fremden Namespace deklariert, oder?!

Stimmt. Du hast gar keinen Event-Handler deklariert/definiert.

Aber wozu willst du die delegate in einem fremden Namensraum deklarieren? Man pfuscht nicht in anderen Namensräumen rum.

Zitat von Marschal

Also.
Ich habe die Form1.h, in der Auch der Fehler entsteht.

Dan die Main, in der auch alles includet wird, also die form1.h und die events.h.

Und in form1.h inkludierst du events.h nicht?

Warum willst du denn überhaupt nochmal neue delegate erstellen? Zumal das dann völlig unterschiedliche Typen sind...

Code cpp:

1	this->wm->WiimoteChanged += gcnew EventHandler<WiimoteChangedEventArgs^>(this, &Klass::ChangedHandlerMethod);

Gruß

Also mein Prolem mit den delegate Funktionen hat sich nun geklärt Ich hatte die Datei falsch includet. Ich hab sie jetzt in der stdafx.h includet, im Vorkompilierten Header ist das ganze deutlich handsamer. Doch nun ein anderes Problem

ich möchte eine Klasse Ableiten. Doch krieg ich die Fehlermeldung:

Code :

1 2	...Events.h(24) : error C2011: 'WiimoteLib::WiimoteExtensionChangedEventArgs': 'class' Typneudefinition ...wiimotelib.dll: Siehe Deklaration von 'WiimoteLib::WiimoteExtensionChangedEventArgs'

Die Klasse hab ich wie folgt Angelegt:

Code cpp:

1 2 3

ref class WiimoteExtensionChangedEventArgs :         public System::EventArgs         {

Kompilieren tue ich übrigends mit /clrure, immer noch .net, immer noch selbiges Projekt.
Was mach ich falsch.

@deepthroat: Übrigends, warum ich "in anderen Namensräumen rumpfusche" ist, weil ich mich an einem Ähnlichen Beispiel orientiere, dieses ist jedoch in c# gestalltet. Deswegen möchte ich den Code erst mal genau so lauffähig kriegen. Ich werde nacher eh noch aufräumen müssen... Oder schlägst mir den Code aus der Events.h in die Form1.h zu übernehmen.

Hier mal Die Events.h:

Code cpp:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

#pragma once   using namespace System;   namespace WiimoteLib //der namespace aus der WiimoteLib.dll ist der selbe...liegt der Hund evtl hier? {     /// <summary>     /// Event to handle a state change on the Wiimote     /// </summary>     /// <param name="sender">Object sending the event</param>     /// <param name="args">Current Wiimote state</param> public delegate void WiimoteChangedEventHandler(System::Object^ sender, WiimoteChangedEventArgs^ args);       /// <summary>     /// Event to handle insertion/removal of an extension (Nunchuk/Classic Controller)     /// </summary>     /// <param name="sender">Object sending the event</param>     /// <param name="args">Current extension status</param> public delegate void WiimoteExtensionChangedEventHandler(System::Object^ sender, WiimoteChangedEventArgs^ args);       /// <summary>     /// Argument sent through the WiimoteExtensionChangedEvent     /// </summary> ref class WiimoteExtensionChangedEventArgs :         public System::EventArgs         {         /// <summary>         /// The extenstion type inserted or removed         /// </summary>     public: ExtensionType p_ExtensionType;         /// <summary>         /// Whether the extension was inserted or removed         /// </summary>     public: bool Inserted;           /// <summary>         /// Constructor         /// </summary>         /// <param name="type">The extension type inserted or removed</param>         /// <param name="inserted">Whether the extension was inserted or removed</param>     public: WiimoteExtensionChangedEventArgs(ExtensionType ext, bool inserted)         {             ExtensionType type = ext;             Inserted = inserted;         }     };       /// <summary>     /// Argument sent through the WiimoteChangedEvent     /// </summary>  ref class WiimoteChangedEventArgs:     public EventArgs     {         /// <summary>         /// The current state of the Wiimote and extension controllers         /// </summary>     public: WiimoteState p_WiimoteState;           /// <summary>         /// Constructor         /// </summary>         /// <param name="ws">Wiimote state</param>     public: WiimoteChangedEventArgs(WiimoteState wss)         {             WiimoteState ws = wss;         }     }; }

MfG Marschal

Hi.

Zitat von Marschal

ich möchte eine Klasse Ableiten. Doch krieg ich die Fehlermeldung:

Code :

1 2	...Events.h(24) : error C2011: 'WiimoteLib::WiimoteExtensionChangedEventArgs': 'class' Typneudefinition ...wiimotelib.dll: Siehe Deklaration von 'WiimoteLib::WiimoteExtensionChangedEventArgs'

Das könnte wieder ein include Problem sein.

Zitat von Marschal

@deepthroat: Übrigends, warum ich "in anderen Namensräumen rumpfusche" ist, weil ich mich an einem Ähnlichen Beispiel orientiere, dieses ist jedoch in c# gestalltet.

Das ist kein Grund es überhaupt zu versuchen. Was spricht dagegen sich einfach einen eigenen Namen auszudenken?

Und warum willst du das überhaupt in C++/CLI machen? Gibt es dafür einen Grund?

Gruß

Nein es gibt eigentlich keinen grund C++ mit CLI zu verwenden, aber ich find C++ allgemein eine schöne Sprache, auch wen C++ und C++/CLR auser dem Namen und zwei drei Systax Sachen nix gemeinsam haben, ne keine Ahnung, gibt keinen Grund.

Ich schätze mal du würdest mir wahrscheinlich auch C# ans Herz legen, wenn ich mit einer managed DLL arbeite

Zitat von Marschal

Nein es gibt eigentlich keinen grund C++ mit CLI zu verwenden, aber ich find C++ allgemein eine schöne Sprache

Ehrlich?! Naja, es gibt schönere / elegantere Sprachen.

Zitat von Marschal

Ich schätze mal du würdest mir wahrscheinlich auch C# ans Herz legen, wenn ich mit einer managed DLL arbeite

Ja, aber nicht nur dann. Man sollte die passende Sprache für ein Problem wählen. C++ bzw. C++/CLI sind nur unter bestimmten Bedingungen sinnvoll. Da du sowieso .NET hast, würde ich z.B. C# verwenden. Die Sprache ist klarer, bietet so angenehme Dinge wie LINQ und IntelliSense funktioniert meistens auch richtig (nicht so wie mit C++).

Gruß

S****se Dan werd ich einfach meine GUI übernehmen, und eben das ganze in C# aufbauen

Ich hätte von Anfang an auf nen Kumpel hören sollen:P Der meinte das selbe

Zu c# findet man auch deutlich mehr im Netz als zu C++/CLI

Aus Interesse, wofür biete sich den c++/cli "besser" an? Ist es theoretisch nicht egal welche Sprache ich mit CLR verwende? ist der Sinn des .NET nicht die Sprachen-unabhängige-Programmierung; wenn ich mich so ausdrücken darf?

Wenn du gute Links zu diesem Thema kennst wäre ich sehr dankbar, habe zwar den Wiki Artikel gelesen, aber wie es aussieht ist das immer noch nicht ausreichen

MfG

Zitat von Marschal

Aus Interesse, wofür biete sich den c++/cli "besser" an? Ist es theoretisch nicht egal welche Sprache ich mit CLR verwende? ist der Sinn des .NET nicht die Sprachen-unabhängige-Programmierung; wenn ich mich so ausdrücken darf?

C++ ist generell eine maschinennahe Sprache.

Und es ist die einzige Sprache des .NET Universums dessen Compiler nativen Code erzeugen kann und mit der man nativen/unmanaged C++ Code in managed Code nach dem IJW (it just works) Prinzip nutzen kann ohne das man P/Invoke oder COM verwenden muss.

Wenn man also alten Code hat, den man in .NET nutzen möchte, oder aus Effizienzgründen "handoptimierten" Code schreiben möchte oder einfach native Bibliotheken nutzen möchte (ohne P/Invoke etc.) dann wäre C++/CLI z.B. sinnvoll.

http://www.functionx.com/cppcli/index.htm
http://blogs.msdn.com/jolson/archive...-or-c-cli.aspx

Gruß