Latest Contributions by TorrinHultgren

The Legend widget in the ArcGIS JavaScript API (Both 3.18 and 4.1) seems hardcoded to always place low values at the bottom and high values at the top, regardless of the order in which they are configured in a map service. Cartographic authorities suggest that there isn't a correct order - valid arguments may be made for either sort order, at the discretion of the cartographer and the intended message. And some cartographers feel very strongly about the order in which their legend appears, and are unnerved when that order is reversed when incorporated into a mapping application or viewed in ArcGIS Online. We'd like to request that either the legend follow the order set in a map service, or that ArcGIS Online users (and developers using the API) be given the ability to set the legend class order they feel is most appropriate. ... View more

The Legend widget in the ArcGIS JavaScript API (Both 3.18 and 4.1) seems hardcoded to always place low values at the bottom and high values at the top, regardless of the order in which they are configured in a map service. Cartographic authorities suggest that there isn't a correct order - valid arguments may be made for either sort order, at the discretion of the cartographer and the intended message. And some cartographers feel very strongly about the order in which their legend appears, and are unnerved when that order is reversed when incorporated into a mapping application or viewed in ArcGIS Online. We'd like to request that either the legend follow the order set in a map service, or that ArcGIS Online users (and developers using the API) be given the ability to set the legend class order they feel is most appropriate. ... View more

In version 1.x of WebAppBuilder popups seemed to be handled by the AttributeTable\Widget.js code, and by adding a little bit of code to the jimu/InfoWindowAction section of that Widget.js file we were able to execute a little bit of JavaScript code after a popup had been rendered to enhance and improve aspects of the popup. It was a bit of a hack, but it worked - happy to share more details if anyone's interested. In version 2.0 of WebAppBuilder, though, it appears as if all of the popup rendering is performed using code from the JavaScript API - js.arcgis.com, specifically esri/dijit/PopupRenderer - so our hack won't work unless we were to pull that code locally, and we'd really prefer not to do that. Instead we're trying to do things the right way - by using Dojo Inheritance to extend the PopupRenderer class.  dojo/_base/declare — The Dojo Toolkit - Reference Guide We know that any extension has to occur after the API has been loaded, so we're working within the dynamic-modules/postload.js file, which does seem to be executed at the right time.  Our very simple code block is here: define(['esri/dijit/PopupRenderer'], function(popupRenderer){     return popupRenderer.extend({         _handleComponentsSuccess: function(){             this.inherited(arguments);             console.log("success");         }     }); }); According to our understanding, this inherits the existing PopupRenderer class, it then returns an extended version of that class with an altered _handleComponentsSuccess function, and this.inherited(arguments); is the technique to use to call the superclass method (so we don't overwrite it). In practice, everything about this code works except for that calling of the superclass method - a "success" is logged to the console every time a popup is supposed to be rendered, but the internal content of the popup is never populated - the original _handleComponentsSuccess code is never executed (We've tried extending the .startup function as well).  So what are we missing?  Is there a different way to extent esri dijits? Or are we misunderstanding the concept of Dojo inheritance? Or is WebAppBuilder just a different ballgame? If we can get this right, it seems like it should be a really elegant way to perform small enhancements.  Thanks in advance. ... View more

For years web developers have been able to interact with the fantastic Dynamic Layers functionality of ArcGIS Server services to alter the symbology of services on-the-fly, but users of Esri's flagship desktop software have been denied the same ability.  We've given up hope for this functionality to be included in ArcGIS Desktop, and were disappointed when the final release of ArcGIS Pro also lacked this feature.  Please, it can't be that hard.  ... View more

Both the SOAP and REST interface for ArcGIS Server services natively support a spatial filter on the query method, and have since version 9.3.1. http://services.arcgisonline.com/ArcGIS/SDK/REST/index.html?query.html But the ArcGIS Explorer SDK ServiceChildLayer.Query method only accepts a simple attribute whereclause. http://help.arcgis.com/en/arcgisexplorer/1500/sdk/componenthelp/index.html#/Query_Method/000300000tw8000000/ It seems as if all the power in ArcGIS Explorer is with FeatureLayers, and it's great that you can create in-memory FeatureLayers from services, but debilitating that in order to perform a spatial query on a service layer (something that service natively supports if query is enabled) in ArcGIS Explorer, you have to first select ALL of the service layer's features (up to the QueryFeatureLimit, of course) into a FeatureLayer and then perform the spatial query.  Any workarounds or recommendations? ... View more

Hi JavaScript API folks, According to the documentation of a GraphicsLayer,: http://help.arcgis.com/en/webapi/javascript/arcgis/help/jsapi/graphicslayer.htm Graphics layers can be reordered within the group of graphics layers. However, the graphics layer in Map.Graphics is always on top. Also, all graphics layers are always on top of TiledMapServiceLayers and DynamicMapServiceLayers. This isn't quite true.  On the page, Graphics Layers seem to end up in the following element: <svg width="821" height="656" style="overflow: visible; position: absolute; z-index: 20;" id="mapDiv_gc">...</svg> which as best I can tell is hard coded with a z-index of 20.  Fine, as long as you never have more than 21 map layers, since other map layers appear to be added with ascending z-index values.  For those of us just nutty enough to add more than 21 layers, though, our graphics get buried.  The z-index value isn't all that difficult to change after the fact with a dojo.style('mapDiv_gc','zIndex',40); command, but should this really be necessary - especially when the documentation is so adamant about graphics layers always being on top of other layers?  Thanks so much! ... View more