@Lynix:

Hi Lynix!

Da hast Du mehr reininterpretiert, als was ich gemeint habe. Um das zu praezisieren: Mit Funktionalitaet meine ich grundlegende Dinge, wie bspw. eine einfache Multiplikation etc, die auch voellig legitim ist, diese in einem Property unterzubringen. Siehe hier z.B.: Properties (C# Programming Guide)

Gruss,
DaMoe

@Karill: Joerg hat schon Recht. MyMemoryStream wird nicht ausgegeben, sondern MemoryStream. Da Kann Joerg soviel casten wie er moechte.

Gruss,
DaMoe

Hi!

Du willst doch sicherlich den Typen im MemoryStream uebergeben, um auf der anderen Seite zu wissen, wie der XMLSerializer zu instanzieren ist? Ich habe Dein Beispiel ein wenig ueberarbeitet.

internal class Program
    {
        private static string myClipBoarData = "Test";

        [STAThread]
        public static void Main(string[] args)
        {
            SetData();
            GetData();
            Console.ReadLine();
        }

        private static void SetData()
        {
            var selControl = new MyControl { Test = "123" };
            var controlType = selControl.GetType();
            
            var ms = new MemoryStream();
            var serialOut = new XmlSerializer(controlType);
            serialOut.Serialize(ms, selControl);
            ms.Position = 0;

            var data = new Tuple<MemoryStream, Type>(ms, controlType);

            Clipboard.SetData(myClipBoarData, data);
        }

        private static void GetData()
        {
            var containsData = Clipboard.ContainsData(myClipBoarData);
            Console.WriteLine(containsData);

            if (containsData)
            {
                var data = (Tuple<MemoryStream, Type>)Clipboard.GetData(myClipBoarData);
                var serializer = new XmlSerializer(data.Item2);
                var control = serializer.Deserialize(data.Item1);

                Console.WriteLine(control.GetType());
                Console.WriteLine(((MyControl)control).Test);
            }
        }
    }

    public class MyControl
    {
        public string Test { get; set; }
    }

Gruss,
DaMoe

Ich danke Euch fuer Eure Meinungen. Ich sehe das aehnlich wie Ihr. Mein Vorgehen, welches Eure Ansichten widerspiegelt, sah und sieht bis jetzt folgendermassen aus: Verwende da, wo lediglich Werte fuer den inneren Zustand benoetigt werden, private Felder. Sobald ich mehr "Funktionalitaet" benoetige, wie z.B. Lazy Loader, Kalkulationen etc. verwende ich private Properties.
Den Hinweis von winSharp93 finde ich noch interessant, der Einheitlichkeit halber an gewissen Stellen, dann doch private Properties zu verwenden.

Ich nehme aus dieser Thread mit, dass es mehr Sinn macht ein Best Practice (Empfehlung) herauszugeben, es aber nicht in einer festen Regel zu verzurren.

Danke und Gruss,
DaMoe

Hallo *!

Wir haben in unserem Unternehmen ein Regelwerk etabliert, welches einem Entwickler aufzeigt wie dieser einheitlich Code entwickeln soll. Nun wird ueber eine Regel diskutiert, die ich momentan noch nicht vertreten kann:

1. Benutze keine privaten Felder, benutze private Properties stattdessen
2. Ausnahmefaelle sind Lazy Loading, NotifyPropertyChanged und Marshalling
3. Wenn Du private Felder verwendest, dann duerfen diese nur ueber die entsprechenden Properties angesprochen werden.

Mich interessiert Eure Meinung dazu. Findet Ihr so eine Regelung sinnvoll?

Meiner Meinung nach schafft man durch die obige Regel explizite, private Felder mehr oder minder ab. Ohne Euch zu stark zu beeinflussen, ist ein Argument der Befuerworter, dass einige Entwickler mal die privaten Felder und dann mal wieder die Properties ansprechen, wodurch natuerlich Fehler entstehen koennen, weil bspw. durch den Zugriff auf ein privates Feld eventuell gewisse Logik eines Properties umgangen wird. Man moechte nun erreichen, dass einheitlich ueberall da, wo es moeglich ist, Properties einsetzt und diese nur anspricht.

Gruss,
DaMoe

Hi,

Du musst schon spezifizieren, dass es sich um ein UiElement handelt. Ich meine, dass Du in etwa schreiben kannst:

Testprop="{Binding ElementName=Textbox1}"

Gruss,
DaMoe

Was meinst Du mit "Wenn ich die entsprechende Assembly aber aus den Verweisen entferne"? Meinst Du aus dem VS Projekt?

Handelt es sich bereits um eine Sprachen spezifische Assembly? Wenn ja, hast Du beachtet, dass diese in einem bestimten Verzeichnis liegen muss?

Gruss,
DaMoe

Moin!

Fehlt Dir eventuell das Namensattribut hier, damit das LoggingGrid identifiziert werden kann und nicht jedes Mal neu erzeugt wird?

Gruss,
Moe

Hi!

1. Sicherlich hast Du Recht, wenn Du sagt, dass das Binding durch die Verwendung von Strings nicht sonderlich robust gegen Refactoring ist. Die Add Methode des Klasse, die hinter dem Property DataBindings steckt, kann auch eine Instanz einer Binding-Klasse entgegennehmen. Wir haben diese Klasse abgeleitet und ermoeglichen nun durch die Verwendung der eigenen Binding-Klasse nicht string anzugeben, sondern mittels Lambda Expression direkt Properties zu definieren ( model => model.MyValue ), d.h. man uebergibt hier ein Delegate (eine Art Zeiger auf ein Property). Somit haben wir das Refactoring Problem an einer Stelle ausgemerzt.
   Natuerlich steht Dir frei eine Basis-Klasse zu definieren, die INotifyPropertyChanged direkt implementiert. Ausserdem hast Du Recht, dass man in den Settern das entsprechende Event feuern muss (wuerde das an dieser Stelle nur machen, wenn die Werte unterschiedlich sind, also vorher noch eine Ueberprufung auf Gleichheit durchfuehren). Auch hier gibt es Hilfestellung durch Tools wie PostSharp mit dem man durch Aspekte bzw. in CSharp mittels eines Attributs relativ schnell und einfach die entsprechende Modelklasse um das INotifyPropertyChanged Event und das dazugehoerige Aufrufen in den Settern der Properties erweitern kann. Letztendlich ein bisschen Handarbeit muss getan werden.
   2.) Du setzt die 50 initial im Konstruktor, d.h. das Binding liest den Wert initial aus und stellt diesen in der ProgressBar dar. Das ist soweit klar. Mich wuerde aber wundern, ohne INotifyPropertyChanged implementiert zu haben, wenn die ProgressBar sich aktualisiert nachdem Du den Wert in der Textbox aenderst. Das kann nicht funktionieren. Aussderm wundert mich eh, dass Du zum einen den Text auf Name gebunden hast, in dem TextChanged Event jedoch den Text auf int parst und auf MyValue setzt.

