|
POST
|
The following code varpane = FrameworkApplication.DockPaneManager.Find("esri_editing_AttributesDockPane"); pane.Pin(); pane.Activate(true); Will throw the following exception System.AggregateException HResult=0x80131500 Message=A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. Source=mscorlib StackTrace: at System.Threading.Tasks.TaskExceptionHolder.Finalize() Inner Exception 1: NullReferenceException: Object reference not set to an instance of an object. Not one single line will cause the issue. It's like the code queue's up some tasks and when they run, it will delayed fail. Upon further inspection, the calling code does nothing, but when trying to open the pane it will then throw. The same thing seems to happen if the pane is visible if I comment out `Pin()` and/or `Activate(true)` it will still throw. I've had similar experience with using the show attributes button command. What is the proper way to display the attributes for a feature that has just been created so the user can directly start editing?
... View more
07-23-2018
06:26 PM
|
0
|
4
|
2005
|
|
POST
|
It would be really nice to be able to float (unpin) a docking pane and remove it's ability to be docked. Also it would be great to be able to center the window or place it's top left corner relative to other panes. I suppose I want a modal window that users can be prompted to perform an action and get the pane out of the way.
... View more
07-19-2018
05:27 PM
|
0
|
0
|
2315
|
|
IDEA
|
ArcGIS Server standardized SQL queries Allow standardize queries setting per service - not server These ideas have been open since 2013 and have not received any attention. If moving the standardized query setting to the service level is not something esri is interested in allowing then we need to make the standardized query rules customizable. Limitations of standardized queries Standardized queries are applied to the entire ArcGIS Server site; they cannot be enabled for some services and disabled for others. Standardized queries are not supported on joins between different workspaces. Additionally, database tables accessed through an OLE DB connection file are not supported. If your service data contains these sources, you'll need to use alternative methods for referencing your data. Subqueries as a where clause, for example, POP_2010 = (SELECT min(POP_2010) FROM counties are not supported. I think subqueries and database functions are a good option to start with since I would assume they are the most common reason to turn off standardized queries. Having a checkbox list of database functions to allow would be very helpful. And for subqueries an allowable template or a white list of queries is an option if it is not overly complicated. It is really problematic to disable standardized queries because one service needs to use a subquery or function.
... View more
05-30-2017
03:31 PM
|
7
|
2
|
1330
|
|
IDEA
|
The 3.x and 4.x javascript api's and their use of dojo loader plugins lock developers into using the dojo loader and the legacy dojo build system - or it places the burden on the developer to create custom module loader implementations. I would like to see esri support the interoperability of module loading moving forward so developers can use modern loading/build/bundling tools with the 4.x api's without a lot of friction. If this idea is accepted, developers cannot complain about the implementation details of the javascript api leaking into their workflows/technology decisions. The esri technology decisions of the api will be an implementation detail instead of an influence.
... View more
03-13-2017
11:59 AM
|
25
|
1
|
1660
|
|
POST
|
A side note; The application needs to be owned by the same user as the web maps being accessed otherwise authentication will be granted.
... View more
02-02-2017
10:46 AM
|
1
|
0
|
2402
|
|
BLOG
|
silly firefox. well, native methods aren't always faster on every browser. They also don't have feature parity with the 3rd party implementations. Anything lazy would be much more noticeable. Either way, here's a grain of salt.
... View more
12-24-2014
08:43 AM
|
0
|
0
|
842
|
|
BLOG
|
Native methods aren't always faster... native vs lodash · jsPerf
... View more
12-24-2014
08:33 AM
|
0
|
0
|
842
|