✔ Wie included ihr?

[Macan]

Jetzt hatte ich gerade das Posting fertig - wäre schon wieder länger geworden *g*

Jetzt habe ich mal Zeit gehabt mir mal alles mal genau durchzulesen und stelle fest,
dass es dir wirklich noch an der draufsicht zu der OOP fehlt Markus.

Absolut ja - und da möchte ich nicht gleich wieder in alte Muster verfallen

Das ist aber dank Namaspaces kein Problem mehr. Definier die Objekte in den gleichen Namespace
und Du kannst ohne was zu includieren darauf zu greifen. Ansonsten musst die entsprechenden Namespaces einbinden.

Ja, das hatte ich schon angefragt. Also mit namespaces sind includes egal. Ich hatte das gestern schon versucht, aber da hat wohl mein Intellisense gesponnen (siehe oben... Edit wegen gegenseitigen Includes).
Dann versuche ich das gleich nochmal (und reinige mal das Projekt manuell, damit wieder alles rund läuft).

Wenn Du auf bereits instanzierte Objekte zugreifen willst, musst sie in der Klasse in der sie definiert wurden
viá Property verfügbar machen und schon kannst auch auf sie zugreifen.

Also quasi static reference (hänge ich dann eben ein). Das mache ich schon so, nur kam mir das so... naja... das OOP umgangen vor.

Wie Du die Klassen bereit stellst die diese Objekte halten, ist allerdings wieder eine andere Geschichte.
Das kannst zum einen viá Referenzen lösen, die Du weiter reichst.

Das mache ich mit den Forms. Ist zwar noch etwas schmerzhaft, da ich da irgendwie unnötigen Code sehe (aber ich muss mich eben noch von alten Sichtweisen trennen).

Oder viá des Singleton Patterns (Statische Objektdefinitionen und Propertys),
was für deine Event und Localizing Klassen ideal währe.

So sie sich mittels namespaces dann auch gegenseitig kennen, ist das perfekt (static sind sie schon und hängen sich auch in ihr eigenes Property ein).

Mit UML versuche ich mich schon. Aber das ist auch eine Umgewöhnung *g*

Also habe ich das eine oder andere schon richtig gemacht - es hat sich eben nur irgendwie komisch angefühlt. Gut, dann sehe ich mal, wie ich die namespaces bei mir wieder zum Laufen bekomme

Vielen Dank für eure Mühe

 

[the incredible Leitman]

Soooo ich bin wieder da *Enthusiasmus-pur*

...
Moment...
...
Mist, zu langsam -.-

Damit meine ich, dass Du dir Gedanken machst wie Du von einer Sourcedatei zu anderen Objekte ansprechen sollst.
Das ist aber dank Namespaces kein Problem mehr. Definier die Objekte in den gleichen Namespace und Du kannst ohne was zu includieren darauf zu greifen. Ansonsten musst die entsprechenden Namespaces einbinden.

Das will ich auch meinen! Deshalb habe ich auch in meinem ersten Beitrag versucht, dir die Funktionsweise von namespaces näher zu bringen

Wenn du in einer Klasse eine globale Variable erstellst und an verschiedenen Stellen verwenden willst, auch außerhalb dieser Klasse, dann erstelle einfach ein
"public property" , mit einer get Methode dass dir diese Variable zurück gibt,
wie Christian meint.

public:
     [
          Category("Appearance"),
          Description("set which state the control should have"),
          DefaultValue(1)
     ]
     property int MyState
     {
          int get()
          {
               return this->m_state;
          }
          void set(int i_value)
          {
               this->m_state = i_value;
          }
     }

EDIT:
VERDAMMTER Mist, verdammter... *grml*
ich bin einfach viiiiiieeeel zu langsam -.-

 

[Macan]

Mist, zu langsam -.-

Das kann man so nie sagen

Das will ich auch meinen! Deshalb habe ich auch in meinem ersten Beitrag versucht, dir die Funktionsweise von namespaces näher zu bringen

Ja - da viel es mir dann auch wie Schuppen von den Augen. Hab's versucht, aber irgendwie scheint da wohl etwas gesponnen zu haben. Ich weiss auch nicht, wie ich die namespaces so übergehen konnte.