Gruss,
Moe

Hi ppppp,

Du musst in der MyDataModel Klasse das INotifyPropertyChanged Interface implementieren, ansonsten bekommt die UI nicht mit, dass sich etwas veraendert hat.

Ausserdem kannst Du den Code im Konstruktor noch vereinfachen

progressBar.DataBindings.Add("Value", myDataModel, "MyValue");
progressBar.DataBindings[0].DataSourceUpdateMode = DataSourceUpdateMode.OnPropertyChanged;

nach

progressBar.DataBindings.Add("Value", myDataModel, "MyValue", DataSourceUpdateMode.OnPropertyChanged);

Die Add Methode hat naemlich noch weitere Ueberladungen.

Gruss,
DaMoe

Hallo und Herzlich Willkommen!

1. "Will nicht" ist keine sonderlich gute Fehlerbeschreibung. Du solltest schon ein wenig detailierter beschreiben, was nicht funktioniert.
2. Hast Du denn schon einmal geschaut, ob es vorgefertigte Libs gibt und wenn ja, dann kann man sich da sicherlich einige Dinge abschauen.

Gruss,
DaMoe

Moin!

Dann nimm doch fuer den Einstiegspunkt nicht Enum, sondern eine Klasse, also in etwas so:

public static class MimeTypes
{
  public static Audio Audio { get {...} }
  public static Image Image { get {...} }
}

