POST
|
Austin, Thanks for posting the suggestion. This will be discussed and evaluated in the near future.
... View more
08-11-2015
10:58 AM
|
0
|
0
|
550
|
POST
|
Yes, there are many good use cases for subsurface capabilities. It will be supported by the time 4.0 moves out of beta. We're just don't have a timeline on when it could be released while we're still in beta.
... View more
08-11-2015
10:56 AM
|
0
|
1
|
842
|
POST
|
In 4.0 beta1, there is no support to permit the camera to go below the surface. It's being discussed for future releases. Keep an eye out for more information related to this in the future.
... View more
08-10-2015
04:35 PM
|
0
|
4
|
842
|
POST
|
Chris, Tim is correct. If you can't find it in the API reference, then there is no current support. The features you're familiar with in 3.14 will eventually be integrated into 4.0 by the final release next year.
... View more
08-10-2015
04:14 PM
|
1
|
0
|
560
|
POST
|
Hi Josh, If a class is not documented in 4.0, it is not supported. You can certainly try to use the class, but it isn't recommended. DynamicLayer does not perform as expected. For that reason it is not documented in beta1. It will eventually be supported in a future beta release. Information related to the current state of the API is found it the API reference. At the moment, we do not have a page dedicated to what we expect to develop and release in future betas since this changes often. As of now, you can expect nearly everything in the current 3.14 API to be included in the final 4.0 release (with the exception of deprecated classes like Geocoder). Regarding your last question, do we expect the code in 4.0beta1 to work against the final 4.0 release? That would certainly be ideal, but we cannot promise that all code structure will remain the same. That's one of the reasons we are releasing in beta - because the code base isn't completely stable yet.
... View more
08-10-2015
04:05 PM
|
1
|
0
|
632
|
POST
|
I should have noticed the proxy extension. Sorry about that. 😕 Try using the urlUtils like you do in 3.14. The import is different though: It's now "esri/core/urlUtils". This isn't documented, which means things can change in beta2, so keep an eye out for doc updates related to this in the future betas.
... View more
08-06-2015
01:37 PM
|
0
|
3
|
765
|
POST
|
Did you include the URLs you want proxied in your proxy.config file? Which proxy are you using, PHP, DotNET, or JSP?
... View more
08-06-2015
12:00 PM
|
0
|
5
|
765
|
POST
|
You should only expect updates coming with each beta release.
... View more
08-05-2015
10:51 AM
|
0
|
0
|
1234
|
POST
|
Cees van Altena Yes, this is a bug. However, you can also set the height of the view directly in the MapView constructor (view.height). Here's a link to the doc: https://developers.arcgis.com/javascript/beta/api-reference/esri-views-MapView.html#height. When you set the height inside the constructor instead of CSS, it seems to work as expected in your sample. View my bin here demonstrating this: JS Bin - Collaborative JavaScript Debugging This can be a current work around to your issue, although setting the CSS directly should work as well.
... View more
07-30-2015
02:11 PM
|
1
|
0
|
462
|
POST
|
Hi Gary, No, this is not supported at the moment. This is a concept we'll be discussing though and will let you know about future plans.
... View more
07-29-2015
03:19 PM
|
2
|
1
|
635
|
POST
|
Hi Adam and Adam, The documentation on this is misleading and, in the cases you both brought up, contradictory. The reason for this is because the way these workflows are being designed has been changing and will continue to change as 4.0 progresses through multiple betas into the final product. The documentation reflects some of these changes over time, but isn't consistent with how things are now. We are updating it so that it will not be as confusing. featureLayer.graphicsCollection does not exist. The Migration page in the guide is wrong and will be updated soon. featureLayer.graphics exists, but as the original post mentions, doesn't actually do anything. This too will likely go away and accessing graphics on the view will change in the future. Stay tuned for documentation updates explaining this. There are a number of reasons featureLayer.graphics will no longer be used, the primary reason being that features are no longer rendered on the layer or the map; rather, they are rendered in the LayerView and View. This is a major difference between our 3.x and 4.x APIs, so keep a look out for updated documentation, blogs, etc that go into greater depth explaining these concepts and classes. In the interim you can access the graphics displayed in the view via the 'graphics-controller-create' event on the featureLayer. This is undocumented, but will be later. The event object has a graphicsController property, which is an object that has a graphicsCollection property. See this jsbin for an example of accessing the graphics using one of our existing samples: JS Bin - Collaborative JavaScript Debugging I hope this helps!
... View more
07-29-2015
03:10 PM
|
2
|
3
|
1234
|
POST
|
Yes. We plan on supporting the ability to switch the Map's spatial reference in 4.0. It's not there yet, but it will be explored. As of now, it looks like this will only be possible with Maps that have NO basemap. The SpatialReference of the map and all of the dynamic layers and FeatureLayers would reproject after changing the SpatialReference directly on the Map.spatialReference property. map.spatialReference = new SpatialReference( {wkid: 4326} ); //or some other spatial reference object
... View more
07-24-2015
01:49 PM
|
1
|
1
|
2227
|
POST
|
How are you able to get the coded value from the queryResults? Is it the same field you tried referencing in the identifyResults?
... View more
07-16-2015
04:18 PM
|
0
|
1
|
1263
|
POST
|
Thanks, Akshay. In addition to understanding the differences between suggest() and findAddressCandidates(), I think the documentation currently doesn't do a good job at conveying the purpose of autoSelect. This will be updated so that it makes more sense. The purpose of autoSelect isn't to select the first suggestion, geocode it, and zoom to it. Rather, it is to geocode and zoom to the first result returned from entering the text exactly as it appears in the search box. This text is sent directly to findAddressCandidates() and doesn't necessarily return the same result as the top suggestion since both are sent to different endpoints. The suggestions listed below the text box as you type are merely that - suggestions. Those results will not be used to geocode unless you click on one of them or select it using your keyboard. Merely hitting enter will only take what is already inside the text box. autoSelect is set to true by default. If you set it to false, you will notice that the findAddressCandidates() function is called, but the top geocoded result is not selected or zoomed to. It is up to the developer to use the results however they want. The results can be accessed using the search-results event: Search | API Reference | ArcGIS API for JavaScript . autoSelect is true by default because in most cases the top result is what the user wants to zoom to.
... View more
07-07-2015
02:54 PM
|
2
|
1
|
942
|
Title | Kudos | Posted |
---|---|---|
1 | 08-20-2024 08:06 AM | |
1 | 08-13-2024 11:53 AM | |
1 | 07-22-2024 11:04 AM | |
1 | 05-16-2024 09:46 AM | |
1 | 04-25-2024 08:56 AM |
Online Status |
Offline
|
Date Last Visited |
10-10-2024
05:40 PM
|