InfoWindow corruption issue

[SarahBurgin]

Hi guys... thanks for the new API... it's looking good!

Just noticed what appears to be an issue with InfoWindow?

Starting with a display that has several hundred simple marker symbols, if I zoom out so that several symbols move on top of each other and then click one of them to open an InfoWindow, using API 3.0/3.1 this is now paged, allowing the user to see details for different symbols across separate pages and select between them.

This is a nice enhancement... however, if the map is then zoomed whilst the InfoWindow remains open, this seems to cause corruption to the InfoWindow pages. I've seen:

- the InfoWindow contents do not display correctly when the page is changed after zoom;
- the marker symbol that was clicked can be replaced with a black circle (i.e. the default symbol);
- sometimes the anchor can end up pointing to the wrong map co-ordinates.

If the InfoWindow is closed then the symbol is restored and upon opening it again the InfoWindow is fixed.

Our application uses InfoWindowRenderer with an mx:VBox containing an mx:Text that's populated using htmlText. I'm testing using Google Chrome.

[SarahBurgin]

Have also noticed that the new selection highlighting when !isNaN(layer.selectionColor) doesn't always highlight the correct symbol. Has anyone else found this?

[DasaPaddock]

Can you share test cases to reproduce these issues?

[GISDev1]

Woah, good catch. I just reproduced the error with the InfoWindow in the OOTB Viewer 3.1.

1. Zoom way out and click on a spot with a lot of close points, therefore activating the pop-up window with little arrows to page through each point feature.

2. Zoom way in and click through the arrows and cycle through the points.

3. Zoom way out (InfoWindow still showing).

4. Pan way over on the map out of the extent of the PopUp window.

5. Pan back over and zoom-in to the pop-up window (same one from original click), and then cycle through and the pop-up window is showing me all of the original field names, with no aliases, and very corrupt looking, and the symbol is overlaid with a black dot as well.

[SarahBurgin]

Thanks for the reply GISDev01. I'm glad you're able to reproduce the InfoWindow corruption issue. We're actually experiencing it with far fewer steps - all it really takes for us to see it, is simply opening an InfoWindow for any overlapping symbol before changing the zoom level in or out, then flicking through the InfoWindow pages.

The other issue - whereby clicking a symbol highlights the wrong symbol, only seems to happen for some of our feature layers. They're layers in which the symbols are ellipses that are displayed by extending the Symbol class with our own custom EllipseSymbol class. The class implements overrides for clear() and draw() methods. What we see is that the first click on a symbol for this layer highlights the correct symbol, which clears when the InfoWindow is closed, but then any other clicks for the layer re-highlight that same symbol again instead of the one that was really clicked. Nevertheless, the InfoWindow that opens relates to the correct symbol.

[SarahBurgin]

I wonder if it's likely that these issues can be resolved? Is there any news, please?

I've now tried switching to version 3.2 of the API and found that it exhibits the same problems.

Looking at the incorrect feature highlighting, it seems to be the layer InfoWindowRenderer that selects the feature, but setting selectionColor on the FeatureLayer to Number.NaN doesn't change its behaviour. I had hoped to find a work-around solution. Does anyone know of a way to stop the InfoWindowRenderer highlighting the features that it selects, as we'd prefer to turn highlights off rather than see the wrong features highlighted?

[DasaPaddock]

You can disable the highlighting by setting the Map style "infoWindowRendererHighlightColor" to NaN:

See:
http://resources.arcgis.com/en/help/flex-api/apiref/com/esri/ags/Map.html#styleSummary

[DasaPaddock]

Thanks for the reply GISDev01. I'm glad you're able to reproduce the InfoWindow corruption issue. We're actually experiencing it with far fewer steps - all it really takes for us to see it, is simply opening an InfoWindow for any overlapping symbol before changing the zoom level in or out, then flicking through the InfoWindow pages.

The other issue - whereby clicking a symbol highlights the wrong symbol, only seems to happen for some of our feature layers. They're layers in which the symbols are ellipses that are displayed by extending the Symbol class with our own custom EllipseSymbol class. The class implements overrides for clear() and draw() methods. What we see is that the first click on a symbol for this layer highlights the correct symbol, which clears when the InfoWindow is closed, but then any other clicks for the layer re-highlight that same symbol again instead of the one that was really clicked. Nevertheless, the InfoWindow that opens relates to the correct symbol.

Are you also overriding destroy() in your EllipseSymbol?
http://resources.arcgis.com/en/help/flex-api/apiref/com/esri/ags/symbols/Symbol.html#destroy()

Can you share the code for EllipseSymbol?

[SarahBurgin]

You can disable the highlighting by setting the Map style "infoWindowRendererHighlightColor" to NaN:

See:
http://resources.arcgis.com/en/help/flex-api/apiref/com/esri/ags/Map.html#styleSummary

That's great - thanks!

Unfortunately it affects all layers, rather than just the few that experienced the issue, nevertheless I think it's a workaround that should be acceptable for our application if we're unable to find a fix!

Are you also overriding destroy() in your EllipseSymbol?
http://resources.arcgis.com/en/help/flex-api/apiref/com/esri/ags/symbols/Symbol.html#destroy()

I wasn't overriding destroy() but have just experimented with that. Sadly, it doesn't seem to help. I find that destroy() isn't being called inbetween one symbol being selected and the next being selected, i.e the map layer isn't necessarily refreshed.

Actually, causing the map layer to update by panning still doesn't appear to change the highlight, although zooming does correct the highlight! Maybe this provides a clue for what's going on?

[SarahBurgin]

Oh... I've just realised the selection highlighting issue is actually caused by some long forgotten code in my draw() function that inhibits repeated redrawing (added because it was being invoked twice for the same symbol in some circumstances IIRC)... looks like I need to remove or adjust that safeguard... commenting it out ensures that the highlighting is correct so that confirms my EllipseSymbol class is at fault!