POST
|
The issue that I experienced was rooted in the server being unable to respond to requests with a complex WHERE clause but this was for unrelated reasons, so my workaround of disabling the WHERE functionality is probably not a general solution, I'm afraid. There are presumably other possible causes for the E0011E issue, so one of those may be applicable. That said, if you wish to disable the cache by changing its size, the syntax I quoted was just an MXML fragment from a layer declaration. If your language API has an onDemandCacheSize() function for the layer then you could presumably try calling onDemandCacheSize(0) instead.
... View more
08-01-2013
07:31 AM
|
0
|
0
|
536
|
POST
|
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!
... View more
05-13-2013
05:51 AM
|
0
|
0
|
392
|
POST
|
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?
... View more
05-13-2013
04:27 AM
|
0
|
0
|
392
|
POST
|
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?
... View more
05-10-2013
11:32 AM
|
0
|
0
|
392
|
POST
|
Wow, thanks for the speedy reply... it has now gone away after making your suggested change!
... View more
04-04-2013
04:10 AM
|
0
|
0
|
226
|
POST
|
I've just noticed that my builds using the API 3.1 all have a subtle letter 'C' visible in the lower right-hand corner of the screen. It doesn't seem to have been there with API 2.4 and API 2.5 builds. Can someone explain what it means please?
... View more
04-04-2013
03:58 AM
|
0
|
4
|
585
|
POST
|
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.
... View more
01-02-2013
01:48 AM
|
0
|
0
|
392
|
POST
|
Have also noticed that the new selection highlighting when !isNaN(layer.selectionColor) doesn't always highlight the correct symbol. Has anyone else found this?
... View more
12-21-2012
12:08 AM
|
0
|
0
|
392
|
POST
|
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.
... View more
12-20-2012
08:08 AM
|
0
|
9
|
772
|
POST
|
In fact, there were still a couple of problems for us, however we've discovered the 'where' functionality can be disabled with the following Feature Layer attribute, so hopefully it won't cause any further trouble now: onDemandCacheSize="0"
... View more
12-20-2012
07:20 AM
|
0
|
0
|
536
|
POST
|
It's like "where=ObjectId NOT IN (...)"; no worries though as I think we've actually just resolved this issue now! 🙂
... View more
12-19-2012
10:37 AM
|
0
|
0
|
536
|
POST
|
Thanks bjorn, your suggestions proved helpful as it turned out to be an issue with the "fields" not being setup correctly for our feature layers. I've noticed that ArcGIS API 3.0 final (and the newer 3.1) are sending a 'where' clause back to the server in the REST requests, which is now causing us a few issues, so we'd like to prevent that from happening. Does anyone know of a way to disable this new behaviour please?
... View more
12-19-2012
05:40 AM
|
0
|
0
|
536
|
POST
|
Sadly that's not an option as our development environment is an offline system, therefore arcgisonline would be unreachable. Do you know if there's a way to find out what Error E0011E actually means, please?
... View more
12-07-2012
08:27 AM
|
0
|
0
|
500
|
POST
|
Thanks again for the replies Robert. Do you know if the REST protocol has changed or become more strict for ArcGIS API 3.0 (final)? How are you using FeatureLayer in your code? Some of the layers are declared statically using MXML whilst in other applications we create them dynamically from ActionScript; both suffer from the same issue with ArcGIS API 3.0 (final). Our layers have mode set to onDemand, useAMF is false and we have custom event handlers for graphicAdd, updateStart and updateEnd. Are you using the Adobe 4.6 SDK? Yes, the build environment is Flash Builder 4.6 with the Adobe Flex 4.6.0 SDK. I've also briefly tried the more recent Apache Flex 4.8.0 but had no luck getting it to build successfully.
... View more
12-07-2012
07:59 AM
|
0
|
0
|
500
|
POST
|
Yes, I can confirm that. The exception doesn't occur if the 2.x or 3.0pre-release swc files are used.
... View more
12-07-2012
06:39 AM
|
0
|
0
|
500
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|