MouseEnter-Event für die grafischen Objekte eines selbstgezeichneten Forms?

Hallöchen,

konnte leider nix passendes zu meinem Problem finden.
Folgendes: Ich habe eine dynamische Anzahl an Bildern, die ich über GDI+ zeichne.
Ich möchte jetzt erreichen, dass wenn die Maus sich über einem der Bilder befindet sich die Hintergrundfarbe verändert.
Das Überprüfen der Mausposition und der des Bildes stellt kein Problem da, nur befindet sich die Überprüfung momentan im MouseMove-Event
und d.h. es wird jedesmal eine Schleife abgarbeitet und auf übereinstimmung geprüft.
Da die Bilderanzahl aber dynamisch ist, wird dies bei einer großen Menge an Bilder sehr problematisch,
von daher bin ich auf der Suche nach einer Art MouseEnter-Event für selbstgezeichnete Bilder oder einer passenden Alternative.
Ich hoffe mir kann geholfen werden 🙂

Mfg
Gumba

private void Form1_MouseMove(object sender, MouseEventArgs e)
        {
            for (int i = 0; i < images.Count; i++)
            {
                if (images[i].IsVisible(MousePosition))
                {
                    MessageBox.Show(i.ToString());
                    break;
                }
            }
        }

images -> List<GraphicsPath>

Hi,

ein MouseEnter für selbstgezeichnete Bilder gibt es nicht. Hast du da Performance-Probleme?
Falls ja, dann wäre die interessante Frage, was diese IsVisible-Methode macht, die du aufrufst. Wird da Pixel-Genau überprüft oder nur über ein Rechteck (welches der Größe des Bildes entspricht)? Falls ersteres würde ich das auf letzteres umstellen.

Falls es nach allen Versuchen zu langsam ist, gäbe es da noch andere Optimierungsmöglichkeiten. So gibt es zum Beispiel Suchbaum-Strukturen speziell für den grafischen Bereich, z. B. QuadTree. Standardmäßig im .Net implementiert sind die aber nicht..

Gruß
Roland

Hallo Gumba,

da musst du aber schon sehr viele grafisch Objekte haben, um Performance-Probleme zu haben.

"dynamische Anzahl an Bildern" klingt nach einem rechteckigen / schachbrettartigem Aufbau. Bei einem solchen kannst du (hauptsächlich mit einfachem Dreisatz) aus den Koordinaten direkt ausrechnen, auf welches Bild geklickt wurde.

herbivore

Falls ja, dann wäre die interessante Frage, was diese IsVisible-Methode macht, die du aufrufst. Wird da Pixel-Genau überprüft oder nur über ein Rechteck (welches der Größe des Bildes entspricht)?

GraphicsPath.IsVisible-Methode (Point)
-> Gibt an, ob der angegebene Punkt in diesem GraphicsPath-Objekt enthalten ist.

das heißt in meinem Fall wird geschaut, ob die Mousposition innerhalb meines Images liegt (also quasi innerhalb eines Rechtecks)

den QuadTree werd ich mir mal anschauen, vll find ich da ja zusätzliche Anregungen 😉

"dynamische Anzahl an Bildern" klingt nach einem rechteckigen / schachbrettartigem Aufbau. Bei einem solchen kannst du (hauptsächlich mit einfachem Dreisatz) aus den Koordinaten direkt ausrechnen, auf welches Bild geklickt wurde.

es geht ja nicht um einen Klick auf das Bild -> das könnt ich auch im MouseClick-Event verarbeiten und momentan habe ich noch keine Performanceprobleme. Meine Befürchtungen waren nur, dass ich später bei einer größeren Anzahl an Bilder welche bekommen könnte und wollte deshalb jetzt in der Anfangs-Entwicklungsphase dieses mögliche Problem beseitigen 😉
Aber vll lässt sich das ja über den erwähnten Dreisatz lösen, denn die Bilder sind wirklich in ner Art Schachbrett aufgereiht 😉

Mfg
Gumba

Edit.: Gibts für den Dreisatz nen Ansatz, den ich benutzen kann? Steh da grad iwie aufm Schlauch 🤔

Hallo Gumba,

Gibts für den Dreisatz nen Ansatz

Wenn du n Bilder hast und jedes Bild hat eine Breite b dann ist die Gesamtbreite n*b.
Wenn das Fenster das von den Bilder ausgefüllt ist w breit ist und die Mauskoordinaten bei x sind kannst du aus dem Verhältnis x/w ermitteln welches der n Bilder betroffen.

Wenn die Bilder keine konstante Breite haben ist der Ansatz der gleiche nur das Suchen des betroffenen Bildes erfolgt ein wenig anders. Aber da kannst du selbst rätseln 😉

mfG Gü

Hallo Gumba,

Meine Befürchtungen waren nur, dass ich später bei einer größeren Anzahl an Bilder welche bekommen könnte und wollte deshalb jetzt in der Anfangs-Entwicklungsphase dieses mögliche Problem beseitigen

Dazu sage ich nur: "premature optimization is the root of all evil". Nur auf eine unbegründete Befürchtung hin sollte man nichts optimieren. Zumal eine Änderung der Ermittlung nur die Implementierung einer einzelnen Methode betrifft und daher die Programmstruktur überhaupt nicht beeinflusst hätte.

herbivore