Differences

This shows you the differences between two versions of the page.

--- thinkgeo.mapsuite.silverlightcore.edittools [2015/09/21 03:20]
admin
+++ thinkgeo.mapsuite.silverlightcore.edittools [2017/03/16 21:59] (current)
@@ Line 1: / Line 1: @@
 ====== ThinkGeo.MapSuite.SilverlightCore.EditTools ======
+{{section>upgrade_map_suite_to_10.0}}
 This class is a wrapper class for the FeatureLayer that isolates only the editing methods to make them easily accessible to the programmer.
 ===== Inheritance Hierarchy =====
@@ Line 8: / Line 11: @@
 ** {{wiki:PublicMethod.gif|}} EditTools(FeatureSource) **
-This is a constructor for the class.
+  * //This is a constructor for the class.//
 == Remarks ==
-None
+  * //None//
 == Parameters ==
   * //featureSource//
@@ Line 20: / Line 23: @@
 ** {{wiki:ProtectedMethod.gif|}} EditTools() **
-This is a constructor for the class.
+  * //This is a constructor for the class.//
 == Remarks ==
-This is the default constructor. It is protected and not meant to be used.
+  * //This is the default constructor. It is protected and not meant to be used.//
 == Parameters ==
 <div newline></div>
@@ Line 28: / Line 31: @@
 ** {{wiki:PublicMethod.gif|}} BeginTransaction() **
-This method starts a new transaction if the FeatureLayer allows editing.
+  * //This method starts a new transaction if the FeatureLayer allows editing.//
 == Remarks ==
-This method is used to start a transaction, assuming that the FeatureLayer allows editing. There are some additional prerequisites to beginning a transaction, such as ensuring that a transaction is not already in progress. You must also be sure that the FeatureSource has been opened. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method is used to start a transaction, assuming that the FeatureLayer allows editing. There are some additional prerequisites to beginning a transaction, such as ensuring that a transaction is not already in progress. You must also be sure that the FeatureSource has been opened. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 40: / Line 43: @@
 ** {{wiki:PublicMethod.gif|}} Add(BaseShape) **
-This method adds a new Feature to an existing transaction.
+  * //This method adds a new Feature to an existing transaction.//
 == Remarks ==
-This method adds a new Feature to an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method adds a new Feature to an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 56: / Line 59: @@
 ** {{wiki:PublicMethod.gif|}} Add(Feature) **
-This method adds a new Feature to an existing transaction.
+  * //This method adds a new Feature to an existing transaction.//
 == Remarks ==
-This method adds a new Feature to an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method adds a new Feature to an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 72: / Line 75: @@
 ** {{wiki:PublicMethod.gif|}} Add(BaseShape,Dictionary<String,String>) **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 92: / Line 95: @@
 ** {{wiki:PublicMethod.gif|}} ScaleUp(String,Double) **
-This method increases the size of the feature by the percentage given in the percentage parameter.
+  * //This method increases the size of the feature by the percentage given in the percentage parameter.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method is useful when you would like to increase the size of the Feature. Note that a larger percentage will scale the shape up faster as you apply the operation multiple times. There is also a ScaleDown method that will shrink the shape as well.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method is useful when you would like to increase the size of the Feature. Note that a larger percentage will scale the shape up faster as you apply the operation multiple times. There is also a ScaleDown method that will shrink the shape as well.//
 == Return Value ==
@@ Line 112: / Line 115: @@
 ** {{wiki:PublicMethod.gif|}} ScaleDown(String,Double) **
-This method decreases the size of the feature by the percentage given in the percentage parameter.
+  * //This method decreases the size of the feature by the percentage given in the percentage parameter.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method is useful when you would like to decrease the size of the Feature. Note that a larger percentage will scale the shape down faster as you apply the operation multiple times. There is also a ScaleUp method that will expand the shape as well.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method is useful when you would like to decrease the size of the Feature. Note that a larger percentage will scale the shape down faster as you apply the operation multiple times. There is also a ScaleUp method that will expand the shape as well.//
 == Return Value ==
@@ Line 132: / Line 135: @@
 ** {{wiki:PublicMethod.gif|}} TranslateByDegree(String,Double,Double,GeographyUnit,DistanceUnit) **
-This method moves the Feature from one location to another based on a distance and a direction in degrees.
+  * //This method moves the Feature from one location to another based on a distance and a direction in degrees.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method moves the Feature from one location to another based on angleInDegrees and the distance parameter. With this overload, it is important to note that the distance units are based on the specified distanceUnit parameter. For example, if your Feature is in decimal degrees and you call this method with a specified distanceUnit of miles, you're going to move this shape a number of miles based on the distance and angleInDegrees. In this way, you could easily move a shape in decimal degrees five miles to the north.If you pass a distance of 0, the operation is ignored.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method moves the Feature from one location to another based on angleInDegrees and the distance parameter. With this overload, it is important to note that the distance units are based on the specified distanceUnit parameter. For example, if your Feature is in decimal degrees and you call this method with a specified distanceUnit of miles, you're going to move this shape a number of miles based on the distance and angleInDegrees. In this way, you could easily move a shape in decimal degrees five miles to the north.If you pass a distance of 0, the operation is ignored.//
 == Return Value ==