public static class Audio 
{
     public static AllMimeTypes MPEG { get { return AllMimeTypes .AudioMPEG; } }
     public static AllMimeTypes WAV { get { return AllMimeTypes .AudioWAV; } }
}
 
public enum AllMimeTypes 
{
   // ...
}
 

Oder Du trennst Dein eigentliches MimeType Enum auf, aber das willst Du sicherlich nicht. Dann besteht natuerlich noch die Moeglichkeit, die MimeType durch Klassen/Structs und Interfaces darzustellen.

Gruss,
Moe

Hi!

SelectedPath loest eine Exceptin aus. Siehe auch FolderBrowserDialog.SelectedPath

Unter dem Punkt .Net Framework Security siehst Du, dass eine FileIOPermission ausgeloest werden kann.

Deine Exception besagt, dass die Zone "MyComputer" Probleme macht. Es scheint bei Dir eine Security Einstellung zu sein, die Dir Probleme bereitet.
Beschaeftige Dich ein wenig im dem Security Konzept von .Net 4.0.

Gruss,
Moe

Moin!

Hast Du einmal in die innere Exception geschaut, um Details zu erhalten?

Gruss,
Moe

Schau Dich mal hier um: Clean Code Advisors: Flow-Design Ressourcen

Wir haben mittels des Flow Designs (siehe auch den DotNetPro Artikel: Lass es fliessen) sehr performant und speicherschonend Filter auf GridViews anwenden koennen. Kann ich nur empfehlen.

Gruss,
DaMoe

Hi!

oder programmatisch Dateien aus TFS auschecken resp. einchecken

Hierzu wuerde ich mir das Team Foundation Server SDK anschauen

Gruss,
Christoph

Oder allgemeiner: AutoCompletion Dialog

Hi!

Es ist schwierig eine konkrete Zahl zu nennen. Ueberschlag doch einfach die Zeit, die Du fuer Deine Projektarbeit, die Dokumentation, die weitergegeben werden kann, und die Implementierung benoetigt hast. Schau Dir mal unterschiedliche auf dem Markt existierende Loesungen und deren Preis an, um einen Eindruck fuer einen Preis zu bekommen:

http://sharptoolbox.com/categories/licensing

Gruss,
DaMoe

@Herbivore: Ich weiss nicht worauf Du hinaus willst. Etwas anderes als in deinem zweiten Posting habe ich nicht behauptet. Wenn ich mal von "interne Klassen" gesprochen habe, war auch internal gemeint, was ich hauptsaechlich auch in meinem Beitrag verwendet habe. Ich habe somit auch auf nichts anderes angespielt als das, was dN!3L erwaehnt.

Ich habe mich vielmehr auf Folgendes bezogen:

Was nicht öffentlich ist, muss nicht (direkt) getestet werden. Es spricht sogar einiges dagegen, interne Methoden unitzutesten, insbesondere weil man dadurch die Freiheit, die Implementierung nach belieben ändern zu können, solange das Verhalten nach außen gleich bleibt, unnötig einschränkt.

Und das ist schon eine sehr absolute Aussage fuer mich und klingt fuer mich falsch bzw. eventuell in diesem Fall missverstaenglich. Was verstehst Du nun unter internen Methoden? Meinst Du "private" Methoden, die bspw. nun die Sichtbarkeit "public" besitzen?

Gruss,
DaMoe

Hallo zusammen,

Mit Unit-Tests testet man doch normalerweise sowieso nur, was schon öffentlich ist. Was nicht öffentlich ist, muss nicht (direkt) getestet werden.

Aber ich weiß nicht, ob man immer so viele interne Sachen testen muss.

