Suchergebnisse

wenns um das Kartenspiel geht, könntest du u.U. auch in Erwägung ziehen, dich doch nochmal mit OwnerDrawing zu beschäftigen. Oder anders: Erzähl mal bischen ausführlicher, was du machen willst, und welchen Sinn das haben soll.

nee - ausgezeichnete Beschreibung! Du glaubst garnet, wie schwer sich Progger gewöhnlich damit tun, ihre Absicht zu beschreiben - die verzetteln die sich immer in Pictureboxen, Textboxen, Events und wasses alles gibt. Also ich krieg auf die Frage ganz oft ausführliche Beschreibungen der mutmasslichen Mittel, aber das Ziel wird dabei kaum klarer (und die angedachten Mittel mögen ja höchst ungeeignet sein). Also beim OwnerDrawing hättest du eine Figur-Klasse, die sich selbst zeichnet. Die könnte e…

aber das ist im Projekt doch gezeigt. naja, nun grad nicht mit Bitmaps, also statt e.Graphics.DrawPath(...) musste halt hinschreiben e.Graphics.DrawImage(...). Guck dir die Graphics-Klasse auch im ObjectBrowser an - die bietet im wesentlichen alle Zeichen-Möglichkeiten. ObjectBrowser kennste? sonst VisualStudio richtig nutzen

Das ist eine Paint-Methode. Sie painted eine String, in zeile#11. Von der Signatur her ("Signatur": Grundlagen: Fachbegriffe) ist die Methode geeignet, das Paint-Event eines beliebigen Controls zu empfangen. Der Text wird zentriert geschrieben ins Rechteck 10, 10, 732, 160 Aber warum beschäftigst du dich mit Schnipseln, zu denen du kein lauffähiges Projekt hast, anstatt die Projekte anzugucken, die ich dir verlinkt habe?

Beantworte du mir erst meine Frage aus post#9

Inhaltlich ist die Methode ok - bis auf die Kleinigkeit, dass in jedem Aufruf ein neues StringFormat erzeugt wird. Stringformat ist IDisposabel, also entweder solltest du nur ein einziges erzeugen, und immer wiederverwenden, oder du musst es jedesmal disposen. Ich bin für ersteres, denn Paint-Methoden sollten möglichst schnell sein. Dasselbe gilt noch mehr für den Font. Font ist eine ziemlich fette Struktur. Nicht erkennen kann ich, ob dieser Eventhandler überhaupt ein Event empfängt.

sieht so aus, als proggst du noch strict off. Dann wäre Visual Studio - Empfohlene Einstellungen dringendst geboten. Danach kann ich zu obiger Funktion noch was ablassen, aber die Umstellung auf strict On dauert - wenn sie erst spät erfolgt - manchmal auch was länger.

keine Ahnung, von welcher Funktion wir nun sprechen. Das Gezeigte jdfs. dürfte unter Strict On nicht kompilieren.

ah, ok. nun Frage: Was bezweckt diese Endlosschleife? VB.NET-Quellcode (3 Zeilen) ah - schon verstanden: infoboard.Dispose() soll nicht erreicht werden. Aber dann lösch doch einfach die zeilen #19 - #23 - damit erreichst du dasselbe Ziel, und sparst jede Menge Rechner-Resourcen. Noch weiter gedacht könnte die ganze Methode weg - eine Picturebox kannst du besser im Form-Designer aufs Form machen, inklusive aller Einstellungen, die dein Code zeigt.

du könntest auch einfach Picturebox.Show/.Hide machen.

ich weiß nicht, was welche diese Sachen sind. Zumindest ein Brenn-Bildle über eine Karte legen geht mit OwnerDrawing sehr gut. Auch Karten überlappend anzuzeigen ist kein Problem. Ebenso Karten auch garnet anzuzeigen, oder verdeckt - falls sowas auftritt.

Zitat von Schmandal: „Wenn ich Deine und Rods Beiträge richtig verstanden habe, ist die Paint Methode wohl nicht die beste Lösung sowas zu realisieren.“Versteh ich nicht. Die Paint-Methode - also die Behandlung des Paint-Events ist der Kern des OwnerDrawing-Ansatzes. Und den OwnderDrawing-Ansatz halte ich für den besten. Ist zunächstmal anspruchsvoller zu programmieren, aber das naive "picturebox hinmachen, picturebox wegmachen" zieht allerlei Folge-Probleme nach sich, die sich bei OwnerDrawing …

eine ganz komische Methode hast du da. Die Karten-Images werden durlaufen, und jedes KartenImage zeichnet sich selbst in sich selbst?

naja, wenn du Karten-Objekte hast, die sich selbst zeichnen, könnte man denen eine Property IsHovered angedeihen lassen, dann zeichnen die sich bisserl größer. (mir ist, als hätten wird das Thema so ähnlich schon mal gehabt)

Du solltest es einfach mal machen. Programmier eine Karte-Klasse, und gib ihr die notwendigen Properties. X, Y, Bounds (Abmasse), IsBurning, IsHovered, IsSelected, IsAufgedeckt etc pp. Deine Fragen beantworten sich dann tw. selber, etwa die Frage "Wie kann ich zu einer bestimmten Karte ohne die Bilder durchzugehen, denn wissen bei welchen Koordinaten diese liegt?" - Koordinaten werden zB mit X,Y angegeben. Zitat von Schmandal: „Wie vollziehe ich bei dem oben genannten Beispiel den Aufruf der Sub…

