Laden...

Überprüfen ob Type == System.DateTime?

Erstellt von Paulo vor 18 Jahren Letzter Beitrag vor 17 Jahren 2.011 Views
P
Paulo Themenstarter:in
172 Beiträge seit 2005
vor 18 Jahren
Überprüfen ob Type == System.DateTime?

Hab jetzt schon alle Variationen probiert aber ich find nicht die richtige, ich möchte prüfen ob mein object vom Typ System.DateTime ist.

object Value wird irgendwann im Code gesetzt, dann:


if (typeof(Value) == System.DateTime)
{
}

So gehts leider nicht, mit Value.GetType auch nicht.. wie macht man das korrekt?
Danke!

Q
992 Beiträge seit 2005
vor 18 Jahren

Ich glaube da gibt es den is-operator.
Also if(value is System.DateTime)

563 Beiträge seit 2004
vor 18 Jahren

Original von Quallo
Ich glaube da gibt es den is-operator.
Also if(value is System.DateTime)

du glaubst? es stimmt 😉

4.506 Beiträge seit 2004
vor 18 Jahren

Hallo!

Oder allgemein, wenn "is" nicht geht (Ich weiß nicht, ob das bei eigenen Klassen geht):



if (Value.GetType() == typeof(System.DateTime))
{
}


Also grad andersrum 😉

Geht "is" immer?

Ciao
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

Q
992 Beiträge seit 2005
vor 18 Jahren

Original von .unreal

Original von Quallo
Ich glaube da gibt es den is-operator.
Also if(value is System.DateTime)

du glaubst? es stimmt 😉

Ich weiß, sagte der SDK auch g

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo norman_timo,

Geht "is" immer?

Ja! Allerdings sollte man immer zweimal überlegen, ob 'is' wirklich das richtige ist. Es igt nur ganz, ganz weniger Fälle, in denen man den dynamischen Typ eines Objekt erfragen muss. In den meisten Fällen ist der dynamische Typ entweder klar oder er interessiert nicht.

herbivore

S
8.746 Beiträge seit 2005
vor 18 Jahren

Original von norman_timo
Oder allgemein, wenn "is" nicht geht (Ich weiß nicht, ob das bei eigenen Klassen geht):

  
  
if (Value.GetType() == typeof(System.DateTime))  
{  
}  
  
  

Achtung, Fallstrick:

Bei Vererbungshierarchien bringt "is" noch das korrektes Ergebnis, während der Typ-Vergleich nur den konkreten Typen vergleicht. Beide Ausdrücke sind also nicht äquivalent. Um mit dem Vergleich zu arbeiten müßte man via Reflection die gesamte Vererbungskette vergleichen.

Und wie Herbi schon sagte: Die Prüfung mit "is" gegen einen konrekten Typen bedeutet in den allermeisten Fällen ein schlechtes OO-Design (fehlende Polymorphie).

Ausnahmen sind generische Lösung wie z.B. der ErrorProvider.

4.506 Beiträge seit 2004
vor 17 Jahren

Hallo zusammen,

stehe gerade vor dem wirklichen Problem, dass ich Typen vergleichen muss. Hintergrund: Ich gehe beim Start die aktuelle DLL per Reflection durch, und möchte die Klassen finden, die "MarshalByRefObject" in der Vererbungshierarchie implementiert haben. Diese will ich dann per Remoting anbieten.

Im Prinzip möchte ich mir einen generischen Remoter basteln.

Hierzu verwende ich folgenden Code, der allerdings nicht so tut, wie er soll:


            Assembly assi = Assembly.GetExecutingAssembly();
            Type[] typen = assi.GetTypes();

            foreach (Type t in typen)
            {
                if (t.IsClass))
                {
                    if (t is MarshalByRefObject)
                    {
                        Console.WriteLine("YES: " + t.Name);
                    }     
                    else
                    {
                        Console.WriteLine("NO: " + t.Name);
                    }
                }
            }

Er findet hier tatsächlich alle Klassen, doch der is-Vergleich schlägt immer fehl, warum?

Ich zu dem Zeitpunkt der Vergleiche noch keinerlei Instanzen der Klassen gemacht, liegt es eventuell daran?

Wie bekomme ich meine Klassen, die MarshalByRefObject in der Vererbungshierarchie haben?

Für Hilfe bin ich schon jetzt dankbar.

Gruß
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

B
119 Beiträge seit 2005
vor 17 Jahren

Hallo,

Er findet hier tatsächlich alle Klassen, doch der is-Vergleich schlägt immer fehl, warum?

Ich zu dem Zeitpunkt der Vergleiche noch keinerlei Instanzen der Klassen gemacht, liegt es eventuell daran?

Es liegt halt ganz einfach daran, dass ein Objekt vom Typ Type eben kein MarshalByRefObject ist, da Type auch nicht davon erbt. Zwar ist es verständlich was du beabsichtigst, aber warum sollte der Typ Type in der Hinsicht besonders reagieren?

Zur Lösung:
Type.IsSubClassOf Method

grüße

4.506 Beiträge seit 2004
vor 17 Jahren

Hallo Bernhard,

jo, mit n bissl nachdenken bin ich dann auch auf den Trichter gekommen, dass der "is"-Operator nur bei konkreten Objekten Sinn machen kann.

Bei den vielen IsProperties in dem Type-Objekt ist mir das "IsSubClass" überhaupt nicht aufgefallen. Hatte zwischenzeitlich den Workaround eingebaut, dass er mittels "BaseType" rekursiv durch den Kompletten Vererbungsbaum geht, und jedes einzelne auf "MarshalByRefObj" überprüft. Im Prinzip wird das "IsSubClass" auch so machen, aber wahrscheinlich performanter 😉

Dank Dir für Deine Hilfe.

Gruß
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”