[Dev] Unsichtbare Cachesymbole aus der Map verbannen

[Wutschkow]

Caches, die in der Liste ausgewählt sind aber deren Position nicht auf der aktuell angezeigten Karte ist, positioniert die MovingMap derzeit bei 0,0 und setzt die Property "IsInvisible".
Allerdings sind die Symbole dadurch nur unsichtbar, aber nicht gänzlich verschwunden. Wenn man mal mit der rechten Maustaste zwischen oberer, linker Ecke und dem gelben Menüpfeil klickt (also quasi zwischen 0,0 und 14,14), bekommt man das Kontextmenü eines markierten, aber derzeit nicht angezeigten Caches.
Soweit nicht gerade schön, aber nur bedingt störend. Wenn man aber größere Symbole als 15x15 (z.B. 32x32) verwenden will, reichen diese dann über den gelben Menüpfeil hinaus und überlagern diesen unsichtbar. Anklicken kann man ihn dann nicht mehr, ergo kein Menü.

Um das Problem zu lösen, habe ich jetzt anstelle von super.move(0, 0); einfach mal super.move(-1000, -1000); verwendet, solche unsichtbaren Symbole also ins "Bildnirwana" verschoben. Das scheint soweit zu klappen.

Aber da das ja doch eher die "quick&dirty"-Variante ist, möchte ich das mal bei den deutlichen erfahreneren Entwicklern zur Diskussion stellen. Könnte das irgendwelche Seiteneffekte haben oder gibt es eventuell eine elegantere und "logischere" Methode, das Problem zu lösen?
(Mit der AlwaysOnTop-Property habe ich schon mal ein wenig rumgespielt, das hat nichts gebracht. Und eine Methode, Bilder ausdrücklich in den Hintergrund zu schicken, habe ich nicht entdecken können.)

 

[pfeffer]

Koordinaten, die nicht auf dem Bildschirm sind, scheinen zu nächst zu funktionieren - so ähnlich hatte ich es ursprünglich. Aber: es scheint mir unvorhersehbare Nebeneffekte zu haben. --> das ist keine gute Lösung.

Man kann die Reihenfolge sehr wohl verändern - guckt mal in die Routinen, die das dragging implementieren. Da wird erstmal alles entfernt, was nicht die Karte ist (damit das verschieben möglichst flüssig geht) und hinterher wieder hergestellt. Auf ähnliche Weise kann man die Reihenfolge der Bilder ändern.

So auf anhieb würde ich, glaub ich, den Eventhandler der MapImage so ändern, dass es den Event korrekt weitergibt an das darunter liegende Bild, wenn es selbst als invisible gekennzeichnet ist. Das scheint mir die durchsichtigste ( ) Lösung zu sein.

Gruß,
Pfeffer.

 

[arbor95]

...Aber: es scheint mir unvorhersehbare Nebeneffekte zu haben. ....

Weisst du noch welche ?

 

[pfeffer]

ich glaube: Speicherprobleme und irgendwie fingen plötzlich alle Symbole an, nicht mehr dort zu sein, wo sie sein sollten. Das kann auch zusammenhängen mit .move und .setLocation. Das eine davon wirkt auf einem virtuell vergrößerten Bildschirm, auf dem Ewe automatisch skrollt oder so, anders als die andere Methode.

Ich hatte aber den Eindruck, dass dieser virtuelle Bildschirm sehr Buggy ist.

Gruß,
Pfeffer.

 

[Ratimer]

Kann man bei den ohnehin nicht sichtbaren Symbolen vollständig auf die Darstellung verzichten? Das frisst doch nur (ohnehin knappe) Rechenleistung des PDA.
Ich gehe oftmals einfach so wandern, ohne vorher Caches rauszusuchen und schalte dann alle Caches im Profil an. Vielleicht liegt ja einer am Wegesrand . Da kommt dann schon eine gewisse Menge zusammen und das Rendern dauert entsprechend lange. Wenn man hier etwas optimieren könnte, wäre das echt super!

 

[pfeffer]

hmmm - vielleicht kann man 2 Listen halten: Symbole, die tatsächlich dargestellt werden und Symbole, die dargestellt werden, wenn sie im Bereich des Bildschirms kommen.

Ich bin mir nicht so sicher, ob das schneller ist, aber vielleicht schon. Dann müsste man immer, wenn ein Symbol dazu kommt oder verschwindet die Arrays umkopieren, die die Liste der angezeigten Symbole beinhalten.
Ich glaube, dieses Array-Umkopieren kann Ewe sehr schnell, weil es in Nativem Code gemacht wird. Man müsste nur dafür sorgen, dass beide Arrays (vector) immer groß genug sind.

Gruß,
Pfeffer.

 

[Ratimer]

hmmm - vielleicht kann man 2 Listen halten: Symbole, die tatsächlich dargestellt werden und Symbole, die dargestellt werden, wenn sie im Bereich des Bildschirms kommen.

Ich bin mir nicht so sicher, ob das schneller ist, aber vielleicht schon. Dann müsste man immer, wenn ein Symbol dazu kommt oder verschwindet die Arrays umkopieren, die die Liste der angezeigten Symbole beinhalten.
Ich glaube, dieses Array-Umkopieren kann Ewe sehr schnell, weil es in Nativem Code gemacht wird. Man müsste nur dafür sorgen, dass beide Arrays (vector) immer groß genug sind.