@@ Line 164: / Line 167: @@
 ** {{wiki:PublicMethod.gif|}} TranslateByOffset(String,Double,Double,GeographyUnit,DistanceUnit) **
-This method moves the Feature from one location to another based on a X and Y offset distance.
+  * //This method moves the Feature from one location to another based on a X and Y offset distance.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method moves the Feature from one location to another based on an X and Y offset distance. With this overload, it is important to note that the distance units are based on the specified distanceUnit parameter. For example, if your Feature is in decimal degrees and you call this method with an X offset of 1 and a Y offset of 1, you're going to move this Feature one unit of the distanceUnit in the horizontal direction and one unit of the distanceUnit in the vertical direction. In this way, you could easily move a Feature in decimal degrees five miles on the X axis and 3 miles on the Y axis.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method moves the Feature from one location to another based on an X and Y offset distance. With this overload, it is important to note that the distance units are based on the specified distanceUnit parameter. For example, if your Feature is in decimal degrees and you call this method with an X offset of 1 and a Y offset of 1, you're going to move this Feature one unit of the distanceUnit in the horizontal direction and one unit of the distanceUnit in the vertical direction. In this way, you could easily move a Feature in decimal degrees five miles on the X axis and 3 miles on the Y axis.//
 == Return Value ==
@@ Line 196: / Line 199: @@
 ** {{wiki:PublicMethod.gif|}} Rotate(String,PointShape,Single) **
-This method rotates the Feature any number of degrees based on a pivot point.
+  * //This method rotates the Feature any number of degrees based on a pivot point.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method rotates the Feature based on a pivot point by a number of degrees. By placing the pivot point in the center of the Feature, you can achieve in-place rotation. By moving the pivot point outside of the center of the Feature, you can translate the shape in a circular motion. Moving the pivot point further outside of the center will make the circular area larger.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This method rotates the Feature based on a pivot point by a number of degrees. By placing the pivot point in the center of the Feature, you can achieve in-place rotation. By moving the pivot point outside of the center of the Feature, you can translate the shape in a circular motion. Moving the pivot point further outside of the center will make the circular area larger.//
 == Return Value ==
@@ Line 220: / Line 223: @@
 ** {{wiki:PublicMethod.gif|}} Union(String,AreaBaseShape) **
-This method returns the union of the Feature and the target shapes, which are defined as the set of all points in the Feature or the target shape.
+  * //This method returns the union of the Feature and the target shapes, which are defined as the set of all points in the Feature or the target shape.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This is useful for adding area shapes together to form a larger area shape.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This is useful for adding area shapes together to form a larger area shape.//
 == Return Value ==
@@ Line 240: / Line 243: @@
 ** {{wiki:PublicMethod.gif|}} Union(String,Feature) **
-This method returns the union of the Feature and the target features, which are defined as the set of all points in the Feature or the target shape.
+  * //This method returns the union of the Feature and the target features, which are defined as the set of all points in the Feature or the target shape.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This is useful for adding area shapes together to form a larger area shape.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource. This is useful for adding area shapes together to form a larger area shape.//
 == Return Value ==
@@ Line 260: / Line 263: @@
 ** {{wiki:PublicMethod.gif|}} GetDifference(String,AreaBaseShape) **
-This method returns the difference between two shapes, which are defined as the set of all points that lie in the Feature but not in the targetShape.
+  * //This method returns the difference between two shapes, which are defined as the set of all points that lie in the Feature but not in the targetShape.//
 == Remarks ==
-This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource.
+  * //This method is a helpful function that allows you to easily edit InternalFeatures directly in the FeatureSource without having to retrieve them, convert them to a shape, manipulate them and put them back into the FeatureSource.//
 == Return Value ==
@@ Line 280: / Line 283: @@
 ** {{wiki:PublicMethod.gif|}} GetDifference(String,Feature) **
-This method returns the difference between two features, which are defined as the set of all points which lie in the Feature but not in the targetFeature.
+  * //This method returns the difference between two features, which are defined as the set of all points which lie in the Feature but not in the targetFeature.//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 300: / Line 303: @@
 ** {{wiki:PublicMethod.gif|}} Delete(String) **
-This method deletes a Feature from an existing transaction.
+  * //This method deletes a Feature from an existing transaction.//
 == Remarks ==
