|
POST
|
With a layer file, you open it using ILayerFile and get the layer reference from the Layer property. Only one layer can be stored in a layer file. However, this layer may be a group layer so you'll need to handle that possibility.
... View more
03-26-2012
01:33 PM
|
0
|
0
|
2516
|
|
POST
|
Neil, VBA is available in 10.1. I have the licenses installed and have run it. Thanks for the correction. Looks like ESRI has had a change of plans.
... View more
03-26-2012
06:05 AM
|
0
|
0
|
1833
|
|
POST
|
Actually, I can get it to open a form, but the form is not "owned" by the application window, so it floats independently and can get hidden behind the application window or other windows if I'm not careful. I have found a grand total of ZERO help or discussion of this topic so far. Try searching the old forums: http://forums.esri.com/forums.asp?c=93 You probably won't find anything specific to add-ins but you'll find plenty of threads on ArcObjects and general programming questions. To display the form so that it floats on top of ArcMap but doesn't go behind it when the user clicks the main ArcMap window you need to call the overloaded Form.Show method and pass in the form's owner. The owner reference must be of type IWin32Window. ArcObjects doesn't expose a reference to the actual window but you can create your own class that implements IWin32Window as shown below. Public Class ModelessDialog
Implements System.Windows.Forms.IWin32Window
Private hwnd As System.IntPtr
''' <summary>
''' Returns the form handle.
''' </summary>
''' <value></value>
''' <returns></returns>
''' <remarks></remarks>
Public ReadOnly Property Handle() As System.IntPtr Implements System.Windows.Forms.IWin32Window.Handle
Get
Return hwnd
End Get
End Property
''' <summary>
''' Constructor.
''' </summary>
''' <param name="handle">The form handle passed as an IntPtr</param>
''' <remarks></remarks>
Public Sub New(ByVal handle As System.IntPtr)
hwnd = handle
End Sub
''' <summary>
''' Constructor.
''' </summary>
''' <param name="handle">The form handle passed as an integer</param>
''' <remarks></remarks>
Public Sub New(ByVal handle As Integer)
hwnd = CType(handle, IntPtr)
End Sub
End Class
To show the dialog you create a new instance of this class and pass it in. All you need is a reference to the ArcMap application so that you can pass in its window handle to the class constructor. Dim form As New yourForm form.Show(New ModelessDialog(m_application.hWnd))
... View more
03-26-2012
06:05 AM
|
0
|
0
|
1833
|
|
POST
|
You're referring to the VBA editor, not Visual Studio. ESRI no longer supports VBA but I believe you can still contact them and get a license for it if you want to use it for ArcGIS 10. Starting with the 10.1 release, VBA will no longer be available.
... View more
03-23-2012
11:04 AM
|
0
|
0
|
1833
|
|
POST
|
I've never had to work with that many graphic elements before so these are all untested ideas... Are you deleting the elements by looping through the graphics container and calling the Reset method after each delete? If so, it's the call to Reset that is most likely slowing it down. Instead of deleting the elements within the loop, add them to a collection (and remove the call to Reset). Then loop through the collection and call DeleteElement. You might consider creating features on a feature layer instead of graphic elements. You'd then be able to delete via query by calling ITable.DeleteSearchedRows, which will be about as fast as you're going to get using ArcObjects. You might also try creating an FdoGraphicsLayer for the elements. According to the documentation, the FdoGraphicsLayer class also implements ITable, so you should be able to call DeleteSearchedRows on it. I'm not sure exactly how the query would look since a graphic element doesn't have attributes like a feature does. I've never done anything like this so you may find out that a lot of the methods on the interfaces the graphics layer implements are just not implemented. It would be some interesting R&D though.
... View more
03-22-2012
10:04 AM
|
0
|
0
|
1191
|
|
POST
|
Well, considering Interfaces have no implementations, that would be alot of the time for us. Having an instance of a class is generally the only way you can use most of the Interfaces, which is why us Java people start with classes that are concrete and then see what Interfaces a class implements. Very true, you can't work with any interface without using a class that implements it. However, when it comes to learning ArcObjects I think it's much easier to focus on tasks. Interfaces define the functionality that is available. Instead of trying to learn everything that a Polygon class can do, it's simpler (at least to me) to break it down into such things as "how do I set z-values on a geometry". If you learn what functionality is provided by an interface, such as IZAware, then you've learned specific functionality that applies a good number of actual classes (i.e. not just the Polygon class). Practically everything I do is task driven - my program needs to do A, B and C. I ask myself what interfaces provide that? I then look at those interfaces to see what classes I need. It's all a matter of perspective I suppose, but for me, I think of the interfaces first. Of course, I've been doing this for 12 years now so I do a lot of things without thinking at all 😉
... View more
03-22-2012
06:44 AM
|
0
|
0
|
1339
|
|
POST
|
Maybe I'm different from other developers but when it comes to ArcObjects I don't think in terms of classes. I think in terms of interfaces. About the only time I actually think about what class I'm working with is when I need to create a new instance of it. After that, it's all interfaces. If you learn the interfaces then all you really have to do is look up the class you're working with to see if it implements the interface(s) that you need. If it doesn't, then you look up the interface to see what class you need. That's how I do it anyways.
... View more
03-22-2012
05:54 AM
|
0
|
0
|
1339
|
|
POST
|
Use IFeatureClass.CreateFeature to create the new feature. Use IFeature.Shape to set the geometry and use IFeature.Store to save it.
... View more
03-20-2012
05:51 AM
|
0
|
0
|
734
|
|
POST
|
In my opinion, it's a bug. The same thing happens in ArcMap if you use the drawing tools to create a line element and set the symbol to be a dashed line with a width greater than 1. As far as I know, it's always been that way so I'm guessing ESRI doesn't have any plans to fix it.
... View more
03-20-2012
05:47 AM
|
0
|
0
|
1036
|
|
POST
|
It depends on the symbol type - for fill symbols use IMultiLayerFillSymbol.
... View more
03-19-2012
05:24 AM
|
0
|
0
|
1191
|
|
POST
|
Did you install the ESRI SDK? If so, did you install the SDK after installing Visual Studio?
... View more
03-19-2012
05:20 AM
|
0
|
0
|
1113
|
|
POST
|
Our applications are implemented as extensions. Inside IExtension.Startup() is the following call: System.Windows.Forms.Application.EnableVisualStyles() When I was debugging the problem, commenting out this line would cause the icons in the GxDialog to come back. We opted to enable visual styles and just let the GxDialog not have any icons (we only use it in a few places so it's no big deal). But, like I said earlier, I no longer seem to have this problem on my development machine. So, it could be an issue with the operating system. You're running XP 32-bit and I'm running Vista 64-bit. I'm pretty sure that when I was debugging this issue that it was back when my development machine was running XP.
... View more
03-16-2012
07:35 AM
|
0
|
0
|
1093
|
|
POST
|
The help states that the class requires the 3d Analyst extension. That's different than requiring a 3d Analyst license. Not all of the objects in the 3d Analyst assemblies require any special licensing but in order to access and use them the assemblies for the extension must be installed. I'm not very familiar with Engine as I don't use it much so I don't know if those assemblies are installed as part of the core product or not. If they are, then I would say you don't have much need to worry. When I first began programming with ArcObjects there weren't any resources to help developers like there are today - online resources website, sample code, tech articles, walkthroughs, etc. The developer help was just a *.chm file that contained nothing more than an inventory of the interfaces, classes, methods, etc. It didn't have any comments, remarks, guidance, etc. to help developers figure out how to use any of the ArcObjects classes. So, yes, it was difficult. What made it even worse was the fact that there were many more bugs in the software than there are today. So, many times I would be trying to figure out how to get something to work only to find out after several days that my code had been correct all along and it wasn't working because of a bug in the ESRI code. After you've worked with the ArcObjects object model for awhile, things get much easier. The biggest hurdle most developers face is simply not knowing what interfaces and classes they need to be using for a specific task. Once you get familiar with ESRI terminology and naming conventions you tend to find those things a lot quicker. It also helps if you have a good memory. In the beginning I did a lot of searching through that skeleton help document and in doing so I read the names of a lot of interfaces and classes. Later on, when faced with a new task I'd remember seeing things that sounded like what I might need for that new task. The ArcObjects library is huge. I don't know what the count is up to now but at one time I believe the number of interfaces, classes, enums, etc. was around 30,000. It just takes time to get familiar with all of that. Using Google and the ESRI help site is the best way to find what you need. I would also recommend going to the old user forums and searching there first (I don't think the current search includes those forums). There's a decades worth of information on the old forums and while most of the code you'll find will be in VB6/VBA, I think it'll help. The key is figuring out the keywords to search with. You'll get better at that as you go. And, I don't think you'll be able to use IDataGraphT. A good rule of thumb, if it comes from an assembly whose name ends with "UI", it's Desktop only. Sorry, I should have caught that. You'll have to use a 3rd party graphing control or use the native Microsoft libraries like you mentioned.
... View more
03-16-2012
06:09 AM
|
0
|
0
|
2443
|
|
POST
|
Yes, in order to project the data into a specific spatial reference you have to know what spatial reference it's in to begin with. That's something that will have to be provided for you, not something that you can determine based on just the coordinate values you have.
... View more
03-16-2012
05:32 AM
|
0
|
0
|
729
|
|
POST
|
It may be possible to speed things up... If you're using ArcObjects in a .NET application it will be inherently slow because .NET does not natively support COM. In order to use ArcObjects you have to go through COM Interop which will slow down any ArcObjects method call (not to mention that .NET is just slower in general than some other language platforms). One solution is to write the code that needs to execute quickly in a language that natively supports COM (such as C++ or VB6) and compile that into a dll that you can call from your .NET application. Another solution is to code the needed algorithms yourself. ESRI supports a wide variety of datasources, platforms, etc. so their code cannot be written for a specific environment and therefore may not run as efficiently as it could if it were written for something specific. Depending on what datasource you're using, you may be able to write your own code that takes advantage of shortcuts specific to that data format (or find code on the internet).
... View more
03-16-2012
05:30 AM
|
0
|
0
|
2173
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-20-2014 05:29 AM | |
| 1 | 02-01-2011 04:18 AM | |
| 1 | 02-04-2011 04:15 AM | |
| 1 | 01-17-2014 03:57 AM | |
| 1 | 10-07-2010 07:37 AM |
| Online Status |
Offline
|
| Date Last Visited |
11-11-2020
02:23 AM
|