Mit F5 starte ich das Debugging und erhalte folgende Fehlermeldung:
"TargetInvocationException wurde nicht behandelt"
Was mache ich falsch?
GRÜSSE, JOE
1. Normalerweise werden Zeichenfunktionen in einem OnDraw-Event
ausgeführt.
2. Deine Linie scheint mir ein Punkt zu sein (gleiche x- und
y-Koordinaten)
--jmp
Joe schrieb:> Sehe aber keine Linie.
Mit deinem Grid machst du ja auch nichts. Das wird gleich wieder vom
Garbage Collector gefressen wenn die Funktion verlassen wird. Klar dass
da nichts gezeichnet wird...
Joe schrieb:> Ich dachte, dass in folgender Zeile "myGrid" verwendet wird:>> myGrid.Children.Add(myLine);
Da steht:
füge die Linie zum Grid dazu.
Gut.
Aber was ist mit dem Grid selber?
Woher soll das Window wissen, dass du diesen einen Grid angezeigt haben
willst? Du kannst tausende Gridsd haben, jeder mit anderen Linien. Aber
welche davon sollen denn jetzt gemalt werden und welche nicht?
Joe schrieb:> Ist die verwendete Lösung sinnvoll
Nein. Das Konzept von WPF ist es Code und GUI zu TRENNEN. D.h. deine GUI
gehört in die XAMLs, der Code in die CSs. Das manuelle Zeichnen per Code
ist nicht sinnvoll.
Also wenn die Linie da immer gezeichnet werden soll, also quasi Teil der
Gui wird - dann gehört die in ein XAML Document, wird also nur
beschrieben. Wie
die dann gezeichnet wird, darum kümmert sich die Grafikengine, die dir
WPF freundlicherweise spendiert.
Gruß Jonas
Ich erhalte die Fehlermeldung:
Fehler 1 Für das nicht statische Feld, die Methode oder die
Eigenschaft "DrawSomeLines.MainWindow.DrawLine()" ist ein Objektverweis
erforderlich. C:\Users\tt.GD\Documents\Visual Studio
2010\Projects\DrawSomeLines\DrawSomeLines\MainWindow.xaml.cs 54 13
DrawSomeLines
Anscheinend kann ich aus einer statischen Methode keine nicht-statische
Methode aufrufen?
GRÜSSE; Joe
>Anscheinend kann ich aus einer statischen Methode keine nicht-statische>Methode aufrufen?>>Dir fehlen ganz klar die Grundlagen in C# und WPF.>>Die solltest du dir erstmal aneignen.
Gruß Jonas
>Timer myTimer = new Timer(3000);
Und wieder hast du den Timer in einem Event definiert, sobald das Event
abgearbeitet wurde frisst der GC deinen Timer...
Gruß Jonas
Mit diesem Beispiel versuche ich meine Grundlagen zu schaffen.
So falsch kann der Zähler nicht sein. Wenn ich statt des
DrawLine-Aufrufes
mir eine MessageBox anzeigen lasse, so klappt das auch im 3sec-Abstand.
Kann mir jemand erklären, was bei dem Aufruf von DrawLine() falsch ist?
GRÜSSE, Joe
Joe schrieb:> Mit diesem Beispiel versuche ich meine Grundlagen zu schaffen.>
Dann empfehle ich dir dringend den Ankauf von Literatur.
Du wirst hier im Forum niemanden finden, der dir einen 300 Seiten C#
Schmöker anlassbezogen vorbetet.
> So falsch kann der Zähler nicht sein. Wenn ich statt des> DrawLine-Aufrufes> mir eine MessageBox anzeigen lasse, so klappt das auch im 3sec-Abstand.
Das hängt ganz davon ab, wann der Garbage Collector dann irgendwann mal
das Timer-Objekt entsorgt.
> Kann mir jemand erklären, was bei dem Aufruf von DrawLine() falsch ist?
die Funktion ist static, gehört also zu keinem spezifischen Objekt,
sondern hängt nur allgemein so in der Klasse rum, damit sie im
Namensraum der Klasse existiert. Aber wenn sie aufgerufen wird, dann
wird sie nicht für irgend ein spezifisches Objekt aufgerufen. Ergo
kannst du auch nicht auf nicht-statische Dinge in deiner Klasse
zugreifen, denn die sind ja an ein einziges, bestimmtes Objekt gebunden
(jedes jemals derartige Objekt hat seine eigenen Satz an
nicht-statischen Variablen).
> • Wo würdest Du den Timer definieren?
Den Timer muss es geben, so lange es das Window gibt.
Genauso wie den Grid oder (bei dir momentan) die Linie.
Also: Wo und wie hast du den Grid und die Linie definiert bzw. erzeugt
und warum hast du das mit dem Timer nicht genauso gemacht?
Fehlermeldung: (*)
Der aufrufende Thread kann nicht auf dieses Objekt zugreifen, da sich
das Objekt im Besitz eines anderen Threads befindet.
GRÜSSE, JOE
Joe schrieb:> Der aufrufende Thread kann nicht auf dieses Objekt zugreifen, da sich> das Objekt im Besitz eines anderen Threads befindet.
Dann weißt du ja wo das Problem liegt und kannst es beheben.
Willst jetzt hier wirklich mit JEDEM Problem aufschlagen anstatt einfach
mal ein Tutoarial/Buch durchzuarbeiten?
Tja.
da wird dann eben wahrscheinlich ein Invoke fehlen.
Vielleicht verstehst du jetz schön langsam, warum die Methode 'Ich
probier einfach so lange rum bis xyz (zutreffendes einsetzen)' nicht
funktioniert. Es gibt hunderte (wenn nicht sogar tausende) Dinge, die du
wissen und beherrschen musst. Und nur wenn du alle beherrscht, dann
landest du auch bei einem sauberen Programm. Nur: woher sollst du denn
das alles wissen, was es zu beachten gilt? Eben. Du kannst es nicht
wissen. Aber dein Buch weiß es.
Hmmm, ok. Ich habe ein Buch: "Einstieg in Visual C# 2010"
Dort finde ich leider nicht viel zu WPF und auch nicht wie
ich Multi-Threading mache. Die Frage ist doch, wie kann ich obiges
Beispiel
sauber und simpel lösen. Wenn ich Schritte zur Lösung erfahre, dann
lerne ich
doch am besten oder nicht? Weil ich dann nämlich weiß, wie man es
richtig macht.
>Es gibt hunderte (wenn nicht sogar tausende) Dinge, die du>wissen und beherrschen musst.
JA, das gebe ich Dir Recht. Man muss aber am lebenden Beispiel erfahren
und lernen, was man alles falsch machen kann. Die Beispiele im Buch sind
immer
sehr simpel und funktionieren natürlich immer.
Grüsse, JOE
Joe schrieb:> Hmmm, ok. Ich habe ein Buch: "Einstieg in Visual C# 2010">> Dort finde ich leider nicht viel zu WPF und auch nicht wie> ich Multi-Threading mache.
Ich kann mir nicht vorstellen, dass Invoke da drinnen nicht beschrieben
ist. Denn das, und das Zusammenspiel mit Delegates, braucht man
eigentlich alle Nase lang, wenn man C# mit .Net einsetzt.
Insofern hat das nichts mit WPF zu tun. WPF ist ja nur ein Framework,
welches dir eine bestimmte Organisation vorgibt. Die Basismechanismen,
wie die Dinge in C# funktionieren sind ja nach wie vor dieselben.
> JA, das gebe ich Dir Recht. Man muss aber am lebenden Beispiel erfahren> und lernen, was man alles falsch machen kann. Die Beispiele im Buch sind> immer> sehr simpel und funktionieren natürlich immer.
Die Beispiele schweben aber nicht im freien Raum, sondern sind in
Kapitel eingebettet in denen Erläuterungen stehen. Das wichtige sind ja
nicht die Beispiele, sondern dass man versteht, worum es im jeweiligen
Kapitel geht.
D.h. man muss so ein Buch auch durcharbeiten! Kapitel für Kapitel lesen,
darüber nachdenken was man gelesen hat, die Beispiele als Illustration
des gelesenen nehmen und im Idealfall dann auch ein wenig abwandeln bzw.
zur Selbstkontrolle selbst ein paar Beispiele dazu erfinden, wenn am
Kapitelende keine Übungsbeispiele angegeben sind.
Dann wird das auch was.
>Ich kann mir nicht vorstellen, dass Invoke da drinnen nicht beschrieben>ist. Denn das, und das Zusammenspiel mit Delegates, braucht man>eigentlich alle Nase lang, wenn man C# mit .Net einsetzt.
Zumindest im Stichwortverzeichnis finde ich "Invoke" und "Delegates"
nicht.
Joe schrieb:>>Ich kann mir nicht vorstellen, dass Invoke da drinnen nicht> beschrieben>>ist. Denn das, und das Zusammenspiel mit Delegates, braucht man>>eigentlich alle Nase lang, wenn man C# mit .Net einsetzt.>> Zumindest im Stichwortverzeichnis finde ich "Invoke" und "Delegates"> nicht.http://technet.microsoft.com/de-de/
Manchmal verstehe ich es nicht ... .