-This method deletes a Feature from an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method deletes a Feature from an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction. The Transaction System The transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer. In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object. As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed. In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 316: / Line 319: @@
 ** {{wiki:PublicMethod.gif|}} Update(BaseShape) **
-This method updates a Feature in an existing transaction.
+  * //This method updates a Feature in an existing transaction.//
 == Remarks ==
-This method updates a Feature in an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method updates a Feature in an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 332: / Line 335: @@
 ** {{wiki:PublicMethod.gif|}} Update(Feature) **
-This method updates a Feature in an existing transaction.
+  * //This method updates a Feature in an existing transaction.//
 == Remarks ==
-This method updates a Feature in an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method updates a Feature in an existing transaction. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 348: / Line 351: @@
 ** {{wiki:PublicMethod.gif|}} Update(BaseShape,Dictionary<String,String>) **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 368: / Line 371: @@
 ** {{wiki:PublicMethod.gif|}} RollbackTransaction() **
-This method will cancel an existing transaction. It will free up the internal memory cache of any InternalFeatures added, updated or deleted.
+  * //This method will cancel an existing transaction. It will free up the internal memory cache of any InternalFeatures added, updated or deleted.//
 == Remarks ==
-This method will cancel an existing transaction. It will free up the internal memory cache of any InternalFeatures added, updated or deleted. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method will cancel an existing transaction. It will free up the internal memory cache of any InternalFeatures added, updated or deleted. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 380: / Line 383: @@
 ** {{wiki:PublicMethod.gif|}} CommitTransaction() **
-This method will commit the existing transaction to its underlying source of data.
+  * //This method will commit the existing transaction to its underlying source of data.//
 == Remarks ==
-This method will commit the existing transaction to its underlying source of data. It will then pass back the results of the commit, including any error(s) received. Finally, it will free up the internal memory cache of any InternalFeatures added, updated or deleted. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.
+  * //This method will commit the existing transaction to its underlying source of data. It will then pass back the results of the commit, including any error(s) received. Finally, it will free up the internal memory cache of any InternalFeatures added, updated or deleted. You will need to ensure that you have started a transaction by calling BeginTransaction.The Transaction SystemThe transaction system of a FeatureLayer sits on top of the inherited implementation of any specific source, such as Oracle Spatial or Shape files. In this way, it functions the same way for every FeatureLayer. You start by calling BeginTransaction. This allocates a collection of in-memory change buffers that are used to store changes until you commit the transaction. So, for example, when you call the Add, Delete or Update method, the changes to the feature are stored in memory only. If for any reason you choose to abandon the transaction, you can call RollbackTransaction at any time and the in-memory buffer will be deleted and the changes will be lost. When you are ready to commit the transaction, you call CommitTransaction and the collections of changes are then passed to the CommitTransactionCore method and the implementer of the specific FeatureLayer is responsible for integrating your changes into the underlying FeatureLayer. By default the IsLiveTransaction property is set to false, which means that until you commit the changes, the FeatureLayer API will not reflect any changes that are in the temporary editing buffer.In the case where the IsLiveTransaction is set to true, then things function slightly differently. The live transaction concept means that all of the modifications you perform during a transaction are live from the standpoint of the querying methods on the object.As an example, imagine that you have a FeatureLayer that has 10 records in it. Next, you begin a transaction and then call GetAllFeatures.  The result would be 10 records. After that, you call a delete on one of the records and call the GetAllFeatures again.  This time you only get nine records, even though the transaction has not yet been committed. In the same sense, you could have added a new record or modified an existing one and those changes would be considered live, though not committed.In the case where you modify records -- such as expanding the size of a polygon -- those changes are reflected as well. For example, you expand a polygon by doubling its size and then do a spatial query that would not normally return the smaller record, but instead would return the larger records.  In this case, the larger records are returned. You can set this property to be false, as well; in which case, all of the spatially related methods would ignore anything that is currently in the transaction buffer waiting to be committed. In such a case, only after committing the transaction would the FeatureLayer reflect the changes.//
 == Return Value ==
@@ Line 392: / Line 395: @@
 ** {{wiki:PublicMethod.gif|}} ToString() **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 404: / Line 407: @@
 ** {{wiki:PublicMethod.gif|}} Equals(Object) **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 420: / Line 423: @@
 ** {{wiki:PublicMethod.gif|}} GetHashCode() **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 432: / Line 435: @@
 ** {{wiki:PublicMethod.gif|}} GetType() **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 445: / Line 448: @@
 ** {{wiki:ProtectedMethod.gif|}} Finalize() **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==
@@ Line 457: / Line 460: @@
 ** {{wiki:ProtectedMethod.gif|}} MemberwiseClone() **
-N/A
+  * //N/A//
 == Remarks ==
-N/A
+  * //N/A//
 == Return Value ==

User Tools

Site Tools

Differences

Page Tools