ich kann mich meinen Vorrednern dahin gehend anschliessen, dass man interne Dinge nicht explizit auf public setzen sollte, denn dann zwingst du den Benutzer Deiner API mehr zu sehen und erschwerst eventuell das Erlernen Deiner API, weil man sich auf einmal mit viel mehr Dingen konfrontiert sieht, als notwendig. Das InternalsVisibleTo Attribut ist schon in Ordnung.
Nun aber zu dem Thema, ob man Dinge, die mit dem internal Keyword markiert sind, testen solle: Ich sage ja.
Wir brauchen uns nicht darueber zu unterhalten, dass public Konstrukte getestet werden muessen. Internal Dinge werden irgendwo implizit ueber die offentliche API abgetestet, allerdings wachsen interne Klassen auch und erreichen einen gewissen Komplexitaetsgrad. Es vereinfacht das Testen bzw. die Komplexitaet des eigentlichen Tests, wenn ich bestimmte Dinge der internen Klasse explizit in einer dazugehoerigen Testklasse teste. Die Tests werden uebersichtlicher und auch praeziser, denn man sieht direkt, dass mit der internen Klasse etwas nicht stimmt, wenn ein Test fehlschlaegt. Zudem wird die Spezifikation fuer die interne Klasse durch explizite Tests offensichtlicher gemacht.
Wenn neuer Code entsteht, gibt es eine offentliche API, die abgetestet wird. In nachfolgenden Schritten refactored man seinen Code, erstellt eventuell interne Klassen, um das SRP Prinzip besser zu beachten. Wenn die neu entstandene interne Klasse noch klein ist, dann moegen die Test ueber die oeffentliche API hinreichend sein. Ab einem bestimmten Grad allerdings nicht mehr. Somit sehe ich es als legitim an, explizit Test dafuer zu schreiben, sobald die interne Klasse komplexer wird, besonders wenn diese dann noch von anderen Klassen verwendet wird. Ich sehe auch, dass es noch mehr die Angst nimmt Aenderungen an so einer Klasse vorzunehmen. Es ist ein noch etwas feineres Sicherheitsnetz fuer den Entwickler, man kann sich explizit auf die interne Klasse fokusieren. In einem weiteren Schritt testet man dann die offentliche API.
Besteht der "internal" Code schon, dann mach es das Testen einfacher, denn hinter einer oeffentlichen API kann ein hoher Komplexitaetsgrad entstehen, der das Testen nicht gerade einfach gestaltet. So kann man sich sukzessive durch die internen Klassen bis nach oben zur offentlichen API arbeiten.

Gruss,
DaMoe

Hi CreamyCewie!

So wie Du fragst und Code postest, sieht die Frage danach aus, als ob Du eine fertige Loesung haben moechtest. Da wirst Du hier nicht weit kommen, zumal das gegen die Forenregeln verstoesst.

Mir scheint, dass Dir der gepostete Code vorgegeben ist?

Wie Du den Text ganz auslesen kannst, ist bereits in Deinem Code Beispiel implementiert, nur nicht komplett wie Du Dir das vostellst. Schau mal in die Methode ReadLine. Um Dir eventuell einen Denkanstoss zu geben wuerde ich Folgendes ueberlegen: Fueg eine weitere Methode hinzu, die aehnlich der ReadLine Methode arbeitet, aber wirklich die gesamte Datei einliest und jede Zeile bspw in einer String-Liste speichert und diese Liste zurueckliefert. Die UI kann ueber die Liste navigieren (Du merkst die bspw. einen Laufindex), wobei die Position in der Liste der Zeilennummer entspricht. Willst Du eine Zeile anzeigen, holst Du Dir anhand des Index eine Zeile aus der Liste, splittest den Strig anhand des Gleichheitszeichens mittels der String-Operation String.Split. Das Ergebnis daraus musst Du lediglich in der Ui visualisieren usw. Ich hoffe, dass das ein Denkanstoss fuer Dich war.

Das naechste Mal poste bitte vorher, was Du Dir fuer Gedanken gemacht hast ueber Ablauf, eventuell Pseudo Code, damit man auf dieser Grundlage diskutieren kann.

Gruss,
DaMoe

Hi brev,

auf der MS Seite, kannst Du im oberen Bereich stets die Dokumentation fuer das entsprechende Zielframework einstellen, sodass du die folgende Seite erhaelst:

