Latest Contributions by JoelBennett

Yes, looking at it more closely, you're better off setting up the API locally and tweaking the one file.  Trying the inline fix actually gets pretty nasty...those two functions are full of required modules...for example, in _legendRequestServer, I can see that: c = dojo/_base/lang l = dojo/json d = dojo/_base/array w = esri/request There's more in the _buildRow_Tools function as well.  It's possible to work with this, but very ugly, so I wouldn't recommend it.  I apologize for sending you down that trail without fully thinking it through. ... View more

Could you post the relevant portions of your code with the modifications included?  In the case that it is correct, there may also be some additional requires I didn't think of initially. ... View more

The preferred solution would be to get the API and host it yourself if possible and then make those tweaks...see the bottom of: Get the ArcGIS API for JavaScript | Guide | ArcGIS API for JavaScript If that's not an option, a less elegant solution would be to add "esri/dijit/Legend" to your require list.  Then, right before your line: var llWidget = new LayerList( you could put Legend.prototype._legendRequestServer = function(a) {      //all the same code as the original _legendRequestServer function      //except with the tweaks mentioned in the other thread } and also Legend.prototype._buildRow_Tools = function(a, b, c, d, e) {      //all the same code as the original _buildRow_Tools function      //except with the tweaks mentioned in the other thread } You can get the original code for the legend class by downloading https://js.arcgis.com/3.16/esri/dijit/Legend.js ... View more

The Legend dijit is known to hiccup on layers having ?token= in their URL under some circumstances.  If you use your browser's developer tools to monitor the network traffic, particularly for the legend request, and notice that "?token=" appears twice in the URL, there is a known workaround. If you have a locally hosted version of the API, you can tweak the esri/dijit/legend.js file to get around this issue.  I discussed this in a separate thread at: https://community.esri.com/thread/122680#comment-463137 Note that I wrote that up for version 3.12...if you have a different version of the API, the variable names could be different. ... View more

No, I would only do that if there was no way around a bug.  More than once, I have reported bugs to ESRI the official way, along with how to fix them, but in vain.  I'm not willing to do that anymore. My purpose here is to keep other developers who run into these problems informed that (1) the problems do exist, (2) it's not their fault, and (3) there are known workarounds. ... View more

ESRI did not fix this bug in version 3.16 of the ArcGIS API for JavaScript. ... View more

ESRI did not fix this bug in version 3.16 of the ArcGIS API for JavaScript. ... View more

ESRI did not fix this bug in version 3.16 of the ArcGIS API for JavaScript. ... View more

What you are doing (aside from the aforementioned typo) is correct...so it may be a problem with the ID value you're passing.  If you're using ASP.NET or something similar, an ID you assign can be transformed with an added prefix. In place of the line you have, try this below.  It'll let know what the actual ID is if this is the case.  If you get the "element not found" alert, then it couldn't find the checkbox at all, which is a different problem altogether... var inputs = document.getElementsByTagName("INPUT"); var found = false; var input; for (var x = 0; x < inputs.length; x++) { input = inputs ; if ((input.type) && (input.type.toLowerCase() == "check") && (input.id.indexOf("slrbxC") >= 0)) {   input.checked = false;   alert("Set...id = [" + input.id + "]");   found = true;   break; } } if (!found) alert("element not found..."); ... View more

Just for posterity, this was fixed in 3.13.  ESRI made no mention of it that I know of. ... View more

This is still a problem in 3.15, although the scope has probably never been as wide as I initially reported (i.e. "any instances").  The problem only manifests if supplying "resourceInfo" to the constructor, and the "serviceMode" is "RESTful" (which is the default value if not specified). The fix is nonetheless the same...the instantiation of _formatDictionary should be moved higher up in the constructor...it could even be the first line if desired. This is because the call stack of the constructor can reach the _getTileUrlTemplate function (by way of _parseResourceInfo), where the _formatDictionary is referenced, which in turn throws an error about using an undefined reference. ... View more

This was fixed in 3.15, eliminating the need for a workaround.  In their "What's new in Version 3.15" document, notice the entry: BUG-000088231: Fixed an issue when using map.setExtent's fit option did not work as expected. Although the link below will probably only work as long as 3.15 is the current version, see also: What's new in Version 3.15 | Guide | ArcGIS API for JavaScript ... View more

This still hasn't been fixed in 3.15.  I've attached a document illustrating what's happening. It is this line in the _coremap module that's causing the problem: if (!b || Math.abs(c.origin[0] - b.origin.x) > c.dx) this.wrapAround180 = !1; The comparison between origin values of WGS 84 and Web Mercator results in wrapAround180 being forced to false. ... View more