Zitat von Schmandal: „Nun weiß ich gerade einfach nicht, wie ich mit dem Paint-Event weitermachen soll,“poste einfach den Code deines PaintEventHandlers - da kann man doch eine Schleife reinschreiben, wo die DrawMe-Sub aller Karten aufgerufen wird.

ist doch super-trivial:VB.NET-Quellcode (8 Zeilen)

jo, ich nahm auch an, dass MyCardImages eine Liste deiner Cards-Objekte ist, und nicht eine Liste von Images. Du wirst doch eine Liste von Cards-Objekten haben, oder ? Weil wenn du keine hast - wie sollen die sich dann selber zeichnen?

Was heisst "scheint" ? Gibt es sie oder nicht? Wenn nicht, dann stimmt was nicht mit deiner Zeichen-Routine. setz mal einen Haltepunkt in die Schleife, und geh die Geschichte im Einzelschritt durch.

Zitat von ErfinderDesRades: „setz mal einen Haltepunkt in die Schleife, und geh die Geschichte im Einzelschritt durch.“

also mir ist deine Zeichenmethode suspekt:VB.NET-Quellcode (6 Zeilen)Wo kommt standardx, standardy her, und enthalten die sinnvolle Werte? Also befindet sich das Rechteck überhaupt im sichtbaren bereich der TabPage, und ist es größer als mw. 20 Pixel? und die Graphics-Konfiguration muss nicht jedesmal neu gemacht werden, sonder wie ich gezeigt: Einmal, vor der Schleife im Paint-Event, dann sind sie konfiguriert die Graphics.

Zitat von Schmandal: „Und das andere Late Binding Problem habe ich mit einem Linq.Jarray gelöst, wobei ich nicht genau weiß ob ein anderer Weg besser gewesen wäre?“hab ich was verpasst - was war das andere LateBinding-Problem? Königsweg, um LatebindingProbleme zu lösen ist, die Datentypen so zu wählen, dass sie auch zueinander passen, und dass nur Member aufgerufen werden, die auch existieren. Was ist dieses directwr für ein Ding?

doch. Ist eine Architektonische Frage. OwnerDrawing mit Figuren, die sich selber zeichnen ist vonne Code-Aufteilung her recht optimal: Das Zeichnungs-Gefummel mittm Graphics ist in der Figur angesiedelt, sodass die PaintEvent-Methode der Owner-Klasse die Figuren durchnudeln nur noch muss. Das ist deshalb sehr schön, weil die Owner-Klasse ist meist eh voll mit allem möglichen, da ist man für jedes Stückerl Code, was man auslagern kann, dankbar. Du aber willst nicht, dass die Figur selbst weiß, wo…

Ich gehe von meim Vorschlag auch wieder ab. Also vergiss ihn. Eine Figur muss ja jederzeit auch ihre Abmasse angeben, und dazu ist unverzichtbar, dass sie ihre Position kennt, also selbst kennt. Also entweder eine Property Location as Point oder halt die Props X, Y. Was du machen kannst, ist, deine Karten in einer ObservableCollection(Of Card) zu halten, und deren CollectionChanged-Event zu überwachen. Und immer wenn die Collection changed, dann berechnest du die Locations der Karten neu und wei…

Einfach alle Karten der Hand durchrechnen. Ist viel Arbeit, und die viele Ergebnisse erbringen auch gar keine Änderung, aber die Arbeit macht ja der Computer. Und wie gesagt im CollectionChanged - da halt eine Schleife, und die Rechnet die Locations - ich sehe da kaum mehr als 10 Zeilen Code, und es ist abgehandelt. Was du mit Modulo, Reihen, und 20 Decks hast, dem kann ich nicht folgen. Aber das ist alles endlos viel Gerede, und nirgends Code zu sehen. Statt zu programmieren scheinst du ständig…

Imo weniger eine Frage von Vor- und Nachteilen. Weil imo sollte auch wenn du eine Kartenstapel-Klasse einführst, die Karten darin in einer ObservableCollection(Of T) gehalten werden, nicht in einer List(Of T). Weil List(Of T) hat kein CollectionChanged-Event.

ja, man kann auch sone Art ObservableCollection selbst erfinden. Geht aber bisser in Richtung "das Rad neu erfinden".

Tja, @Schmandal': soviel zu Vor- und Nachteilen: Der eine findets besser, eine Extra-Klasse zu erfinden, der andere empfiehlt, mit den Klassen umgehen zu lernen, die's schon gibt. Ergebnis wird dasselbe sein.

sieht so aus, als haben die Karten immer einen X-Abstand von 10. Da könnte man eine For-Schleife anbringen mit Step 10, und feddich. VB.NET-Quellcode (3 Zeilen)sorry - mir ist das super-trivial - ist dir das so schwierig?

Dann guck nochmal das StoryCard-Projekt an. Jede Karte bewirkt bei Änderungen ihrer Optik 2 Invalidates. Dabei wird nicht das ganze Control invalidiert sondern nur die Fläche der Karte. Und zweimal wird invalidiert, nämlich einmal vor der Änderung und einmal danach. Das vor der Änderung invalidieren ist erforderlich, um die Löschung der vorherigen Zeichnung zu bewirken. Ist klar - im MouseMove immer das ganze Control invalidieren tut weh. Das Konzept von Ownerdrawing ist, nur dann zu invalidiere…