Forenbeiträge von onlinegurke Ingesamt 778 Beiträge
Die Aussage schreibgeschützt ist aber so auch nicht richtig. Vielmehr wird eine Referenz auf das Objekt in die Variable kopiert.
x="....."
ist also rein syntaktisch völlig i.O., ändert nur halt nix an der Auflistung, weil dann eine Referenz auf ein anderes Objekt in die Variable (wohlgemerkt nicht in die Auflistung) kopiert wird.
Blöd finde ich foreach aber nicht... 😉
wär eher für sowas hier:
public class Team
{
private string mName;
public Team(String name) {mName=name;}
public Name{ get{return mName;}}
static void Main()
{
TeamCollection teams=new TeamCollection();
teams.Add(new Team("AlphaTeam"))
}
}
public class TeamCollection:thumbsup:bjectModel.KeyedCollection<String, Team>
{
overrides String GetKeyForItem(Team item) { return item.Name;}
}
//edit: [/csharp] vergessen...
ganz ohne Ahnung gehts nicht. Schau dir mal die Links unter Ressourcen an und meld dich, wenn du dann konkrete Probleme hast.
Team t=new Team();
oder was meinst du? Objekte werden IMMER zur Laufzeit erstellt. Lies dir mal bitte erstmal das durch, sollte bei den meisten Fragen helfen...
schonmal mit "FFFF" als Input getestet? Durerfte an dieser Stelle:
data = Convert.ToByte(oneByte,16);
einen Fehler bringen, weil es aus dem Bereich von Byte rausgeht. Verwende UInt16. Muesste es auch eine Methode geben (Convert.ToUInt16)
//edit: sry, hab einen denkfehler gehabt, dachte du meintest zwei Byte und nicht zwei Zeichen
Fehlende using-Direktive auf System.Text.RegularExpressions
ansonsten ist der Code so syntaktisch korrekt, aber es wär hal günstiger den Regex gleich einmal zu kompilieren.
Man denkt doch beim Schach auch nicht, "Kann ich auf F4 mal die Dame stellen?" sondern eher "Kann ich die Dame mal auf F4 stellen?". Maßgeblich sind doch nicht die Felder, sondern die Figuren...
Warum nehmt ihr das Spielfeld als Grundlage für das Objektmodell, warum nicht die Spielfiguren? Die eignen sich doch viel besser! Eine Basisklasse Spielfigur, die sowas anbietet wie Position und KannDahin(position) und eine Spielerklasse mit meinetwegen einen Namen und eine Figuren Eigenschaft. Würd ich logischer finden...
Hab mich mit 3.0 aber bisher auch kaum beschäftigt...
Wie meinst du selbst beibringen? Programm mit WPF schreiben versuchen, Buch durchlesen oder Tutorials durcharbeiten (oder alles davon)? Ich würd vor allem Buch lesen und dann Tutorials...
Mein Orcas Express Beta 1 (und jetzt auch 2) ärgert mich zur Zeit leider öfters mit der Fehlermeldung, dass EntityName in Zeile 2, Position 74 nicht geparst werden kann. Das tritt auf bei verschiedenen Designern, e.g. Windows-Forms-Designer und SQL Compact Edition Designer. Beim WPF-Designer ist mir das noch nicht aufgefallen, den benutz ich aber auch so gut wie gar nicht. Einen klaren Grund dafür (evtl. schlechte eigene Steuerelemente oder so) gibts nicht wirklich, das Problem tritt auch schon auf, wenn ich mich auf Framework-Steuerelemente beschränke.
Gibt es da außer mir noch jemanden, der das Problem hat, oder bin ich da auf verlorenem Posten?
Mir ist bewußt das dies das Konzept von EARLY Binding untergräbt.
Naja, wenn du die Funktionalität der Menüeinträge über eine Schnittstelle definierst und dann auf die Schnittstelle castest, dann würde ich das nicht als Verstoß bezeichnen. Aber was anderes: Wenn du wie svenson das vorgeschlagen hast Activator.CreateInstance benutzt solltest du a einen parameterlosen Konstruktor anbieten und b in der Datenbank nicht nur class_1, sondern den vollqualifizierenden Namen (d.h., incl. Assembly) speichern.
Wie wäre es mit
Select SignalID, AVG(Value) as Mittelwert From Tabelle Group by SignalID
Ich würd dir auch dringend empfehlen, Run() als virtual zu markieren, dann kannst du in abgeleiteten Klassen vielleicht noch andere schoene Dinge mit den Dateien machen als Diagnostics.Process.Start
Naja, was ist denn ueberhaupt ein Muss? Bestimmte Sachen kann man ausschliesslich mit Attributen machen, manche Sachen gehen damit einfacher. Wo zum Beispiel exzessiv Attribute verwendet werden (muessen) ist Entwurfszeitunterstuetzung, schreibst ein Steuerelement und moechtest, dass es genauso angezeigt wird, wie die .NET-Steuerelemente, oder ein Objekt, was du im Property Grid anzeigfen willst. Solche Sachen gehen (beinahe ausschliesslich) ueber Attribute. An der Stelle ist auch die Eigenschaft von Attributen wichtig, dass sie erst zur Laufzeit geladen werden, denn nur so ist es moeglich, dass die Beschreibungen und Kategoriebezeichnungen der Steuerelemente lokalisiert und nicht in Englisch geladen werden koennen.
//edit: Mist, zu spaet...
_Original von talla_ich glaube das Team macht seinen Job gut.
ich kann dem nur zustimmen. Und nur, dass es auch mal ein "normaler" User gesagt hat: Ich finde das, was herbivore in dem Thread gemacht hat vollkommen in Ordnung und kann auch den letzten Beitraegen von talla hier nur zustimmen.
@JuyJuka:
Da würde ich widersprechen wollen, Events kann prinzipiell jeder und alles an- und abmelden, nur eben halt alles einzeln, nicht "Mal ebene alle Abbonements weg!". Ich wuerde sogar sagen, dass man Handler, die auf private Methoden verweisen, auch extern wieder abmelden kann, dazu waere aber ein tiefer Eingriff in Reflection notwendig, aber es muesste gehen...
wenn das property auf readonly gesetzt ist, ist das egal, aber wenn du value zurückgibst, dann unterstützt dein Editor auch "normale" properties
Ja, stimmt. Ich meinte ja nur, dass das öffentliche "Ueberleben" von derartigen Seiten drauf hinweist, das so etwas grundsätzlich möglich ist, nicht von vorn herein illegal. Aber ist eigentlich Blödsinn, prinzipiell ist alles legal, es ist alles eine Frage der Abkommen mit den Betreibern, die benötigt werden. Ziehe meine Aussage zurück 🙂
Also allein die Existenz von Metasuchmaschienen (das was du da machen willst ist ja auch eine) weist eigentlich darauf hin, das es da keine generellen Urheberrechtsprobleme gibt, ich würde es aber trotzdem nochmal nochmal mit den einzelnen Anbietern abklären
Wenn ich dann ParameterInfo.DefaultValue aufrufe, bekomme ich immer System.DBNull zurück (auch bei boolean zum Beispiel).
Sicher System.DBNull? Nicht einfach nur null? Naja, egal, die Werte, die dem Konstruktor übergeben werden kannst du nur im Konstruktor selbst in dem Moment, wo er aufgerufen wird feststellen, oder was meinst du? Defaultwerte kriegst du genau so, wie du's gemacht hast. System.DBNull oder null zeigt wahrscheinlich an, dass es keinen Defaultwert gibt (wobei ich das Design unsauber finden würde, kann's grad nicht prüfen, hab kein VS auf Arbeit)
//edit: Nur mal so gefragt, was hast du den ungefär für eine Tippgeschwindigkeit, herbivore? Bist ja geschwindigkeitstechnisch gar nicht zu schlagen... 🙁
du musst an SetValue ja auch eine Instanz des Typs, nicht das Typobjekt, übergeben. Bei statischen properties müsste man den ersten Parameter gämzlich weglassen (null), der zweite Parameter ist immer der Wert und der dritte, ja, der dritte sind die Parameter für den Aufruf. Als C#er gibt es aber genau eine Art von parametrisierten properties, nämlich Indexer. Aber wenn du Code aufrufst, der e.g. in VB.NET geschrieben wurde, dann ist da tw. auch ein dritter Parameter notwendig.
SOA ist an sich auch ne tolle Sache, gerade auch so, wie es Microsoft bei den Entwurfszeitmustern durchzieht, aber so dokumentiert nuetzt das halt nicht allzu viel...
zum nick:
Woher kommen eure Nicknames?
aber langsam überlege ich, mir doch einen neuen nickname auszudenken oder zumindest mal n bild von mir reinzustellen...
Du hast einen Serviceprovider zur Verfuegung, der nur dazu da ist, dir Serviceobjekte wie dieses zu liefern. Entwurfszeitkomponenten, Designer und so'n Kram ist alles SOA, d.h., man muss im wesentlichen nur wissen, welchen Servicetyp man gerade braucht (und ob der Provider diesen liefern kann). Leider gibt es keine Moeglichkeit rauszukriegen, welche Servicetypen VS unterstuetzt. Aber ich meine, selbst wenn, dann setzt dir jemand eine andere IDE an den Code, e.g. #dev, die diesen Service vielleicht nicht unterstuetzt, und sch wars. Lieber immer pruefen. Aber das hast du ja im Fall des IWindowsFormsEditorServices auch gemacht 🙂
Ich wuerde es auch erstmal, wie Qwald schon gesagt hat, mit Microsofts AntMe probieren. Da gibt es glaube ich auch neben den "normalen" AntMe Starterpacks auch ein Starterpack fuer welche wie dich, die in die managed DirectX-Programmierung einsteigen wollen.
Tu das nicht. Wenn du das tust, dann funktioniert es recht nicht mehr. lösche lieber den INHALT der Auflistung und dann fuege die Elemente einzeln neu hinzu. Das sollte funktionieren. So wie du es jetzt machst erstellst du eine neue Collection, und das ist mit readonly properties natürlich inkompatibel. Aber mir fällt grad ein, woran es liegt. Wenn du Aenderungen an einem Objekt durchfuehren willst, dann musst du das dem DesignerHost auch mitteilen, lass dir mal ein IComponentChangeService geben und benachrichtige den, wenn du die Collection loeschst und neu befuellst.
hast du auch in der property das DesignerSerializationAttribute auf Content gesetzt? Da würde ich das Problem vermuten...
Was herbivore meint, ist, dass du erstmal nach vorhandenen EventArgs-Klassen benutzen, und wenn du Ereignisdatenklassen von EventArgs ableitest, dann kannst du immer auch Generika verwenden, mindestens beim Delegate (EventHandler<T>)
sieht komplexer aus (ist es auch 🙂), aber ist auch deutlich leistungsfähiger, da du fuer die Implementierung einer neuen Methode die Methode nur erstellen musst und nicht dauernd was in der Switch-Anweisung machen...
Die Anforderungen erinnern mich ganz stark an die DockPanelSuite, ich glaub die steht unter LGPL...
wenn du weisst von welcher Klasse das eine statische Methode ist, bzw, auf welches Objekt du diuese Methode anwenden sollst, dann geht das.
richtig ne eigene Homepage hab ich nich, nur n Blog zusammen mit meiner Freundin, allerdings so ziemlich ohne auch nur der Erwähnung das ich mich jemals mit Programmieren beschäftigt hab...
wenn du nicht vor hast den Debugger zu benutzen, warum verwendest du ihn dann? Aendere mal die Konfiguration in x86, oder starte das Projekt ohne Debugger...
Ja, das sollte gehen, wenn du die selben Codedateien mit verschiedenen Projetdateien referenzieren. Dann musst du dann in den Compileoptionen der Projekte halt verschiedene Konstanten definieren...
Ich denk mir Klassendesign und Lösungen zu Architekturfragen beim Fahrradfahren aus und setze sie dann später um 🙂, entwickle momentan noch ausreichend wenig, dass das ausreicht...
ach ja, Namen des Threads aendern geht einfach, indem du den ersten Beitrag editierst...
sry ich meinte die ControlCollection der IBar, ja 🙂
Literatur gibts ganz wenig, stimmt 🙁 aber generell gibts dazu ein Beispiel von MS, TaskPane heissts glaub ich, hat mir seehr geholfen...
Nur wegen dem korrekten Namensgebrauch: Es handelt sich in diesem Moment dann nicht mehr um ein Control, sondern um ein Component. Component ist aber der generelle Oberbegriff fuer alle Klassen, die eine Unterstuetzung fuer Designer bereitstellen (e.g. VS WinForms Designer).
IDesigner ist ein Irrweg. Ueberschreib die ControlCollection von QuickBar, und ueberschreibe da die Add-Methode.
//edit: Mittlerweile waere es glaub'ich sinnvoll den Namen des Threads mal zu aendern, weil es so ueberhaupt gar nicht um automatische Namensvergabe geht...
Die Unterschiede sind tatsaechlich nur Feature vorhanden / nicht vorhanden. Bei vielen Sachen greift VS ja - sowohl Express als auch die anderen Versionen - auf externe Programme zurueck (e.g. csc) und die sind in jedem Fall gleich. Der Lieferumfang ist einfach groesser, es gibt eine PlugIn-Unterstuetzung, etc.
Das BrowsableAttribute ist das falsche Attribute, verwende stattdessen EditorBrowsableAttribute und setz den Wert am besten auf Advanced, damit man ueberhaupt noch rankommt, aber die auch ausblenden kann. Browsable wirkt sich nur auf die Darstellung zB im PropertyGrid aus.
ja, das hat etwas damit zu tun. Deine Aufzaehlung gibts du aber wahrscheinlich nur als readonly property nach außen, da verursacht
[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
natuerlich nur Fehler und wird nicht ausgefuehrt. Nimm stattdessen
[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
Visible ist die Defaulteinstellungen. Das .NET-Framework ist aber scheinbar nicht intelligent genug, readonly propertys standardmaessig mit Content zu behandeln, deswegen muss das bei jedem einzelnen readonly property hin.
Ich vermute mal, das ganze Problem ist, dass du die Location der neu hinzugefügten QuickBarItems nicht einstellt. Sie kommen alle, aber sind dann alle uebereinander
Ich glaube mit Activator.CreateInstance(..) schieße ich mit Kanonen auf Spatzen.
solange das aber so performante Kanonen sind ist auch das kein Problem. Im Gegenteil, dann ist es auch kein Problem, wenn sich die Spatzen noch zu ausgewachsenen Raubvoegeln entwickeln... 🙂
Wenn es einfach um die Darstellung von Zahlen geht (was potentiell sehr viele sein können): Ja 🙂, abhaengig vom Kontext der Formatierung kann es aber auch total unerwuenscht sein, "x Atome" zu schreiben. Wenn du in einem Steuerelement in einer Anwendung die Eingabe nur Zahlen etc. begrenzen willst wäre es von vornherein ausgeschlossen, dass da noch irgendwas anderes formatiert wird.
Auf der anderen Seite ist das weiß Gott kein komplizierter Parservorgang, der Performanceverlust ist dürfte also auch beim Formatieren von 10.000 Zahlen noch keinen Flaschenhals verursachen...
Insofern hast du Recht, zumal der Wartbarkeitsvorteil von String.Format u.U. recht groß ist. Hab halt noch nicht so viel Praxis 🙁
ich persönlich hege auch eine tiefe Abneigung gegen die Convert-Klasse, aber das ist quasi die Abkürzung, wenn du String.Format aufrufst, dann muss der Formatcode ja erst geparst werden - um die geparste Zeichenkette dann an Convert zu übergeben. Auch beim Aufruf von (int).ToString(formatcode), was meine persönlich bevorzugte Variante ist, geht der Aufruf intern an Convert...
Wozu willst du denn die Einträge sortieren?
Ich würde aber auf gar keinen Fall den Verbindungsstatus als Zeichenkette speichern, codier es lieber entweder fest (Enumeration) oder Variabel (Zahlen), wenn es nur zwei Zustände gibt und geben kann, wie es deine Beispiele vermuten lassen kannst du auch Booleans nehmen.
Insgesamt würde ich dir aber vorschlagen gleich eine komplett neue Datenstruktur für ein Telefon zu erstellen, dann kannst du auch Suchen implementieren wie "finde alle freien Telefone in meiner Abteilung". Dazu müsste aber gespeichert sein, zu welcher Abteilung das Telefon (oder vielmehr der dazugehörige Mitarbeiter) gehört (nicht nur die Rufnummer).
Im Zusammenhang mit Komponenten würd ich dir aber dringend von der Verwendung von Internal abraten, denn damit machst du dir alle Vorteile, die du mit (hoffentlich über Schnittstellen definierten) Komponenten erschlagen hast: Austauschbarkeit geht dann nur, wenn die neue Komponente auch im selben Projekt ist und das ist nicht Sinn und Zweck der Sache.
Nimm Events