[JAVA] Context gevoelig popupmenu

[Verwijderd]

Hallo,

Ik ben momenteel een programmaatje aan het schrijven om gps tracks te visualiseren.
Daarvoor gebruik ik g2d om alles in een JPanel te tekenen.

Wat ik nu graag zou willen, is een context gevoelig popupmenu bij rechtermuisklik, voor bv:

- klik op een track
- klik op de achtergrond
- klik op een terrein item zoals een huis, weg, vijver, ....

Volgens mij is dit niet mogelijk als ik alles met g2d methodes teken.
Moet ik images laden in het JPanel, of hoe los ik dit anders op?

Verder zou ik een spline willen kunnen tekenen met de muis, die achteraf selecteerbaar en wijzigbaar is. Hier zelfde verhaal, hoe detecteer ik dat erop geklikt wordt?

Groeten,
Jerre

[RobIII]

Titelfix
Helaas ben ik niet zo'n JAVA guru om een zinnig antwoord hierop te kunnen geven, maar kun je voor de wel-guru's dan op z'n minst al eens aangeven wat je al hebt gezocht / gevonden en geprobeerd en wat daar niet aan werkte?
Overigens zegt mij gut-feeling dat je "gewoon" de X/Y van je muis onclick moet bepalen en aan de hand daarvan uitpuzzelen waar op geklikt is (wat je dus op die plek hebt getekend (huisje/weg/vijver/etc)) en afhankelijk daarvan het context menu samenstellen en tonen.

[ Voor 36% gewijzigd door RobIII op 28-08-2006 23:28 ]

[Robtimus]

RobIII schreef op maandag 28 augustus 2006 @ 23:07:
Overigens zegt mij gut-feeling dat je "gewoon" de X/Y van je muis onclick moet bepalen en aan de hand daarvan uitpuzzelen waar op geklikt is (wat je dus op die plek hebt getekend (huisje/weg/vijver/etc)) en afhankelijk daarvan het context menu samenstellen en tonen.

We have a winner!

Jij weet wat je waar hebt getekent, dus weet je ook wat er op welk coordinaat te zien is. En wat een mazzel, een MouseEvent heeft methods getX(), getY() en getPoint()*!

* getPoint() creeert een nieuw Point object dus is alleen aan te bevelen als een functie een Point object nodig heeft. Eerst getPoint() aanroepen en dan daarvan de x en y fields uitlezen is dus af te raden.

[Verwijderd]

IceManX schreef op dinsdag 29 augustus 2006 @ 13:15:
* getPoint() creeert een nieuw Point object dus is alleen aan te bevelen als een functie een Point object nodig heeft. Eerst getPoint() aanroepen en dan daarvan de x en y fields uitlezen is dus af te raden.

Seriously: lekker boeien. Dit is er echt een uit de catagorie: onnodige premature optimalisaties.
Zo'n Point object maakt het gewoon lekker leesbaar.

[JKVA]

Tja, als je met de hand alles tekent met je Graphics objecten, dan ontkom je er niet aan om alles met de hand te maken.

Dus gewoon de onclick afvangen, x en y doorgeven en dan kijken wat het toepasselijke menu is bij die coordinaat.

[Robtimus]

Verwijderd schreef op dinsdag 29 augustus 2006 @ 15:33:
[...]

Seriously: lekker boeien. Dit is er echt een uit de catagorie: onnodige premature optimalisaties.
Zo'n Point object maakt het gewoon lekker leesbaar.

Persoonlijk vind ik getX() en getY() net zo leesbaar, dus dat valt wel mee.

[MBV]

Verwijderd schreef op dinsdag 29 augustus 2006 @ 15:33:
[...]

Seriously: lekker boeien. Dit is er echt een uit de catagorie: onnodige premature optimalisaties.
Zo'n Point object maakt het gewoon lekker leesbaar.

offtopic:
Doe daar aub wel aan. Als je dat niet doet is het weer zo'n typisch bloated java-programma als Poseidon UML en co, wat na even werken zo traag wordt dat je spijt krijgt dat je hem hebt gedownload

Volgens mij kon dit nog wel eens een lastig probleempje zijn. De TS zal waarschijnlijk niet alleen rechthoekjes hebben, en dan wordt het ineens lastiger uitrekenen waar je een 'collision' mee hebt...

[Gerco]

MBV schreef op dinsdag 29 augustus 2006 @ 22:41:
Volgens mij kon dit nog wel eens een lastig probleempje zijn. De TS zal waarschijnlijk niet alleen rechthoekjes hebben, en dan wordt het ineens lastiger uitrekenen waar je een 'collision' mee hebt...

Dat zou je kunnen oplossen door ergens een tweede (graphics) buffer bij te houden met daarin per pixel, welk object zich daar bevind.

Dat zou je kunnen doen door op een tweede graphics, elk object met een unieke kleur te tekenen en dan, wanneer je het object waar de muis naar wijst wilt weten, de X en Y van de muis op die tweede graphics op te zoeken. De kleur op die positie geeft het gewenste object aan.

[Verwijderd]

inderdaad, de tekeningetjes kunnen wat ingewikkelder zijn. Laat staan het spoor van de gps zelf.
Daarvoor wordt alles berekend op basis van lengte en breedtegraad. Tussen alle punten wordt een lijn getrokken. Dat betekent dat je voor elk lijnstukje appart de vgl moet uitrekenen om te kijken of er op geklikt wordt.

Kleurdetectie lijkt me het makkelijkste. Alleen geen idee hoe je dit detecteert in java.

Wat ik me afvraag, kan ik niet bv van elk te displayen item een graphics object maken, en invoegen in een of ander displayend panel. Zodanig dat het object automatisch herkend kan worden bij een klik? Ondersteund java zo iets, of kent iemand een package die dit mogelijk maakt?

Of heeft iemand ervaring met java based GIS systemen?

opmerking op JKVA:
De "gps track" teken met de g2d drawline methode. Andere tekeningetjes zoals huisjes, vlaggetjes, ventjes etc zou ik uit een jpeg kunnen laden. Aangezien die vierkant zijn, kan ik inderdaad wel de xy coordinaten van de hoekpunten kunnen uitrekenen en bij houden.

[ Voor 16% gewijzigd door Verwijderd op 29-08-2006 23:17 ]

[Gerco]

@steenaap: Het gaat dus niet om detectie van de kleur op je scherm he. Je tekent al je objecten twee keer. 1x op het scherm en 1x op een onzichtbare, offscreen graphics/buffer/image. Op die tweede graphics/buffer/image teken je elk object met 1 kleur die per object verschilt.

De mapping tussen de kleuren en de objecten bewaar je ergens en als er dan geklikt word, vraag je aan de offscreen graphics/buffer/image welke kleur er op positie (x,y) staat. Zoek die kleur op in de mapping en je hebt je object te pakken.

Je zal alleen zelf moeten bepalen hoe je de kleur op een bepaalde positie moet opvragen. Aangezien dit afhangt van de buffer implementatie (ik weet zo even geen objecten die je hiervoor kan gebruiken uit mijn hoofd) en kunnen we je dus ook niet mee helpen.

[Verwijderd]

Dat is inderdaad een goeie! Had ik nog niet bij stilgestaan (en berichtje te snel gelezen).
Ik probeer het voorlopig hiermee.

[ Voor 72% gewijzigd door Verwijderd op 29-08-2006 23:20 ]

[momania]

Verwijderd schreef op dinsdag 29 augustus 2006 @ 15:33:
[...]

Seriously: lekker boeien. Dit is er echt een uit de catagorie: onnodige premature optimalisaties.
Zo'n Point object maakt het gewoon lekker leesbaar.

offtopic:
En dit wordt gelukkig met de komende 'escape analysis' automatisch weer opgelost