Das wäre sicher die zur Laufzeit günstigste Variante, scheint mir aber recht aufwändig zu programmieren. Ich kenne den Sourcecode nicht. Aber kann man nicht einfach die Objekte ohne Koordinaten aus dem Redering ausschließen? Das wäre warscheinlich nicht so aufwändig und würde sicher auch schon was bringen.

 

[pfeffer]

ich vermute, dass die Objekteigenschaft "invisible" genau das macht. Habe ich mir aber nicht im Ewe-Code angeschaut.

Gruß,
Pfeffer.

 

[Wutschkow]

Also wenn ich das richtig durchschaue, dann wird im Moment die Entscheidung, ob ein Symbol auf der Karte darzustellen ist oder nicht, erst nach dem Erstellen der Symbol-Images getroffen, nämlich anhand der Frage, ob die Darstellung dieses Bildes innerhalb der Bildschirmdimensionen liegen würde oder nicht.
Dann ist das Image aber eben schon vorhanden und muss anscheinend irgendwohin.

Man müsste also die Entscheidung, ob ein Symbol darzustellen ist oder nicht, auf einen früheren Zeitpunkt verlagern, dann brauchen nichtbenötige Images gar nicht erst angelegt zu werden.

Das muss man dann aber bei jeder Veränderung der Karte auch immer wieder überprüfen und ggf. Images nachliefern und nicht mehr benötigte löschen. Dazu müsste denke ich einiges im Code umgestrickt werden. Die Event-Variante wäre in der Hinsicht weitaus billiger.

@Ratimer: Wäre für Deine Anwendungsvariante nicht der Radarschirm eine gute und eventuell übersichtliche Alternative?

 

[Wutschkow]

ich vermute, dass die Objekteigenschaft "invisible" genau das macht. Habe ich mir aber nicht im Ewe-Code angeschaut.

Tja, wie definiert man Rendering? Die Symbole sind mit "IsInvisible" eben nicht sichtbar, aber sie existieren trotzdem und müssen sicher auch irgendwie berechnet werden. Sonst könnten sie ja keine Events erhalten und genau das ist ja das Problem. Ich vermute mal, sie werden einfach mit 100% Transparenz gezeichnet und fertig.

 

[pfeffer]

und wie zeichnet man 100% Transparenz? - Ich vermute, einfach gar nicht.

Vielleicht gibt es ja auch noch eine eigenschaft, die die Events abschaltet?

Gruß,
Pfeffer.

 

[Ratimer]

Man müsste also die Entscheidung, ob ein Symbol darzustellen ist oder nicht, auf einen früheren Zeitpunkt verlagern, dann brauchen nichtbenötige Images gar nicht erst angelegt zu werden.

Sehe ich auch so.

Das muss man dann aber bei jeder Veränderung der Karte auch immer wieder überprüfen und ggf. Images nachliefern und nicht mehr benötigte löschen. Dazu müsste denke ich einiges im Code umgestrickt werden. Die Event-Variante wäre in der Hinsicht weitaus billiger.

Es würde sicher schon etwas bringen, wenn einfach die Waypoints ohne Koordinaten niemals gerendert werden, also bei oben genannter Entscheidung herausfallen. Alle Punkte die nur zur Zeit außerhalb des Bildschirms liegen auszufiltern wäre natürlich das Sahnehäubchen.

@Ratimer: Wäre für Deine Anwendungsvariante nicht der Radarschirm eine gute und eventuell übersichtliche Alternative?

Ich will ja sehen, ob etwas "am Wege" liegt. Da hilft die Karte schon besser.

 

[Wutschkow]

und wie zeichnet man 100% Transparenz? - Ich vermute, einfach gar nicht.

Deshalb meine Frage, was man unter Rendern versteht. Wenn Rendern wirklich nur das Zeichnen der Pixel auf dem Bildschirm ist, dann wird mit "IsInvisible" nicht gerendert. Wir können das auch gerne so festhalten. Es ändert leider nichts an der Tatsache, das auch ungerenderte Images Events abgreifen.

Vielleicht gibt es ja auch noch eine eigenschaft, die die Events abschaltet?

Danach habe ich als erstes gesucht. Gefunden habe ich leider nichts. Nur ist die "Dokumentation" der API ja auch nicht gerade geschwätzig. Oder gibt es eine bessere Quelle als http://www.ewesoft.com/docs/api/?

Das einzige, was mir dazu aufgefallen ist:

IsLocked

public static final int IsLocked

    A property bit - The image is locked - not used yet.

    See Also:
        Constant Field Values

"not used yet" hört sich aber auch nicht gut an, oder?

 

[Wutschkow]

Es würde sicher schon etwas bringen, wenn einfach die Waypoints ohne Koordinaten niemals gerendert werden, also bei oben genannter Entscheidung herausfallen.

Wegpunkte ohne Koordinaten fallen auch jetzt schon früher raus. Ich meine, für die werden gar nicht erst Images erstellt, weil sich diese Entscheidung ja recht einfach anhand der Cacheholder-Daten treffen lässt. Ist aber nur aus der Erinnerung, da müsste ich nochmal in den Code schauen.

 

[pfeffer]

ich gucke immer in den Ewe-Quellcode, da steht dann auch was wirklich passiert, nicht nur, was passieren sollte.
Ich glaube, es gibt noch eine weitere Eigenschaft, die so ähnlich heißt - vielleicht disable? oder IsEnabled? - Ich weiß es grad nicht. Vielleicht gibt es die 2. Eigenschaft auch nur bei Controls - ich weiß grad aus dem kopf auch nicht, ob MapImage von Control abgeleitet ist (vermutlich nicht?).

Gruß,
Pfeffer.