Ach und diese Properties [] - ah nun fällt der Groschen
Ich hab's bisher umständlich über "ganz normale" Properties gemacht.
Muss ich gleich mal probieren

Und da soll mal einer sagen, dass Du nicht auch noch Licht ins Dunkel bringen kannst

Danke auch Dir

 

[Christian Kusmanow]

Und da soll mal einer sagen, dass Du nicht auch noch Licht ins Dunkel bringen kannst

Das nenne ich aber mal Teamwork. ;-)

 

[the incredible Leitman]

Mist, zu langsam -.-

Das kann man so nie sagen

doch kann man...schon wieder passiert *lol*

Ach und diese Properties [] - ah nun fällt der Groschen

das sind eigentlich eh "ganz normale" Properties
die Anweisungen ind den eckigen Klammern geben lediglich Informationen für den Designer an, also ob und wie es in einem propertyGrid dargestellt werden soll...
Wollte einfach nur die komplette Schreibweise angeben,
da ich als ich meine ersten Custom Controls geschrieben habe auch im Windows Designer auf diese Properties zugreifen wollte und lange nirgends eine ausführliche Angabe gefunden habe -.-

bezüglich namespace:
Kann sein, dass du sie (wie dlls) in Visual Studio manuell einbinden musst
Dazu gehst du mit der rechten Maustaste auf dein Project->Properties
Dann CommonProperties->References und fügst mit Add New Reference ein was du noch brauchst

Hoffe das hilft dir irgendwie weiter...

Tut mir leid, ich habe so von den ganzen Basics in C und allem kaum Ahnung,
habe vor ca 6 Monaten zu programmieren angefangen und mich gleich an VC++.NET gewandt...
Aus diesem Grund bin ich in den eigentlichen Features wie casts, multicast delegaten und dergleichen noch nicht sattelfest... Dafür kann ich aber mit dem integrierten Windows Designer wundervolle Forms und Controls erstellen ^^

Das nenne ich aber mal Teamwork

T.E.A.M = Toll, Ein Anderer Machts *gg*

mfG
Michael Leithner

 

[Christian Kusmanow]

Was ist noch anfügen möchte ist, dass Du die Events deiner Eventklasse auch statisch Anbieten kannst,
sofern sie nicht Funktionaliäten anbietet, die das Instanzieren notwendig machen würde.
Wovon ich aber mal nicht ausgehe.
Somit brauchtest die Eventklasse ansich nicht in Singleton-Form verfügbar machen.

T.E.A.M = Toll, Ein Anderer Machts *gg*

Das hast jetzt anscheinend in den falsch Hals bekommen.
Du müsstest wissen, dass ich von c++ nicht so die Ahnung habe. Aber dafür eher von c++++

 

[the incredible Leitman]

Das hast jetzt anscheinend in den falsch Hals bekommen.
Du müsstest wissen, dass ich von c++ nicht so die Ahnung habe. Aber dafür eher von c++++

Nein, das hatte gar nichts zu bedeuten, ist mir nur eingefallen... jedesmal wenn ich das Wort Team irgendwo sehe, muss an meinen alten Werkstättenprofessor denken *lol* deshalb der kurze Einwurf ^^
Aber wie gesagt, das war nur ein kurzer Huster geistiger Kreativität, nicht auf irgendwas bezogen oder gar sinnvoll

ich weiß, ich weiß, du bist
||'''''' ++
||,,,, ++ - Master *gg*

 

[Macan]

Das nenne ich aber mal Teamwork.

In der Tat - nachdem die Konfusion ("was will der eigentlich") mal weg ist Jetzt kann ich mich damit mal genauestens befassen.

das sind eigentlich eh "ganz normale" Properties
die Anweisungen ind den eckigen Klammern geben lediglich Informationen für den Designer an, also ob und wie es in einem propertyGrid dargestellt werden soll...

Ah ok. Und das public dort (mal sehen, ob das in C++ genauso ist) macht die dann quasi sichtbar? Ich dachte mir, dass public in dem Zusammenhang nur heisst, dass auch andere Assemblies Zugriff haben können. Aber - so oder so - wieder was gelernt

bezüglich namespace:
Kann sein, dass du sie (wie dlls) in Visual Studio manuell einbinden musst
Dazu gehst du mit der rechten Maustaste auf dein Project->Properties
Dann CommonProperties->References und fügst mit Add New Reference ein was du noch brauchst

