Hi.

Wie man etwas auf die Form zeichnet weiss ich:



Nun wollte ich dieses mal via SUB machen:



Doch rufe ich diese so auf:

Zeichnet er garnichts auf die Form.

Warum?

Danke.

Mfg. TGS

In deinem Code sind gleich einige Fehler, allerdings brauche ich keinen davon zu berichtigen, denn man zeichnet nicht außerhalb des Paint-Events. Es gibt keinen Grund, dies zu tun, du brauchst also gar nicht zu versuchen das zu begründen.

TheGameSiders schrieb:

Wie man etwas auf die Form zeichnet weiss ich

Offensichtlich nicht.
Das geht nämlich so:
Es gibt auch ein e.Graphics.DrawImage() mit 30 Überladungen, da musst Du Dir das richtige raussuchen

Artentus hat revht. Zeichne im Paint Event und pfusche nicht mit Bitmaps oder Creategraphics rum. Wenn du dir jetzt denkst aber wie soll ich das mit den Events dann machen (Zeichnen bei Event) sag ich dir das du Invalidate verwenden kannst

Das Problem mit dem Zeichnen außerhalb eines Paint Events kann ich verstehen.
Wenn du zb in dem Paint Event viel (sehr viel) zu zeichnen hast, ist es oft nicht so gut, nur wegen einer Kleinigkeit, Alles mit invalidate neu zu zeichnen.

Es ist aber leider die einzig akzeptable Möglichkeit. Dinge, die außerhalb der Paint-Events gezeichnet werden, sind nicht konsistent, d.h. sie verschwinden ganz schnell wieder. Außerdem ist das Erstellen eines Graphics-Objektes auch nicht ganz unperformant und DoubleBuffer gibt es z.B. nicht.
Wenn man wirklich so viel zu zeichnen hat, dass es laggt, dann sollte man nicht GDI+ verwenden, sondern für Spiele DirectX und für GUIs WPF.

Ich hoffe das ist ein schlechter Witz/vertipper. Du übergibst als Parameter nicht wirklich Strings?! Falls doch, dann:
Option Strict On !!!!

Und: klar zeichnet er nichts auf die Form, es zeichnet ja auf die Bitmap. Wenn du auf die Form zeichnen willst arbeite im Paint-Event. Zeichnest du auf eine Bitmap, dann zeichnest du eben auf die Bitmap aber nirgends anders hin.

@Linux13524
Tja, das läuft dann darauf hinaus, dass du dein Paint-Event bzw die darunter liegende Klassenstruktur nicht anständig gecoded hast. .invalidate() hat nämlich Überladungen wo du den neuzuzeichnenden Bereich übergeben kannst. Das bringt schon etwas mehr Performance. Wenn du es 100%ig machen willst kannst du deine Objekte ganz gezielt neuzeichnen: einmal den alten Bereich des Objekts und einmal den Neuen. So wird nichts zuviel gezeichnet und lässt sich mit GraphicsPaths machen. Suche mal nach 'gezieltem OwnerDrawing' vom ErfinderDesRades, der hat das besser erklärt als ich. In meinem GDI-Tutorial ist das+Links auch zu finden^^
lg

@Artentus
Stimmt. So ein Problem, dass die Sachen irgendwie verschwinden hatte ich auch mal. Daraufhin hab ich dann doch wieder alles in das Paint Event.

FreakJNS schrieb:

.invalidate() hat nämlich Überladungen

Mist!
Warum hat mir das nie jemand gesagt
Ich werd mir das mal genau anschauen.

@TheGameSiders: Ist Dein Problem inzwischen gelöst?

RodFromGermany schrieb:

@TheGameSiders: Ist Dein Problem inzwischen gelöst?

Danke, aber wenn man es nicht ausserhalb des Paintevents machen kann/soll, hat sich das ja erledigt ~unmöglich~.

Trotzdem danke

Mfg. TGS

Da wüsste ich zu gerne warum das unmöglich sein soll. Wenn du etwas auf die Form zeichnen willst geht das Paint-Event IMMER (oder bring mir ein Gegenbeispiel). Das du im Paint-Event arbeiten musst heißt btw nicht, dass du keine anderen Methoden aufrufen darfst. Wichtig ist, dass du nur auf das Graphics-Objekt vom Paint-Event zeichnest (=> e.Graphics), dieses also ggf als Methodenparameter weiterreichst.

Also unmöglich ist es nicht. Du sollst es halt einfach nicht machen. Der Code wäre so:


Aber wie FreakJNS schon sagte: Nimm das Graphic-Objekt vom Paint-Event.

