|
POST
|
If it's the same issue, I ran into this one not too long ago with an application still using 3.14. In this case, it's a problem in xstyle, which is included in the ArcGIS API for JavaScript. For further reference, see this page. The code shown on that linked page is slightly different than what I've found included with 3.14 though. However, you can find the affected code in api\xstyle\css.js. In that file, the fix I applied in 3.14 was to change the text: a&&"none"!=a?b([eval(a)],d):d() to a&&"none"!=a&&"normal"!=a?b([eval(a)],d):d() Basically, I just added a second condition to check that the value of "a" did not equal "normal". Here's what a diff utility shows after formatting the before-and-after products:
... View more
06-07-2022
04:42 PM
|
1
|
1
|
1617
|
|
POST
|
The MapImageLayer class has a gdbVersion property that allows you to specify the version for the layer (FeatureLayer does too). Therefore, you would get the version name from the URL, and add it into the constructor for the layer. For example (assuming the name of the version parameter in your URL is "version"): var myLayer = new MapImageLayer({
url: "https://myserver/arcgis/rest/services/MyService/MapServer",
gdbVersion: new URLSearchParams(window.location.search).get("version")
});
... View more
06-06-2022
01:23 PM
|
1
|
0
|
623
|
|
POST
|
From the documentation: "To download the ArcGIS API for JavaScript and its documentation, navigate to the ArcGIS API for JavaScript download page and log-in with your Esri global account." I too use this to host the API on networks that have no internet access.
... View more
05-31-2022
04:03 PM
|
0
|
0
|
1554
|
|
POST
|
From your description, this appears to be a bug, but you shouldn't necessarily have to go through the effort of manually checking the vertices yourself. One possible workaround may be to clone the polygon, and check the property of the cloned object. Another workaround may be to call one or both of the following on the original geometry: geometry.notifyChange("rings");
geometry.notifyChange("isSelfIntersecting");
... View more
05-27-2022
01:41 PM
|
0
|
1
|
2262
|
|
POST
|
You can use bind in order to maintain a reference to your layer. For example: l_FeatureLayer.on("edits", otRilievi_Object.rilievi_edits_complete.bind(otRilievi_Object, l_FeatureLayer)); ...and elsewhere... this.rilievi_edits_complete = function(target, p_Features) {
//target is now a reference to the layer being edited
};
... View more
05-27-2022
09:53 AM
|
0
|
1
|
958
|
|
POST
|
I think what you're looking for is geometryEngine.contains: if (geometryEngine.contains(polygonGeometry, multiPointGeometry)) {
//do something
}
... View more
05-19-2022
03:39 PM
|
0
|
0
|
820
|
|
POST
|
The documentation states the height values are expected to be in meters. Therefore, it appears that if you have measurements in some other units, you'll need to convert those values to meters first.
... View more
05-18-2022
11:42 AM
|
0
|
0
|
516
|
|
POST
|
Assuming you already have a reference to the GraphicsLayer (graphicsLayer) and the rectangle (geometry) assumed to be a Polygon: var intersectingFeatures = [];
var extent = geometry.extent;
graphicsLayer.graphics.forEach(function(graphic) {
if (extent.intersects(graphic.geometry))
intersectingFeatures.push(graphic);
});
//now do whatever with the intersectingFeatures array
... View more
05-13-2022
12:53 PM
|
1
|
1
|
1544
|
|
POST
|
Note, this is only an issue when using (1) PictureMarkerSymbols with offsets, and (2) version 4.23 of the API. It works fine in 4.22. See also this post.
... View more
05-10-2022
10:26 AM
|
0
|
0
|
623
|
|
POST
|
My bad...I didn't actually try using the widget after making that change. It seems that in addition to what you have to hide the Select button, you could add the second selector shown below to get rid of the header as well: .esri-editor__update-features-action-buttons {
display: none;
}
div.esri-editor__scroller>div:first-child h5 {
display: none;
} I have actually tried going through the workflow with those, and it appears to work as expected.
... View more
05-05-2022
12:41 PM
|
2
|
1
|
2641
|
|
POST
|
Somebody can correct me if I'm wrong, but the visibility of that section doesn't appear to be configurable. Adding the following to the style tag of the "Edit features with the Editor widget" sample causes it to disappear though: div.esri-editor__scroller>div:first-child {
display: none;
} Perhaps you can work that selector (or something similar to it) into your application.
... View more
05-04-2022
04:13 PM
|
1
|
4
|
2665
|
|
BLOG
|
These are some great new features, and I'm continually impressed with the things that keep coming out each release. Many thanks to the team for all they continue to do to support us in turning out quality solutions for our customers. What I don’t doubt about 4.24 and subsequent releases is that they’ll continue to contain many powerful new features. What I do wonder about, on the other hand, is what they won’t contain. Although the "bonus track" in the original post isn't an official position, it does invite a particular discussion...specifically the part about some being "stuck on 3x", and therefore presumably not updating to 4x. For my part, I started making the jump with 4.16, and after a 6-month process, completed it, and released our framework with 4.18. The transition wasn’t the most pleasant experience, but still good and valuable nonetheless. But here’s the main point of this post: if I had waited until ESRI had migrated everything we needed from 3x to 4x, my organization would still be “stuck on 3x” to this day as well. For example, the 3x MapImageLayer, which we use heavily. I’m aware about this recent post which says it’s targeted for 4.24, but I still mention it because it’s part of the larger point. By now, this module has been “Coming Soon” for nearly five years. I worked around its absence by writing my own implementation (which works, although is not ideal), but that isn’t necessarily an option for everybody else needing it. Another example is the ScaleDependentRenderer. It was another one I had to create my own implementation for, during which I quickly discovered 4x unfortunately doesn’t support custom renderers like 3x did. Nonetheless, although one of your own recently said that implementing scale-dependent rendering in 4x is “super simple”, it’s been "Under Consideration" for years. Other things that’ve made me wonder: There hasn’t been a single item that’s made the jump in the functionality matrix in about a year. The 3x home page once plainly said 3x would be retired in August 2022, but that notice quietly disappeared a few months after it showed up. ESRI is still actively seeking to introduce people to the 3x-based Web AppBuilder with a recent “overview and concepts” blog that’s newer than the corresponding one for Experience Builder by 8 months. All that is to say, from my limited outsider perspective, we seem to be getting some rather mixed messages. Is 4x parity with 3x no longer a priority? If it still is, is it expected to be reached anytime soon?
... View more
04-29-2022
12:33 PM
|
1
|
0
|
706
|
|
POST
|
My bad, you are correct; this upcoming version looks like it's working properly in this regard. We'll stick with 4.22 for now, and look forward to 4.24.
... View more
04-22-2022
11:00 AM
|
0
|
0
|
2013
|
|
POST
|
Thank you for the reply. I'm not sure what the codepen is supposed to show though; the symbols aren't offset, and I don't think hitTest even comes into play. If a fix has already been applied in the "next" version, can you please tell me what modules have been affected? I see the aforementioned "draw" function has been updated, but simply applying those changes does not resolve the issue.
... View more
04-21-2022
06:58 PM
|
0
|
0
|
2041
|
|
POST
|
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
04-21-2022
01:21 PM
|
0
|
5
|
2095
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 12-09-2025 09:35 AM | |
| 2 | 12-09-2025 09:06 AM | |
| 1 | 11-26-2025 12:29 PM | |
| 3 | 11-26-2025 09:11 AM | |
| 1 | 10-02-2025 01:14 PM |