Die Elemente einer Hashtable haben immer einen Schlüssel, den du entweder bei Add() als ersten Parmeter oder an den Indexer als Index übergibst. Im Beispielcode ist das immer der Wert der in strId drinsteht. Mit _htAlleObjekte[strId] greifst du also immer auf das Element zu, welches durch den Schlüssel strId identifiziert wird.
Der Schlüssel ist vom Typ System.Object, kann also beliebig sein. Der Schlüssel ist keine bestimmte Property deines Objekts, da die Hashtable die Logik deiner Objekte bzw. deren Klassen nicht kennt. Es ist also deine freie Entscheidung, woher dieser Schlüssel kommt und wo du diesen speicherst. Der Einfachheit halber bietet es sich logischerweise an, diesen in einem Instanzfeld des Objekts zu speichern und als Property ohne Setter zur Verfügung zu stellen. Es obliegt dann aber immer noch dir selbst, der Hashtable zu sagen, welcher Schlüsselwert zu verwenden ist, da die Hashtable diesen Umstand nicht kennen kann.
Original von RIDI2oo5
@bitstream: dein code könnte aber auch noch optimiert werden. etwa so:
Das würde ich nicht als Optimierung ansehen. Und besser finde ich es auch nicht, da es (zumindest für meinen Geschmack) es schlechter lesbar ist. Kurz gesagt, es war Absicht, das aktuelle Relation-Objekt in einer separaten Variable zu halten.
Xgene schrieb ausserdem: "oder wäre vielleicht eine hashtable eine bessere wahl?". Das wäre wirklich zu überlegen, eine Collection einzusetzen, bei der du den Relation-Namen als Schlüssel verwendest. Dann brauchst du gar keine Schleife mehr...
Ich würde folgendes vorschlagen, das auch das (bei einer grossen Anzahl von Einträgen) unperformante foreach() durch for() ersetzt.
public void DeleteRelation(string relationName)
{
for (int i = 0; i < this.relations_.Count; i++)
{
Relation r = (Relation) this.relations_[i];
if (r.RelationName == relationName)
{
this.relations_.RemoveAt(i);
break;
}
}
}
Du kannst für die verschiedenen Ansichten auf der rechten Seite UserForms erstellen, die du bei einem Buttonklick gegeneinander austauschst. Damit hast du den gewünschten "Effekt", und es spricht auch nichts gegen so ein Vorhaben.
Original von RIDI2oo5
1. was meint ihr, wenn ihr von der 'mangelnden sicherheit des IE' redet? in welche richtung? ist dies auch für einen 'standard-user' relevant?
Was mir spontan einfällt: ActiveX, VBScript, das sogenannte Sicherheitszonenmodell, die vielen Bugs, die feste Verdrahtung von Browser und Betriebssystem und nicht zuletzt die häufigeren Attacken wegen seiner grossen Verbreitung.
Ich arbeite schon aus Prinzip und aus Sicherheitsgründen ausschliesslich mit dem Firefox. Darüber hinaus hat er einige nette Features, hinzu kommen viele praktische Extensions und eine deutlich bessere CSS-Unterstützung. Dass Firefox langsam sein soll, kann ich keineswegs bestätigen. Einzig bei komplexen Tabellenkonstrukten (sehr gross und/oder mehrfach verschachtelt) gibt's hier und da Probleme, aber sowas tut man sich auch nicht freiwillig an. Ich sehe also keinen Grund, warum ich mir den IE antun sollte. Selbst vor Firefox habe ich eine Alternative genutzt, damals Opera.
Original von MSuthe
Dabei habe ich festgestellt, dass beim ersten Auslösen der Exception diese eine beachtliche Laufzeit benötigt. Bei einem erneuten Auslösen nicht mehr.
Das ist zwar ärgerlich aber normal und wohl auch nicht zu ändern. Das passiert aber nur im Debug-Modus in der IDE. Wenn du die EXE separat startest, ist das Problem verschwunden. So, who cares? Btw, bei mir dauert das Catching nur ca. 2-3 Sekunden.
Im Framework gibt es leider keine Möglichkeit hierzu. Du kannst dir aber bei The Code Project ein fertiges Control für die Eingabe von IPv4-Adressen heraussuchen.
Original von Quest
Hmm, das ganze geht noch weiter, wenn ich "192.169.020.010" Parse krieg ich "192.169.16.8" raus - irgendwie verstümmelt der jedes mal bei führenden Nullen...
Vorausgesetzt die Teile mit führenden Nullen werden als Oktalzahl gewertet, wäre das ja auch korrekt: 010 oct = 8 dez. Merkwürdig wird es eigentlich nur, wenn bei Voranstellen einer 0 eine ungültige Oktalzahl wie 019 notiert wird. Da würde ich einen Fehler erwarten.
Zitat
In dem Link von bitsream gehts ja um genau dasselbe...
Den habe ich mir selber nochmal angeschaut. Dort geht es zwar um das Compact Framework, aber wenigstens habe ich überhaupt etwas dazu gefunden...
Bei mir funktionieren auch alle vier (Fx 1.1) ohne Fehler.
Allerdings passiert etwas merkwürdiges bei den führenden Nullen: Der String "192.169.20.018" bspw. wird in die IP-Adresse 192.169.20.16 umgewandelt.
Bei führenden Nullen und Merkwürdigkeiten denke ich immer sofort an das Oktalsystem, vor allem, wenn die Merkwürdigkeiten nahe 7 und 8 auftreten. Das stimmt auch, sofern es korrekte Oktalzahlen sind. Beispiel: Aus "192.169.20.017" wird 192.169.20.15.
Merkwürdig wird's aber wirklich bei ungültigen Oktalzahlen wie dem 018 aus dem ersten Beispiel oben. Das müsste eigentlich zu einem Fehler führen; stattdessen bekommen wir die gänzlich unpassende Adresse 192.169.20.16 für "192.169.20.018".
Original von herbivore
Im Englischen hat 'instance' dagegen viele Bedeutungen und tatsächlich ist die richtige Übersetzung von 'instance' im Zusammenhang mit OOP 'Exemplar'.
Bekannt ist mir das schon, zumal in vielen sprachunabhängigen, vor allem älteren Texten eher von 'Exemplar' die Rede ist. Dennoch sage und schreibe auch ich normalerweise 'Instanz', um Unverständnis zu vermeiden.
Zitat
und wenn ich es mir recht überlege, scheib ich in Zukunft wieder 'Exemplar', wie ich das in Vor-MyCSharp-Zeiten getan habe.
Wäre eine Überlegung Wert. Unnötige Anglizismen und falsche Übersetzungen sind mir eigentlich auch ein Dorn im Auge. Die 'Umwelt' verleitet einen selbst dann aber doch oft dazu, es auch falsch zu machen...
Zitat
Und wo wir gerade bei dem Thema sind, gibt es noch zwei Informatik-Standard-Fehlübersetzungen: 'control' wird oft/meistens mit 'Kontrolle' übersetzt, obwohl es 'Steuerung' heißen müsste. Ein Indiz dafür haben wir alle vor der Nase. Das 'Ctrl' der Control-Taste ist ja auf deutschen Tastaturen korrekt mit 'Strg' für Steuerung übersetzt.
Was ich in diesem Zusammenhang noch viel schlimmer finde: Vielen ist offenbar nicht bewusst, dass 'Strg' eine deutsche Abkürzung ist und lassen sich dabeu auch nicht dadurch beirren dass alle anderen Tasten mit deutschen Worten bzw. Abkürzungen beschriftet sind. Allzuoft höre ich, dass die 'Strg'-Taste mit 'String'-Taste oder -- noch viel schlimmer -- als 'Strong'-Taste bezeichnet wird. Da rollen sich mir die Fussnägel...
Zitat
Dass das hier keine Moralpredigt sein soll, mag daran klar werden, dass ich selbst mein halbes Leben fälschlicherweise davon ausgegangen bin, dass Stati die korrekte Mehrzahl von Status ist. Vor ca. einer Woche wurde ich eines Besseren belehrt. Korrekt ist Status - mit langen u gesprochen. Anfreunden kann ich mich damit immer noch nicht. :-)
Lustigerweise wurde mir von einem Lehrer mal der Plural-'Status' als falsch angekreidet, da musste ich ihn erst einmal davon überzeugen, dass es das Wort 'Stati' nicht gibt. Alternativ kann man im Plural auch von 'Statuswerten' oder 'Zuständen' sprechen.
[field:System.Reflection.FieldAttributes.NotSerialized]
public event ......
Mir ist allerdings schleierhaft, warum das nicht [event:System.Reflection.FieldAttributes.NotSerialized] heißt.
Warum dem so tut, ist ganz einfach: Der "field:"-Modifier soll explizit ausdrücken, dass sich das eben nicht auf das Event selber bezieht, sondern auf das "darunterliegende" Feld, in welchem die EventHandler registriert wurden.
Kleiner Tipp: Wenn du nun weisst, dass es eine Klasse namens BitConverter gibt, warum schaust du nicht einfach mal in deren Dokumentation, um den umgekehrten Weg selber herauszufinden?
Es reicht, wenn du im Designer im Eigenschaften-Grid unten rechts bei "Icon" die Icon-Datei auswählst. VS.NET fügt dann den passenden Code ein und legt für die Icondatei einen Ressourceneintrag an. Das musst du also nicht händisch zusammenfummeln.
Die Zeichen mit dem ASCII-Code 4 und 3 sind in einem Base64-String ganz sicher nicht erlaubt, zumal sie keine darstellbaren Zeichen sind. Der Sinn von Base64 ist es doch gerade, Nicht-ASCII-Zeichen zu kodieren!
Original von Quallo
@bitstream: Ich denke, dass Kraft recht hatte: Ich habe bei einer Stelle drei Zustände also drei Möglichkeiten.
Dass macht also Zustände^Stelle = 3^1 = 3.
Wäre es Stelle^Zustände, dann wäre es 1^3 = 1.
Stimmt, ich habe mich geirrt. Ich bin da wohl mit den Begriffen Felder und Zustände durcheinander geraten...
Es verhält sich ja so wie bei den Zahlensystemen! Wenn man eine vierstellige Binärzahl hat, gibt es 2^4=16 Kombinationen. Übertragen auf KRAFTs Frage haben wir also eine vierstellige Ternärzahl, also 3^4=81 Kombinationen.
Original von KRAFT
Ich habe ein Schema mit 4 Feldern. Jedes dieser Felder kann einen von 3 Zustanden annehem (1,2,3). Die Anzahl der Möglichen Kombinatioen ist also 3 hoch 4 also 81 wenn ich das richtig sehe.
Nein, die Anzahl möglicher Kombinationen ist immer Stellen^Zustände, in deinem Fall also 4^3 = 64.
Den Rest deiner Frage habe ich nicht verstanden... :-/
Alle URL-Parameter bei einem GET-Request müssen korrekt kodiert werden. Erlaubt sind nur bestimmte Zeichen des US-ASCII-Zeichensatzes. Alle Details dazu findest du in RFC 1738. Im Framework gibt es dazu System.Web.HttpUtility.UrlEncode.
Bei .NET ist es eigentlich relativ egal, welche .NET-Sprache du verwendest, da alle auf das selbe Framework zugreifen und in die selbe IL transformiert werden. Lediglich in der Syntax gibt es Unterschiede. Da du bereits Kenntnisse in Java und C++ hast, dürfte dir der Einstieg in C# sicherlich deutlich leichter fallen, da hier grosse Verwandtschaft in der Syntax besteht; VB.NET ist da völlig anders.
Und meine ganz persönliche Meinung: Die Syntax von VB (egal ob 6 oder .NET) ist hässlich, unübersichtlich und schlecht lesbar. C# hingegen ist schlank, elegant und leicht lesbar. Auch wenn man vorher mit VB6 gearbeitet hat, VB.NET ist doch zu anders, als dass einem das grossartig helfen würde.