@Linux13524
FromHwnd ist afaik genau das gleiche wie .createGraphics, nur, dass du auf einen beliebigen Fenster-Handle zeichnen kannst. Ich wüsste nicht, warum man überhaupt mit .createGraphics zeichnen sollte (.fromHwnd schon, aber nicht, wenn man es wie creategraphics benutzt).

Also einfach das GraphicsObjekt aus dem Paint-Event nehmen und weiterreichen.

FreakJNS schrieb:

Also einfach das GraphicsObjekt aus dem Paint-Event nehmen und weiterreichen.

Genau. Das ist der beste Weg zu zeichnen.

Im Paintevent zu zeichnen ist keine Erfindung um dich zu ärgern sondern um zu helfen. Das System sendet eine Paint Nachricht an dein Fenster, wenn es neu gezeichnet werden muss. Dann wird sich der DeviceContext des Fensters gehohlt, damit ein Graphics-Objekt erzeugt und das Paint-Event gefeuert. Jetzt kannste einfach drauf loszeichnen. Beim Doublebuffering wird zuerst ne kompatible Bitmap erzeuigt und auf dessen DC gemalt anschließend wird der DC auf den DC der Form kopiert, so wird das Flackern vermieden. Nimmste jetzt Creategraphics wird der DC gehohlt und draufgemalt, da wird von Haus aus kein DoubleBuffer unterstützt. Der Nachteil ist entweder löscht das System das Gezeichnete, oder es ist absolut unperformant weils immer neu gezeichnet wird.

@Linux13524
Das klappt nun auf meinem Steuerelement wenn ich es so aufrufe:

Rufe ich es aber von einer anderen Form so auf:





Was ist daran wieder falsch?..

Danke

Mfg. TGS



EDIT: Hab vergessen das Bild in dem Ordner zu speichern.
So, nun kein Fehler, aber wieder erscheint nichts auf der Form sondern auf dem Steuerelement..

Was an zeichne im Paintevent verstehst du nicht ? Wir habens doch ziemlich ausführlich erklärt o. hast du noch Fragen ?

TheGameSiders schrieb:

Was ist daran wieder falsch?

Dass du nicht das Paint-Event verwendest.

^ this

mal davon abgesehen, dass man IN der Zeichenroutine nur zeichnen soll. Das Laden von Bildern gehört da definitiv nicht mit rein, dass muss vorher geschehen, weil es Zeitaufwändig ist. Ständige Plattenzugriffe sind langsam, und genau das tust du: bei jedem Neuzeichnen die komplette Grafik neu ladne. Wer sowas programmiert braucht garnicht mit Aussagen wie "GDI ist langsam" kommen.

Um es deutlich zu sagen: Der Code von Linux13524 ist Dreck! (ist nicht böse gemeint, wenn man z.B. auf fremde Programm-Fenster zeichnen wollte müsste man das so machen, aber hier NICHT).

Außerdem glaube ich so langsam, dass @TheGameSiders die Grundlagen der Programmierung von .NET mal wiederholen sollte. Ich habe das Gefühl, dass du da irgendwelche Aufrufe kreuz und quer machst ohne zu wissen wo vorne und hinten ist. Aber nochmal: Du willst etwas auf Form1 zeichnen, dann arbeite im Form1-Paint-Event. Du willst etwas auch Panel24 zeichnen, dann arbeite im Panel24-Paint-Event. Von dort kannst du dann hurr.durr.drawObject(e.graphics,eineBitmap,...) aufrufen, du siehst: Das Graphics-Objekt aus dem Paint-Event wird der Methode als Parameter übergeben, da ist kein CreateGraphics/FromHwnd/Blödsinn notwendig.

Weiterhin glaube ich, dass dir ein passendes Klassenkonzept fehlt. Methoden mit gefühlten siebzig Parametern sollte es nicht geben, denn ein OOP Konzept hätte eine Klasse ZeichenbaresObjekt, dass seine Position/Grafik/etc kennt und eine Methode .draw(g as graphics) wo es sich selbst auf das Graphics-Objekt zeichnet.

lg

Also als "Dreck" würde ich meinen Code nicht bezeichnen. Er ist halt nicht die Lösung des hier angesprochenen Falls, ist aber dennoch die Antwort auf die Frage des TEs.

@TheGameSiders
Bei .FromHwnd musst du das Handle des Objekts auf dem du zeichnen willst angeben.
Und deshalb ist es dann vorteilhaft, wenn du auf fremde Fenster zeichen willst (wie FreakJNS ja auch schon gesagt hat), aber nicht in deinem Fall.