Herausfinden über welchem Steuerelement sich die Maus befindet

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von Trade.

    Herausfinden über welchem Steuerelement sich die Maus befindet

    Hallo,
    ich habe eine Form, die unter Anderem 572 RectangleShapes enthält. Schwebt nun die Maus über einnem schwebt bzw. es verlässt soll sich die borderwidth verändern.
    Anstatt mich unzählige Male mit enter und leave oder hover rumschlagen zu müssen hätte ich vor einach, am besten nach dem Namen, abzufragen über welchem Steuerelement sich die Maus gerade befindet.
    Allerdings komme ich nicht so recht weiter, bzw. habe keine Ahnung wie man überhaupt sowas macht :/
    Vielen Dank.
    Moin.

    RoW171 schrieb:

    572 RectangleShapes
    Sicher, dass du kein Design-Problem hast? Das klingt nach viel zu viel.
    Was soll erreicht werden? Das kann man sicher anders (besser) lösen ;)
    Mit freundlichen Grüßen,
    Thunderbolt
    Also so Zellen für ein Schiffe versenken kann man auch noch bequem als DataGridView-Zellen abbilden.
    FightingSnakes ist zB ein Sample, wo DGV-Zellen als Spiel-Welt-Zellen "missbraucht" werden.
    Und dort ist auch auf weitere Tuts mit vergleichbaren "Missbräuchen" verlinkt.

    Die Zelle unter der Maus findet man mit der DGV.Hittest-Methode.
    Die ist bisserl unkomfortabel zu bedienen, aber eiglich sehr effizient und leistungsfähig.
    Hi
    zeichne dein Spiel mithilfe der Graphics-Klasse auf ein Steuerelement (Paint-Ereignis benutzen!)
    Über die Ereignisse MouseMove, MouseClick erhältst du alle relevanten Informationen, sodass du dort die Spielelogik implementieren kannst. Das mit dem DGV halte ich übrigens für anstrengender, als es selbst zu zeichnen.

    Viele Grüße
    ~blaze~

    ~blaze~ schrieb:

    Das mit dem DGV halte ich übrigens für anstrengender, als es selbst zu zeichnen.
    Jo, normalerweise, wenn viele Objekte darzustellen sind, wäre Ownerdrawing (hier meist bischen irreführend als GDI+ bezeichnet) das Mittel der Wahl.
    Aber im Spezialfall, dass ein Spielfeld in gleichförmige kleine Quadrate zu unterteilen ist, die sich auch nicht bewegen, da kann einem ein DGV einiges abnehmen, das teilt seine Fläche ja auch in Rechtecke ein, und kann die mit einfachen Indizees addressierbar machen, kann selektieren, auf Taste/Maus reagieren etc..
    Und auch im DGV-Ansatz kommt man nicht ohne OwnerDrawing aus, man muss halt die einzelnen Zellen malen.
    Jdfs. ich hab immerhin auf was verlinkt, wo man sich lauffähige Beispiele dazu angucken kann.
    Ich kann auch nicht versprechen, dasses wirklich einfacher ist, dazu müsste man letztendlich beide Ansätze ausprogrammieren.

    Und dann braucht man natürlich die Spiele-Logik, so oder so.
    Also ein Datenmodell muss man auch konzipieren und umsetzen können. Es müssen ja verschiedenerlei Schiffe gemerkt werden, jedes bestehend aus mehreren Einheiten, und sowohl die Einheiten als auch die Schiiffe insgesamt kennen ja verschiedene Zustände (eigenes/anderes Schiff, (un-)getroffen). Und auch die Zellen muss man markieren können, mit/ohne Schiff, getestet/ungetestet... - da liegt imo die Hauptaufgabe, das überhaupt mal im Einzelnen zu konzipieren.

    RoW171 schrieb:

    Schwebt nun die Maus über einnem schwebt bzw. es verlässt
    Controls haben ein Enter- und ein Leave-Event, die erfüllen genau diesen Zweck. Falls Du etwas später reagieren willst, nimm das MouseHover-Event.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ein DataGridView hat in 'nem Spiel nichts zu suchen. Es ist ein Control und damit macht man keine Spiele.
    Ist ja ganz recht für gewisse Sachen bzgl. Datenverarbeitung, aber man sollte über den Tellerrand hinausschauen und mal davon abkommen, speziell hier.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:
    Hmm - du wiederholst nur, was bereits Blaze in post#8 äussert (übrigens inhaltlich etwas differenzierter), und wo ich bereits in post#9 drauf antwortete.

    Das mit dem Tellerrand kann ich übrigens zurückgeben - du könntest ja auch mal über deinen (GDI+)-Tellerrand gucken.

    Aber egal - ich nehme an, der TE hat sein Projekt eh inzwischen aufgegeben - man hört ja nix mehr von ihm.

    Und ansonsten ufert die Tellerrand-Diskussion jetzt womöglich auch noch aus.

    /Delete-Request

    ErfinderDesRades schrieb:

    du könntest ja auch mal über deinen (GDI+)-Tellerrand gucken.
    Dann nimmste halt DirectX oder OpenGL. So oder so sind diese Technologien aber für Spiele geeignet, was ein DGV nicht ist. Deswegen macht die Aussage keinen Sinn. ;)

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:
    Aber du glaubst doch nicht im Ernst, dass der TE imstande ist, DirectX oder OpenGL zu handlen?

    Und ma bitte!
    Ein Schiffe-Versenken-Spiel ist was absolut statisches. Da hat man lauter starre Zellen, und malt gelegentlich ein Kreuzlein rein. Das kann man sehr gut in DGV-Zellen machen.
    Aber natürlich gerne auch mit richtigen Figure-Klassen, die sich selber malen (klassisches OwnerDrawing).

    Nur mit DirectX drauf loszugehen ist ma sowas von oversized.
    Und ist wie gesagt gänzlich ausserhalb dessen, was der des TE realistisch gesehen vermutlich erreichen kann - diese Einlassung kann ihm also garnix nützen.
    DirectX und OpenGl sind wohl wirklich zu viel fuer den TE, aber ein DataGridView wird er vermutlich genau so wenig dafuer nutzen koennen. Ich finde es unsinnig(hier in diesem Fall) solche Sachen zu empfehlen. Bei einem so simplen Spiel, reicht GDI und ein bisschen Mathe aus.

    Hier habe ich mal ein Control gemacht, fuer eine "Lotto Simulation". Da kann der TE sicher einiges abgreifen und fuer sein Vorhaben nutzen.
    Checkboxen limitieren für Lotto 6 aus 49 - Visual Basic 2010 Express
    And i think to myself... what a wonderfuL World!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Eddy“ ()

    Jo, da hast du jetzt wirklich eine feinere Vorlage abgeliefert als ich, mit blitzsauberem OwnerDrawing :thumbup:
    (beachte: wir sind die einzigen, die wirklich eine Vorlage liefern, alle anderen wissen nur wie's geht).

    Ups - doch nicht blitzsauber - eine Verbesserung hätte ich noch: Beim Setzen einer Zelle solltest du statt Me.Invalidate() nur Me.Invalidate(Rectangle) aufrufen, wobei Rectangle sollte die Abmasse der Zelle angebibt. So wird dann nur das kleine Rechteck geneuzeichnet, nicht die ganze Control-Fläche.
    Merkt man konkret nicht, aber Ownerdrawing sollte das prinzipiell können, dass nur der Teil geneuzeichnet wird, der auch geändert wird - sollte man sich garnet anders angewöhnen.
    Natürlich reicht GDI+ auch und ist auch vollkommen geeignet. Es ging nur darum, dass ich über den GDI+-Tellerrand schauen sollte und da wären halt dann noch die weiteren Technologien. Das hieß aber nicht, dass der TE das benutzen soll.
    Aber gut, nun BTT.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!: