Dear Folks,
This is second consecutive time being Most Valuable Professional (MVP) on ESRI Forums. I take this opportunity to thank all those who have clicked ‘this post answered my question’ .
Thanks to all my team members, collegues, friends and organisation , for their support and encouragment throughout.
Long back I have also faced problem of images not being loaded in some of my machines which runs my MapObjects application. ImageLayer.Valid() method returns false in some occassions. I tried to find exact cause or probable causes for the issue. After giving enough try and searching forum, I learnt it may cause due to improper installation of MapObjects and it was suggested to MoRuntime.exe for avoiding these sorts of issue. This solution is helpful for few, but in mycase I couldnt figure the root cause. There is some internal issue with MO on loading this image predominatley in loading TIF format. ESRI should support major issues like this atleast!
Recently Brendan Lee & Maarten VanDenBroek facing similar trail. Maarten has found a cause and probable workaround of this issue. ”We were able to determine that the client software for Oracle 10 was causing the problem (at least in our case). The Oracle software somehow interferes with the MapObjects software and prevents it from opening the image catalog and reading TIFF files. When we changed our application to intialize the GIS (loading the layers thus forcing it to load all its DLL’s) BEFORE loading the Oracle client software DLL’s, the problem went away”
I’m glad to see one workaround for this issue. This is good finding. The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.
It shows exactly which DLL’s are loaded by the EXE at any given point to study his problem. Tools like this will certainly helpful for developers like us to understand the what happens behind the scene.
You can not (and should not) add records the attribute table of a shapefile outside of an application (such as MO) that is aware of the linkage between the attribute records and shape records.
To add a field to the attribute table you have a few options. The first is to create a new shapefile based on the old one with the new field added, then to copy all of the data from the old shapefile to the new shapefile using MO methods. This is the safest option, and can be done completely using MO methods. A second choice is to use a non-MO based tool (such as ADO) to add the field the to dBase file. You’ll need to make sure that no map layers refer to the shapefile BEFORE attempting this, but it does save the time/trouble of having to copy the data. Once the new field is added you can query and populate the field using MO methods.
One interesting note is that recordset Fields property returns random order of fields in a collection. If you want to access the fields in their actual physical order, then do not use the Recordset’s Fields property. Rather use the Recordset’s TableDesc Property. The only fields not in the TableDesc are the “Shape” field, and the virtual, internal “FeatureID” field. The only fields which show up in the TableDesc are the fields physically stored in the *.dbf portion of the shapefile.
Another point is that there is no direct method to DELETE any field in a shapefile or feature class using MapObjects.
MapObjects 2.2 was designed, tested, and supported for use with Visual Studio .NET (from 2002), which uses the .NET Framework v1.0. Unfortunately, it is not supported for use with Visual Studio 2005, which uses the .NET Framework v2.0. It may just work, but we have not tested it. For one, the MapObjects installer only knows how to look for the version 1.0 GAC, so at a minimum, you would have to do part of the installation manually, depending on how comfortable you are with modifying the development environment and the .NET framework.
Even the most recent version of MapObjects-Windows Edition, version 2.4 does not support Visual Studio 2005.
It is unfornuate that ESRI will end MapObjects Supports soon and discontinue the product.
Jim Barry of ESRI writes “We are sorry to report that free copies of MapObjects software are no longer available for evaluation.”
ESRI highly recommends that you consider using ArcGIS Engine if you want to use embeddable mapping and GIS components in your application’s design. The easiest and least expensive way to get the ArcGIS Engine developer kit is to subscribe to the ESRI Developer Network. More information here:
http://www.esri.com/software/arcgis/edn/index.html
Great product from ESRI finally ends in peace. I love MapObjects!
Here is PDF document for MapObjects in Delphi. MapObjects in Delphi
When I debug my MO application, I came across this issue that MapObjects returns NULL value as a zero. I was relating external .mdb table to shapefile and querying the records based on field from the table. The query passed to Search Expression returns the erroneaus recordset taking null values as zeros. I was puzzled to see the result, after through debugging I understood its MO problem. When I searched forum, I found detailed explanation on this issue from Mr. A.J. Romanelli . Below link helps you to understand the basic concept behind the problem.
In nutshell “The dBase specification (and thus shapefiles) doesn’t support null values for string fields, but null values are supported for numeric fields (numeric nulls are stored as null characters, not zero values). MO doesn’t support the dBase null value numeric, and returns the null values as zeros.”
http://forums.esri.com/Thread.asp?c=9&f=85&t=182395&mc=8#msgid541136
We need to use some other workaround for this problem.
What is Tracking layer?. MapObjects help says. “A TrackingLayer object represents a layer in a Map that depicts geographically referenced phenomena whose position may change. These phenomena are referred to as events, and are represented by GeoEvent objects.”
Its sound confusing right?, well, consider Tracking layer as virtual layer. For example, if you want add/draw shapes say, vehicle movements in vehicle tracking application, this comes handy. Not only restricted to dynamic objects, say when you query layer and draw the resultant features as tracking layer and export as shape file. In many circumstances tracking layer are useful for a developer.
Both the TrackingLayer’s Event property array and its Symbol property array can hold up to a “Long” integer’s number of shapes and symbols. This is approximately 2.14 billion. However, you will probably reach a practical limit before you get that high based on your system resources and its draw performance.
Hope this post gives you information about Tracking Layer object in MapObjects.
Geometrically, you might think that a polyline (Line class) or a polygon (Polygon class) is nothing more than an ordered collection of vertex points. However, in MO, the Line and Polygon classes support multiple parts. So in the object model, the collection of these parts is stored in the Line/Polygon’s Parts property. Each “part” is a collection of points–a Points collection object.
Imagine for a moment a donut polygon which has an outer ring of vertex points and an inner ring of vertex points. In this case, the Polygon object has a Parts property, and that Parts property contains two parts, that is, two Points collection objects. The first Points collection is an ordered collection of vertex points which make up the outer ring, and the second Points collection is an ordered collection of vertex points which make up the inner ring.
And, by the way, outer rings are always oriented clockwise, and inner rings must always be oriented counter-clockwise.
The FilterExpression property in MapObjects is meant to store a piece of ANSI SQL that will be used to set up a definition query on a layer. What this means is that the layer will consist of only those features which satisfy the FilterExpression.
As per the documentation, your expression should be that syntax which would normally follow the word “WHERE” in an SQL query, such as: “POP > 2000″
If no features satisfy the expression, none are returned and the layer is not drawn. To demonstrate this, set the FilterExpression to “1 = 0″ and you’ll get nothing back.
The values you are storing in the FilterExpression property are not valid statements and, therefore, they evaluate to FALSE, causing no features to be returned.
First, a clarification, SDE does not store shapefiles, you can load a shapefile into SDE, but the data is now stored in SDE, and will benefit from spatial and attribute indexes created in by SDE and the RDBMS.
Second, think of filter expression as analogous to a definition query in ArcView. You use search expression to search for features within a layer (or the subset of a layer if a filter expression is already applied).
Third, setting the filter order to moAttributeFirst may or may not improve your performance, this is directly related to the data you are viewing, and the extent at which you are viewing it. In some cases this will speed up your data retrievals, in others it will drastically slow them down. If you are not sure about your data, leave the default setting. If you are sure that the current extent of your data is such that a much smaller subset will be returned by the atttribute query than is contained within the spatial extent then setting moAttribute first will speed your queries. This setting works against you when you are zoomed into a small area where only a few records would be returned by the spatial extent, but many are returned by the attribute query.
Lastly, if you are going to be using filter expressions and or attribute queries against your sde data be sure to have the appropriate column(s) indexed within your RDBMS. The indexes will (in general) greatly enhance your query response times.
Use filterexpression only to limit the features you want to see in your display or perform a searchexpression on.
To highlight features, use searchexpression and then use DrawShape in the AfterLayerDraw event to display it.
SearchExpression honors the FilterExpression so you cannot select a feature from your layer that doesn’t apply to the FilterExpression as well. (This makes your query shorter).
