Latest Contributions by JoelBennett

A new bug in the 4.23 MapView.hitTest operation does not take into account the offsets a PictureMarkerSymbol (and perhaps other symbols) might have, particularly when these symbols are used to render features in a FeatureLayer. The image below, although admittedly rough, illustrates the issue: As can be seen, the hitTest region is the same size as the image, but has not been offset properly. This leads to unexpected and confusing behavior in some of our applications. I’ve investigated the issue as best I can, but it’s getting to the point where further progress is going to take too much time from more important things. I’ve gotten as far as the draw method of esri.views.2d.engine.webgl.effects.HittestEffect, but I can’t tell if the problem is within the logic of that function, or the graphics context it’s querying. I can see it’s been substantially changed from the 4.22 version though. In looking for other solutions, I’ve found that PopupViewModel.fetchFeatures works properly in this regard, but it doesn’t appear to be suitable for the same kinds of use cases that hitTest is designed for. Because I can’t produce a suitable workaround for this issue, which I believe would be too detrimental to our users’ experience, I’m going to be forced to reject 4.23 altogether. Can we get a fix for this, or will we have to wait until 4.24 is released (plus 3 additional weeks to download)? ... View more

A new bug in 4.23 causes the MapView.zoom property to read incorrectly as -1 when the (1) constraints.lods and (2) extent properties are specified in the constructor. I noticed this new section titled “Zoom and LODs” appeared in the 4.23 documentation, but I’m not doing anything contrary to it to warrant this issue. To view this in action, go to the Sandbox for the “Into to MapView – Create a 2D map” sample. When there, change this code: const view = new MapView({ container: "viewDiv", map: map, zoom: 4, center: [15, 65] // longitude, latitude });   to this (it's a little long, but mostly just LODs): const view = new MapView({ container: "viewDiv", map: map, constraints: { lods: [ { level: 0, resolution: 156543.033928, scale: 591657527.591555, alias: "World (1:591,657,527)" }, { level: 1, resolution: 78271.5169639999, scale: 295828763.795777, alias: "World (1:295,828,763)" }, { level: 2, resolution: 39135.7584820001, scale: 147914381.897889, alias: "World (1:147,914,381)" }, { level: 3, resolution: 19567.8792409999, scale: 73957190.948944, alias: "Continent (1:73,957,190)" }, { level: 4, resolution: 9783.93962049996, scale: 36978595.474472, alias: "Continent (1:36,978,595)" }, { level: 5, resolution: 4891.96981024998, scale: 18489297.737236, alias: "Countries (1:18,489,297)" }, { level: 6, resolution: 2445.98490512499, scale: 9244648.868618, alias: "Country (1:9,244,648)" }, { level: 7, resolution: 1222.99245256249, scale: 4622324.434309, alias: "States / Provinces (1:4,622,324)" }, { level: 8, resolution: 611.49622628138, scale: 2311162.217155, alias: "Counties (1:2,311,162)" }, { level: 9, resolution: 305.748113140558, scale: 1155581.108577, alias: "Counties (1:1,155,581)" }, { level: 10, resolution: 152.874056570411, scale: 577790.554289, alias: "County (1:577,790)" }, { level: 11, resolution: 76.4370282850732, scale: 288895.277144, alias: "Metropolitan Area (1:288,895)" }, { level: 12, resolution: 38.2185141425366, scale: 144447.638572, alias: "Cities (1:144,447)" }, { level: 13, resolution: 19.1092570712683, scale: 72223.819286, alias: "City (1:72,223)" }, { level: 14, resolution: 9.55462853563415, scale: 36111.909643, alias: "Town (1:36,111)" }, { level: 15, resolution: 4.77731426794937, scale: 18055.954822, alias: "Neighborhood (1:18,055)" }, { level: 16, resolution: 2.38865713397468, scale: 9027.977411, alias: "Streets (1:9,027)" }, { level: 17, resolution: 1.19432856685505, scale: 4513.988705, alias: "City Block (1:4,513)" }, { level: 18, resolution: 0.5971642835598172, scale: 2256.994353, alias: "Buildings (1:2,256)" }, { level: 19, resolution: 0.29858214164761665, scale: 1128.497176, alias: "Building (1:1,128)" }, { level: 20, resolution: 0.1492910708899543, scale: 564.248588, alias: "Houses (1:564)" }, { level: 21, resolution: 0.0746455354449772, scale: 282.124294, alias: "Houses (1:282)" } ], rotationEnabled: true, snapToZoom: true }, extent: { xmin: -17576195, ymin: 2427634, xmax: -17573701, ymax: 2429488, spatialReference: { wkid: 3857 } } }); view.when(function () { alert(view.zoom); view.notifyChange("zoom"); alert(view.zoom); });   Then click the Refresh link at the top right of the page. You will see two alerts: -1 and (probably) 15. To see that this is specific to 4.23, go to the top of the code, and change the “link” and “script” tag urls to use 4.22 instead. After clicking Refresh again, you’ll receive two more alerts: 15 and 15.  This demonstrates that what once worked in 4.22 no longer works in 4.23. When I usually report these things, I try to show where in the API the problem happens, but I’m not able this time. However, I do have a workaround for AMD-based solutions with a locally hosted API. In esri/views/MapView.js, search for: this._set("ready",!0) and then replace with: this._set("ready",!0);this.notifyChange("zoom")   ... View more

Not listed in the breaking changes for the 4.23 release is that svg elements generated by the symbolUtils. renderPreviewHTML function now have their css display explicitly set to “block”. Previously this property was not set, and defaulted to the value of “inline”. As can be seen in the image below, this makes a substantial difference in how they’re laid out on the page, which the browser's Developer Tools help show: 4.22 vs 4.23 This image shows a custom symbol selector that allows a user to visually specify the value for a field associated with a UniqueValueRenderer when specifying a feature’s attributes. It uses a simple table where each cell is supposed to be center-aligned, but changes made to 4.23 throw it off. I can’t think of a good reason why every image generated by renderPreviewHTML should be displayed as a block. If we wanted to do something as unusual as that, we could do it ourselves by wrapping it in a div, or better yet, adding our own CSS selectors. To get around this now, though, we either have to add application logic to set it back to inline, or add a CSS selector with an “!important” rule, neither of which is desirable. Since we host a local copy of the JSAPI, I prefer just to prevent the addition altogether. The following shows how to do this for AMD-based solutions. Although the issue is found within the esri/symbols/support/svgUtils module, we made the change in the esri/widgets/Legend.js file since we use the Legend widget and it already contains a copy of that module. In esri/widgets/Legend.js, search for: {xmlns:"http://www.w3.org/2000/svg",width:C,height:G,style:"display: block;"} Replace with: {xmlns:"http://www.w3.org/2000/svg",width:C,height:G/*,style:"display: block;"*/}   ... View more