CodeDomProvider-Klasse .NET Framework 4

Der Tod von Steve Jobs ist wirklich tragisch. Er hat die Computer Welt massgeblich beeinflusst und gepraegt. Hut ab vor seiner Leistung.

"Die Welt ist wegen Steve ein besserer Ort."

Soweit wuerde ich persoenlich nicht gehen und kann mich dieser Aussage nicht anschliessen.

Gruss,
Moe

Hi Steven!

Such ein wenig in unserem Forum, dieses Thema wurde des oefteren besprochen. Auch findest Du relative schnell mit den Stichworten "c# write excel without installation" unter Google so einige Treffer.

Schau mal hier. Vielleicht bringt Dich das weiter.

http://www.aneef.net/2008/07/25/create-excel-sheets-programmatically-with-c-without-installing-excel/

Gruss,
Moe

Keine frei Bibliothek, aber enthaelt, was Du benoetigst: DevExpress

@progi123:

...mir hat sich gleich die Frage gestellt, ob Du Dir dessen im klaren bist, dass UDP kein zuverlaessiges Protokoll ist,....

Hi!

Ich habe den Eintrag nur ueberflogen, und mir hat sich gleich die Frage gestellt, ob Du Dir dessen im klaren bist, dass UDP kein zuverlaessiges Protokoll ist, d.h. Du Nachrichten wohl verlieren kannst. Eine fehlerhafte Uebertragung kann man mit einer sogenannten Integritaetspruefung erkennen. Kann es nicht sein, dass Dein Problem in UDP begruendet ist, das es keine Ubertragungsgarantie gewaehrleistet?

Gruss,
Moe

Hi!

Mich interessiert hier an dieser Stelle, ob die Eintraege eindeutig identifizierbar sind bzw. wie identifizierst Du einen Eintrag, der in Tabelle A geaendert wurde in Tabelle B? Kommt eine Beschreibung immer nur einmal vor?

Ich sehe die Moeglichkeit hier, dass Du Dir eine Klassenstruktur aufbaust, die Deine Daten haelt: Erstelle zwei Klassen, wobei die Klasse A der Struktur der Tabelle A entspricht, passend dazu Klasse B und nun die ensprechenden Instanzen von Klasse A und B sich kennen, oder sich ueber Aenderungen notifizieren (Stichwort: INotifyPropertyChanged), damit die Klassen keine konkreten Abhaengigkeiten zueinander besitzen.
Ich kann mir auch eine Assoziationsklasse zw. A und B Vorstellen, die zudem die Synchronization uebernimmt. Das erkaufst Du Dir natuerlich mit je einem zusaetzlichen Objekt pro Zeile.

Es gibt unterschiedliche Moeglichkeiten, eine absolute Antwort kann ich Dir momentan nicht geben (Dazu fehlt mir die Info, wie Du die Datensaetze korrelierst; siehe initiale Fragen). Die Find Methode ist hier sicherlich die schlechteste Wahl.

Gruss,
DaMoe

Hi!

Was funktioniert denn nicht? Gut, Du hast jetzt eine statische Methode, aber davon abgesehen ist Dein Vorgehen Usus in .Net.

By the way: Klassennamen fangen in C# mit einem Grossbuchstaben anfangen, genauso wie Methodennamen.

Gruss,
Moe

Hi!

Schau mal hier in diesem Beispiel von Microsoft, ob Du mit dem Border Property etwas anfangen kannst. Das Border Property ist in dem Beispiel in der Klasse Excel.Range verfuegbar, aber eventuell hilft es Dir weiter.

Microsoft Excel mit Microsoft Visual C# .NET automatisieren

Gruss,
Moe

Moin!

Es sollte funktionieren. Ich tippe mal und sage: Setz mal die Variable kunibert vorher explizit auf null.

Nachtrag: So wie Du es in Deinem Beispiel aufgefuehrt hast, sollte es kein Problem sein

  
Elefant kunibert;  
 kunibert = new Elefant() { Name = "Kunibert", Ohrengröße = 81 };  
  

Hast Du vielleicht folgendes Konstrukt:

Elefant kunibert;

if(someCondition)
{
 kunibert = new Elefant() { Name = "Kunibert", Ohrengröße = 81 };
}

return kunibert;

Gruss,
Moe

VS 2010 oder 2008?

Fuer 2010 gibt es eine Extension, die glaube ich etwas Aehnliches was Du benoetigst, leistet. Ich finde diese Extension momentan nicht. Schau Du mal in der VS Gallery, ob Du etwas findest. Sollte ich die Extension wiederfinden, melde ich mich.

Gruss,
Moe

Hi!

Die Liste muss nicht von DependencyObject ableiten, dafuer gibt es wie mein Vorredner gesagt hat, ObservableList<T> bzw. BindingList<T>.
Deine Elemente bzw. die eigentliche Klasse sollte von DependencyObject ablgeiten.

Gruss,
Moe

Hi!

Es ist schwierig zu sagen, was Dein Problem ist, da der Kontext fehlt.

Hilft Dir vielleicht der folgende Eintrag auch weiter? Kommunikation 2 Forms

Gruss,
Moe

Hi!

Leitet Deine Datenklasse von DependencyObject ab?

Dependency properties can be implemented only on objects that derive from the
DependencyObject
class. All WPF elements derive from DependencyObject. If you want
to implement dependency properties on a custom class, the class must inherit from
DependencyObject.

Aktualisierung von UI, wenn sich die BL aendert, funktioniert ueber INotifyPropertyChanged (WinForms bzw. wird auch von WPF verwendet). Mach Dich mal in dieser Richtung schlau.

Gruss,
Moe

Das macht der GarbageCollector von alleine

Diese Aussage trifft in den meisten Faellen zu, allerdings entbindet es nicht sich Gedanken machen zu muessen, welches Objekt A auf welches andere Objekt B referenziert und somit die Lebensdauer des Objekts B beeinflussen kann.

Hi medi,

um die Speicherbehandlung kuemmert sich in .Net der GC, in Deinem Bsp. eo auf null zu setzen bewirkt an dieser Stelle nicht viel bzw. heisst nicht, dass das Objekt sofort abgebaut ist (kann sich eher auf die Lebenszeit der Objekte negativ auswirken, weil die Variable sich zu einem spaeteren Zeitpunkt, auch wenn sie auf null gesetzt wird, im Zugriff befindet; Stichwort: GC, Generationen). Das bestimmt lediglich der GC, der, vereinfacht gesagt, schaut, ob irgendwer noch Referenzen auf Objekte besitzt und wenn dies nicht der Fall ist, diese selbstaendig abbaut. Aus dem kurzen Konstrukt, dass Du gepostet hast, faellt mir auf, dass Du in jeder Iteration ein Object von EigenesObject generierst und anschliessend die Methode "macheVieles(...)" mit Parametern aufrufst. Das schaut merkwuerdig aus, ich stelle mir direkt die Frage, was passiert in der Methode? Warum wir immer ein neues Objekt erzeugt von der Klasse EigenesObject? Dein Code deutet darauf hin, dass die Parameter, die Du uebergibst irgendwie in der Instanz der Klasse EigenesObject verwendet werden. Kann es sein, dass die Parameter eine etwas laengere Lebensdauer haben? Meine Vermutung ist, dass irgendwie eine Referenz auf jede Instanz der Klasse EigenesObject in der Methode macheVieles aufgebaut wird, wodurch der GC die Objekte nicht abraeumt.

Gruss,
DaMoe

Hi,

die Fehlermeldung sagt Dir schon, was eigentlich falsch ist:

objPresSet.Open(...) gibt Dir ein Object von Typ Presentation zurueck, dass du auf eine Variable vom Typ Application (PView) setzen moechtest. Da du das direkt zuweist, also PView = ... ist das ein implizierter Cast, der nicht moeglich ist.

Gruss,
Moe

Hi,

Und im 70-511 Training verwenden sie beinahe alle paar Seiten andere Konventionen lach.

