Latest Contributions by JoelBennett

New to the 4.21 ArcGIS API for JavaScript is a bug that occurs when using click-based tools in the SketchViewModel module.  In particular, it occurs whenever the create method is called with createOptions.mode being set to "click", regardless of geometry type.  The problem itself is that a click from any mouse button is treated the same as a left-click. This can be seen in the sample "Edit features with the Editor widget".  Select any feature type to create, and you can place or draw the feature the same way by using any mouse button.  If you use the sandbox to change the version to 4.20, only left-clicks are used to place or draw as one would expect. This is not a problem for all workflows, but is for some.  For example, in one workflow, the create tool is repeatedly activated after each feature is created, so the user can continue creating features without manually clicking to activate every time.  At any time, the user may want to right-click an existing feature in the same or different layer, and choose from various actions in a right-click menu.  However, in 4.21, the right-click no longer results in a context menu being shown, but a new feature being unexpectedly created. If you have a locally hosted copy of the API, my recommended workaround is to make the following change in the esri/views/draw/DrawOperation module: Search for: f._onImmediateClick=function(a){   Replace with: f._onImmediateClick=function(a){if(a.button!==0)return;   ... View more

Starting in 4.19, and including 4.20, setting the effect property on instances of ImageryLayer has no effect.  This can be verified in the sandbox for the sample Intro to ImageryLayer.  In the constructor for the layer on line 39, you can add an effect property like so:   const layer = new ImageryLayer({ effect: "grayscale(100%)", url: "https://sampleserver6.arcgisonline.com/arcgis/rest/services/NLCDLandCover2001/ImageServer", format: "jpgpng" // server exports in either jpg or png format });     When you refresh the sample using the Refresh button at the top-right of the page, you see the layer in full color as before.  Now, go to line 16 and change the API version to 4.18 like so:   <script src="https://js.arcgis.com/4.18/"></script>     When you refresh the sample again, the layer now renders in grayscale, as it should.  Other 4.19 layer types, like FeatureLayer, MapImageLayer, and TileLayer work just fine in this regard; the issue seems limited to ImageryLayer. I can't fully explain the issue, as I don't fully understand it, but the following workaround is working for me in version 4.19 (I'm unable to verify it in 4.20 since it's not available for download yet).  If you have a locally hosted copy of the API, make the following change in esri\views\2d\layers\ImageryLayerView2D.js: Search for:   this.watch("timeExtent",()=>{   Replace with:   this.watch("layer.effect",()=>{this.subview.container.effect=this.get("layer.effect")}),this.watch("timeExtent",()=>{     ... View more

Although an issue with incorrect symbology was fixed in the 4.19 Legend widget, the fix has caused new problems of a different nature. Starting in version 4.19, the Legend widget will send numerous, duplicated requests to retrieve the symbology for the same map service. In particular, for instances of MapImageLayer and TileLayer, it will send a legend request for each visible sublayer in the service (or each sublayer regardless of visibility, if respectLayerVisibility is false). These requests have the exact same URL, and the exact same response, and are therefore duplicated and wasteful. All the Legend samples in the SDK involve instances of FeatureLayer, which don't exhibit this problem. However, to reproduce the issue, you can go to the Sandbox for the Legend widget sample, and replace the code within the second script tag with this: require(["esri/views/MapView", "esri/widgets/Legend", "esri/WebMap"], function(MapView, Legend, WebMap) { var webmap = new WebMap({ portalItem: { // autocasts as new PortalItem() id: "ab51d5972c4f4c5282ebae7a24d4fcf6" } }); var view = new MapView({ container: "viewDiv", map: webmap }); view.when(function() { webmap.layers.forEach(function(layer) { if (layer.sublayers) layer.sublayers.forEach(function(subLayer){subLayer.visible=true;}) }); var legend = new Legend({ respectLayerVisibility: false, view: view }); // Add widget to the bottom right corner of the view view.ui.add(legend, "bottom-right"); }); });   After replacing the code, open your browser's developer tools, and then in the browser window, click the "Refresh" button at the top-right of the page (note, this is a button in the page itself, not the browser's refresh button). By watching the network tab in your browser's developer tools, you'll watch the browser go berserk with legend requests. By my count, it makes nearly 260 legend requests to do what could be done with only 16. If you zoom in, you'll watch even more legend requests being sent for information the application already has. The Legend widget has a cache, which is intended to prevent this kind of waste. However, as with the previous problem that resulted in incorrect symbology, it's the keys for this cache that are once again the culprit. Last time, they weren't "unique enough"; this time they're "too unique". My suggested fix previously involved using keys based upon the layers' url property, and once again it appears to solve this new problem as well. My workaround for 4.19 involves 3 find-and-replace operations in esri/widgets/Legend.js; the first two implement the use of layer URLs in the cache keys (rather than layer UID and sublayer ID), and the third prevents additional duplicated requests by using the cache to store promises (in addition to the legend responses it normally stores).   Part 1: Search for (in function buildLegendElementsForTools): this._getLegendLayers(`${a.uid}-default`) Replace with: this._getLegendLayers(`${a.url}-default`)   Part 2: Search for (in function _generateSymbolTableElementForSublayer): this._getLegendLayers(K||`${this.layer.uid}-${a.id}-default`,K) Replace with: this._getLegendLayers(K||`${this.layer.url}-default`,K)   Part 3: Search for (in function _getLegendLayers) return r?Promise.resolve(r):this._legendRequest(g) Replace with: return r?((r.constructor==Promise)?r:Promise.resolve(r)):xa[a]=this._legendRequest(g)     ... View more

The interactive geometry-editing utility of the SketchViewModel will not work if the view's extent is not normalized. This can be verified in the sample "Edit features with the Editor widget" with the following steps: Load the sample. Pan east (or west) until you go all the way around the world. This will go much faster if you zoom way out, pan, and then zoom back in to the editable features. In the "Editor" widget, click "Edit feature". Click on a polygon feature; this puts the feature into interactive geometry-editing mode. Move the mouse cursor over the rotation handle; note that rotation handle doesn't become highlighted like it should. Click and drag on the rotation handle; the feature is not rotated, and the map is panned instead. The same occurs if you attempt to use the resize handles or drag the feature to a new location. This was observed in 4.18 and 4.19; I don't know if it worked in previous versions or not. I haven't attempted to troubleshoot the API code itself. Instead, my current workaround is to detect if the view's extent is normalized before using the SketchViewModel, and if it is not, to normalize it before allowing further action to take place. ... View more