Also so ist da nichts einzubinden. Geht wohl nur, wenn man eben eine .exe oder .dll hat. Assemblies basteln (also .dll's)... soweit bin ich noch nicht *g* Eine .exe und die Sprachresourcen in .dll sind bis jetzt das höchste der Gefühle

Tut mir leid, ich habe so von den ganzen Basics in C und allem kaum Ahnung,
habe vor ca 6 Monaten zu programmieren angefangen und mich gleich an VC++.NET gewandt...

Sei froh - ich habe dauernd das Gefühl, ich mache etwas unanständiges, wenn ich in alte Denkmuster (c) verfalle *g* Wobei das eine oder andere mir nun nicht mehr sooo schmutzig erscheint.

Nur mit den namespaces, das scheint noch nicht so zu wollen. Also wenn ich nur Sourcecode habe, dort eben in jeder .h (und zugehörigen .cpp Datei) die namespaces definiere... also:
Datei Foo.h

namespace Foo
{
code... (Definitionen, Methoden, etc.)
}

dann benötige ich nur noch die namespaces, also:
Datei Bar.h

using namespace Foo;

und alles wird gut? #include Foo ist dann nicht mehr nötig? Ich frage, weil das bei mir nicht funktioniert.

 

[Christian Kusmanow]

Ah ok. Und das public dort (mal sehen, ob das in C++ genauso ist) macht die dann quasi sichtbar? Ich dachte mir, dass public in dem Zusammenhang nur heisst, dass auch andere Assemblies Zugriff haben können. Aber - so oder so - wieder was gelernt

Autsch, sowas musst aber im Schlaf beherrschen genau so wie die Operatoren.
Lerne bitte unverzüglich alle Zugriffsmodifikatoren und deren Funktionsweise auswendig.

Nur mit den namespaces, das scheint noch nicht so zu wollen. Also wenn ich nur Sourcecode habe, dort eben in jeder .h (und zugehörigen .cpp Datei) die namespaces definiere... also:
Datei Foo.h

namespace Foo
{
code... (Definitionen, Methoden, etc.)
}

dann benötige ich nur noch die namespaces, also:
Datei Bar.h

using namespace Foo;

und alles wird gut? #include Foo ist dann nicht mehr nötig? Ich frage, weil das bei mir nicht funktioniert.

Michael, mach Markus doch bitte mal eine kleine Demo dazu.
Ich denke dann wird sich auch noch das Problem schnell lösen.

//Edit:

ich weiß, ich weiß, du bist
||'''''' ++
||,,,, ++ - Master *gg*

lol
Und Du anscheinend der ASCII Art Master. ;-)

 

[Macan]

Was ist noch anfügen möchte ist, dass Du die Events deiner Eventklasse auch statisch Anbieten kannst,
sofern sie nicht Funktionaliäten anbietet, die das Instanzieren notwendig machen würde.
Wovon ich aber mal nicht ausgehe.

Stimmt, aber ich hab mal spasseshalber folgendes gemacht:

	public:
		static MyEvent^ MyEventRoot;
	private:
		delegate static void DoEventDelegate(String^ MyEventMessage);
	public:
		static DoEventDelegate^ DoEvent;
	private:
		void TriggerEvent(String^ MyEventMessage);

Sieht ungeordnet aus, ich weiss

Der Konstruktor übergibt EventRoot die Addresse von sich selbst, ruft dann die ganze Initialisierung auf (mit sich selbst) und am Ende wird noch ein static delegate auf die nonstatic Methode TriggerEvent gebaut. So wird, bei nicht statischer, also instantiierbarer Methode TriggerEvent ein statischer Verweis auf die Methode gebastelt. Wie gesagt - nur so aus Spass Falls ich nichts übersehen habe, könnte ich so threadsafe (und simpel) mehrere Objekte instantiieren (nur die Trigger-Methode, ach und der Handler würden dann instantiiert werden und ich müsste mir keine Gedanken wegen threadsync machen).
Eigentlich ist alles statisch, auch TriggerEvent.

Ist aber nicht schlecht, einen static delegaten auf non-static Methoden bauen zu können.