Ich verstehe es nicht, warum das MS zulaesst, aber mir ist der Umstand eines schlecht formatierten Codes in den MCTS Buechern auch schon aufgefallen, werden doch bspw. Klassennamen in C# mit Kleinbuchstaben geschrieben (in dem Buch) und sind somit teilweise nicht mehr von Variablennamen zu unterscheiden (in einigen Bsp.). Du darfst, was es die Formatierung angeht, die MCTS Buecher fuer C#/VB.Net nicht als Referenz nehmen (schon ein wenig traurig).

Gruss,
Moe

Hallo!

Hast Du mal geschaut, woher Deine Assemblies geladen werden? In dem Menu Eintrag Debug->Windows->Modules (habe nur das englische VS hier), findest Du eine Liste der geladenen Assemblies. Schau mal da nach, wo der Debugger die PDBs sucht bzw. kannst du dort auch explizit angeben, woher die PDBs kommen sollen.
Ausserdem kann u.U. die Einstellung Tools->Options->Debugging-> Enable Just My Code (Managed Only), wenn diese aktiviert ist, zu Problemen fuehren, wenn man in "fremden" Code debuggen moechte, fuehren. Probier etwas herum.

Gruss,
Moe

Hi,

die Messung der Zeit ist eine Sache fuer sich. Dein Betriebsystem ist kein Echtzeitsystem. Such mal hier im Forum, das wurde des oefteren schon erlaeutert. Hierzu ein Post von vielen:

Timer zu langsam

Stichworte hierzu: Echtzeit, Zeit messen, Timer

Gruss,
Moe

Schau mal hier in der MSDN:
Control.DataBindings Property

Control.BindingContext Property

Gruss,
Moe

Hi!

Du kannst am besten in A einen entsprechenden Konstruktor bereitstellen, der ein existierendes A uebernimmt und die Werte setzt. Da derjenige, der A pflegt, programmiert, etc. am besten weiss, welche Werte zu setzen sind bzw. bei Aenderungen, wie dazukommende Properties, auch in A das Setzen der Werte direkt anpassen kann.

Natuerlich muss B dann entsprechenden Konstruktor abieten (siehe Vorpsoting) und A weiterreichen.

class B : A
 {
     public B(A a) : base(a)
     {
     }
 }

Gruss,
Moe

Hi!

Schau mal hier: DataGrid Class

Kann es eventuell sein, dass Dir das Binding in den Spaltendefinitionen fehlt wie in dem Beispiel unter dem von mir geposteten Link zu sehen ist?

Gruss,
Moe

Moin!

Schau Dir mal System.Windows.Forms.RichTextBox an bzw. wenn es auch etwas Kostenpflichtiges sein kann, dann schau mal bei DevExpress nach.

Gruss,
Christoph

Hi LatinChriz!

Bei den MCTS Pruefungen habe ich die Erfahrung gemacht, dass man zum einen die Lern-Fragen gut beantworten sollen koennte sowie die auf der beiliegenden DVD befindlichen Pruefungsfragen (wobei diese wesentlich naeher an den Preufungsfragen sind, als die Lernbuchfragen). Braindumps, wie mein Vorredner bereits gesagt hat, sind auch eine gute Idee und solltest Du eventuell im Internet finden.

Wenn du dir dennoch unsicher bist, dann nimm einen Second Shot dazu

Sehe ich eher als eine falsche Herangehensweise an. Man sollte sich sicher sein, wenn man die Pruefung antritt. Leider sind die Pruefungen sehr "amerikanisch": Multiple-Choice Fragen, die viel konkretes Spezialwissen abgefragen, das man einfach auswendig lernen muss. Meine Erfahrung ist, dass dabei eher weniger Transferleistung zu leisten ist.

Gruss,
Moe

Hi,

ich habe selber einmal nachgeschaut und habe keinerlei Einstellungsmoeglichkeit gefunden, den Beschreibungstext aus bzw. einzublenden. Kann es allerdings sein, dass dein PropertyGrid nicht wirklich komplett angezeigt wird, wenn ich mir so Deinen Screenshot anschaue? Es sieht so aus, als ob Dir etwas vom unteren Teil der PG fehlen wuerde.

Gruss,
Moe