32 BaseConstructL(aConstructionParameters); |
32 BaseConstructL(aConstructionParameters); |
33 } |
33 } |
34 </codeblock> </stepxmp> </step> <step id="GUID-82CD3F69-85A8-5D9D-9C38-9F4424A33B4A"><cmd>Write code to handle the Location Server setting GPS options </cmd> <info>The PSY can also be passed options for a position request. The parameters are obtained through accessor methods provided on the <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita"><apiname>CPositioner</apiname></xref> class. </info> <info>The <codeph>CPositioner</codeph> base class provides a default implementation that retrieves the options provided by the client application when it makes a location request. The PSY implementation can override these methods if required: </info> <substeps id="GUID-F357104A-BE9B-5919-8AB6-15114BF7DC17"><substep id="GUID-D91E3CAB-29D6-5CBE-912A-CBAF4A54F83C"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-F72BE40F-537B-3633-B6BF-65B694682681"><apiname>CPositioner::GetMaxAge()</apiname></xref> </info> <info>A client application may specify a maximum age when performing a position request. This means that a position can be returned from an old measurement as long as the position is not older than the specified maximum age. Supporting maximum age is optional in a PSY. If the PSY developer wants to support the maximum age, the PSY must be implemented to cache the latest position estimate. <codeph>GetMaxAge()</codeph> is the function that the PSY implementation can use to retrieve the maximum age specified by the client. </info> </substep> <substep id="GUID-EFB2A64D-109F-5D1D-94C1-88316F12ADCA"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-53E2D165-76D4-3329-9834-B64EEC11604F"><apiname>CPositioner::IsPartialUpdateAllowed()</apiname></xref> </info> <info>A client application may specify that it accepts incomplete location information. Incomplete location information is only required to contain the time and the PSY ID. It is not required to include latitude or longitude. For example, a GPS PSY may read NMEA sentences, which does not include a fix because the terminal is indoors. The GPS PSY could still return satellite information to the client if partial updates are allowed. The PSY can check if partial location information is accepted by the client by calling <codeph>IsPartialUpdateAllowed()</codeph>. If <codeph>ETrue</codeph> is returned, then the PSY can return an incomplete fix. </info> </substep> <substep id="GUID-AEA081B2-E438-51D5-8CE8-956BD929AE32"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-C7BB2CA5-3351-3117-B859-C3014B80653C"><apiname>CPositioner::GetRequiredPositionQuality()</apiname></xref> </info> <info>A client application may specify a required position quality. The PSY can use the position quality if it is possible to specify the required quality of position to the positioning technology that it encapsulates. <codeph>GetRequiredPositionQuality()</codeph> returns <codeph>KErrNotFound</codeph> if no quality has been specified by the client. </info> <info> Important Note: <codeph> |
34 </codeblock> </stepxmp> </step> <step id="GUID-82CD3F69-85A8-5D9D-9C38-9F4424A33B4A"><cmd>Write code to handle the Location Server setting GPS options </cmd> <info>The PSY can also be passed options for a position request. The parameters are obtained through accessor methods provided on the <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita"><apiname>CPositioner</apiname></xref> class. </info> <info>The <codeph>CPositioner</codeph> base class provides a default implementation that retrieves the options provided by the client application when it makes a location request. The PSY implementation can override these methods if required: </info> <substeps id="GUID-F357104A-BE9B-5919-8AB6-15114BF7DC17"><substep id="GUID-D91E3CAB-29D6-5CBE-912A-CBAF4A54F83C"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-F72BE40F-537B-3633-B6BF-65B694682681"><apiname>CPositioner::GetMaxAge()</apiname></xref> </info> <info>A client application may specify a maximum age when performing a position request. This means that a position can be returned from an old measurement as long as the position is not older than the specified maximum age. Supporting maximum age is optional in a PSY. If the PSY developer wants to support the maximum age, the PSY must be implemented to cache the latest position estimate. <codeph>GetMaxAge()</codeph> is the function that the PSY implementation can use to retrieve the maximum age specified by the client. </info> </substep> <substep id="GUID-EFB2A64D-109F-5D1D-94C1-88316F12ADCA"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-53E2D165-76D4-3329-9834-B64EEC11604F"><apiname>CPositioner::IsPartialUpdateAllowed()</apiname></xref> </info> <info>A client application may specify that it accepts incomplete location information. Incomplete location information is only required to contain the time and the PSY ID. It is not required to include latitude or longitude. For example, a GPS PSY may read NMEA sentences, which does not include a fix because the terminal is indoors. The GPS PSY could still return satellite information to the client if partial updates are allowed. The PSY can check if partial location information is accepted by the client by calling <codeph>IsPartialUpdateAllowed()</codeph>. If <codeph>ETrue</codeph> is returned, then the PSY can return an incomplete fix. </info> </substep> <substep id="GUID-AEA081B2-E438-51D5-8CE8-956BD929AE32"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-C7BB2CA5-3351-3117-B859-C3014B80653C"><apiname>CPositioner::GetRequiredPositionQuality()</apiname></xref> </info> <info>A client application may specify a required position quality. The PSY can use the position quality if it is possible to specify the required quality of position to the positioning technology that it encapsulates. <codeph>GetRequiredPositionQuality()</codeph> returns <codeph>KErrNotFound</codeph> if no quality has been specified by the client. </info> <info> Important Note: <codeph> |
35 GetRequiredPositionQuality()</codeph> is not currently supported and always returns <codeph>KErrNotFound</codeph>. </info> </substep> </substeps> </step> <step id="GUID-83717E31-D4E4-5937-A6D0-6A8368798C8B"><cmd>Write code to handle a single location request </cmd> <info>When a client requests location information from the Location Framework, the framework forwards the request to a PSY instance. <codeph>CPositioner</codeph> provides a pure virtual method <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-03A37FAC-3129-3483-AC7F-C17A46D9F431"><apiname>CPositioner::NotifyPositionUpdate()</apiname></xref> that must be implemented by the PSY in order to handle a position request. </info> <info> <codeph>NotifyPositionUpdate()</codeph> is an asynchronous call and must be implemented in the PSY to return at once. If positioning takes time, it should be implemented using active objects, otherwise the Location Server is blocked for the time that a position fix is being obtained by the PSY. <codeph>NotifyPositionUpdate()</codeph> has a <codeph>TRequestStatus</codeph> parameter which is used to signal that the position acquisition is complete. </info> <info> <codeph>NotifyPositionUpdate</codeph> () also has a <xref href="GUID-73D6F438-C270-33B9-974B-D4D1583E1738.dita"><apiname>TPositionInfoBase</apiname></xref> as an output parameter. This object is used to pass position information back to the client. <codeph>TPositionInfoBase</codeph> is an abstract class and the actual class hierarchy of the position information object can be obtained by calling <xref href="GUID-73D6F438-C270-33B9-974B-D4D1583E1738.dita#GUID-73D6F438-C270-33B9-974B-D4D1583E1738/GUID-CD86897E-5924-3758-BD92-1D324BE4287C"><apiname>TPositionInfoBase::PositionClassType()</apiname></xref>. The PSY must cast the position information object to the actual subclass and the appropriate position information filled in. PSYs can support different sets of position information classes but <xref href="GUID-D5B2E933-209D-3871-8E27-CC5C8855C745.dita"><apiname>TPositionInfo</apiname></xref> and <xref href="GUID-ADB30502-C84C-3027-B457-9150FA4AC510.dita"><apiname>HGenericPositionInfo</apiname></xref> are mandatory. The position information class must store data as specified by the WGS84 geodetic datum. </info> <info>The PSY must also report the data quality status while returning position information. </info> <info>This sequence diagram of figure 1 shows the steps that are involved when the Location Framework makes a request for a position update from a PSY. </info> <info><fig id="GUID-E194C421-6C62-5538-809C-DB33A454B930"><title> |
35 GetRequiredPositionQuality()</codeph> is not currently supported and always returns <codeph>KErrNotFound</codeph>. </info> </substep> </substeps> </step> <step id="GUID-83717E31-D4E4-5937-A6D0-6A8368798C8B"><cmd>Write code to handle a single location request </cmd> <info>When a client requests location information from the Location Framework, the framework forwards the request to a PSY instance. <codeph>CPositioner</codeph> provides a pure virtual method <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-03A37FAC-3129-3483-AC7F-C17A46D9F431"><apiname>CPositioner::NotifyPositionUpdate()</apiname></xref> that must be implemented by the PSY in order to handle a position request. </info> <info> <codeph>NotifyPositionUpdate()</codeph> is an asynchronous call and must be implemented in the PSY to return at once. If positioning takes time, it should be implemented using active objects, otherwise the Location Server is blocked for the time that a position fix is being obtained by the PSY. <codeph>NotifyPositionUpdate()</codeph> has a <codeph>TRequestStatus</codeph> parameter which is used to signal that the position acquisition is complete. </info> <info> <codeph>NotifyPositionUpdate</codeph> () also has a <xref href="GUID-73D6F438-C270-33B9-974B-D4D1583E1738.dita"><apiname>TPositionInfoBase</apiname></xref> as an output parameter. This object is used to pass position information back to the client. <codeph>TPositionInfoBase</codeph> is an abstract class and the actual class hierarchy of the position information object can be obtained by calling <xref href="GUID-73D6F438-C270-33B9-974B-D4D1583E1738.dita#GUID-73D6F438-C270-33B9-974B-D4D1583E1738/GUID-CD86897E-5924-3758-BD92-1D324BE4287C"><apiname>TPositionInfoBase::PositionClassType()</apiname></xref>. The PSY must cast the position information object to the actual subclass and the appropriate position information filled in. PSYs can support different sets of position information classes but <xref href="GUID-D5B2E933-209D-3871-8E27-CC5C8855C745.dita"><apiname>TPositionInfo</apiname></xref> and <xref href="GUID-ADB30502-C84C-3027-B457-9150FA4AC510.dita"><apiname>HGenericPositionInfo</apiname></xref> are mandatory. The position information class must store data as specified by the WGS84 geodetic datum. </info> <info>The PSY must also report the data quality status while returning position information. </info> <info>This sequence diagram of figure 1 shows the steps that are involved when the Location Framework makes a request for a position update from a PSY. </info> <info><fig id="GUID-E194C421-6C62-5538-809C-DB33A454B930"><title> |
36 Figure 1. Handling a request for position information. |
36 Figure 1. Handling a request for position information. |
37 </title> <image href="GUID-2D86812F-5DB1-5FD9-A199-AE344D5A10C8_d0e456651_href.png" placement="inline"/></fig> </info> <info>The following code example shows how to process a location request. </info> <stepxmp><codeblock id="GUID-8D2520E2-38D9-5412-A1C7-B57B88998576" xml:space="preserve">void CPosExamplePositioner::NotifyPositionUpdate( |
37 </title> <image href="GUID-2D86812F-5DB1-5FD9-A199-AE344D5A10C8_d0e462496_href.png" placement="inline"/></fig> </info> <info>The following code example shows how to process a location request. </info> <stepxmp><codeblock id="GUID-8D2520E2-38D9-5412-A1C7-B57B88998576" xml:space="preserve">void CPosExamplePositioner::NotifyPositionUpdate( |
38 TPositionInfoBase& aPosInfo, |
38 TPositionInfoBase& aPosInfo, |
39 TRequestStatus& aStatus) |
39 TRequestStatus& aStatus) |
40 { |
40 { |
41 TRequestStatus *statusPtr = &aStatus; |
41 TRequestStatus *statusPtr = &aStatus; |
42 |
42 |
66 |
66 |
67 User::RequestComplete(statusPtr, KErrNone); |
67 User::RequestComplete(statusPtr, KErrNone); |
68 } |
68 } |
69 </codeblock> </stepxmp> </step> <step id="GUID-100F3359-EDCF-5555-A38B-B379F0A7C572"><cmd>Write code to handle periodic location requests (tracking) </cmd> <info>A client application can request periodic position updates from the Location Framework. This is known as tracking. If the client application continues to reissue position requests as soon as the last request completes then it receives periodic position updates. </info> <info>The Location Framework sends a position request to a PSY when a location update is required by a client. The PSY must be ready to give position information as soon as the Location Framework sends a request. A PSY needs to know about the requirement for periodic position requests if the underlying positioning technology needs to be kept powered in order to provide fast position updates. Conversely, a PSY can go into standby mode if it knows that it is a long time until the next request. </info> <info>To support tracking the PSY must implement the following virtual methods in <codeph>CPositioner</codeph>: </info> <substeps id="GUID-F84A38AA-F86B-5049-984D-296896BB7FAA"><substep id="GUID-65D1CB9C-B8AA-54AF-A4E0-0527F3BC0A52"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-EF23126A-7869-3113-9ED6-530BB57D66A2"><apiname>CPositioner::TrackingOverridden()</apiname></xref> must be implemented by the PSY <codeph>CPositioner</codeph> subclass to return <codeph>ETrue</codeph>. This indicates that the PSY implements specific logic to handle periodic position updates. The default implementation for <codeph>TrackingOverridden</codeph> in <codeph>CPositioner</codeph> returns <codeph>EFalse</codeph>. </info> </substep> <substep id="GUID-57D535CB-67A1-5027-92D7-4998926556E8"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-C0CCADDD-6CD8-37E9-BC7F-19ECF0F72C84"><apiname>CPositioner::StopTracking()</apiname></xref> must be overridden by the PSY <codeph>CPositioner</codeph> subclass. It is called by the Location Framework to signal that the tracking session has been closed so the PSY can put the positioning technology hardware into standby mode. The default implementation for <codeph>StopTracking() </codeph> in <codeph>CPositioner</codeph> does not perform any action. </info> <info>If a PSY implementation returns <codeph>ETrue</codeph> from <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-EF23126A-7869-3113-9ED6-530BB57D66A2"><apiname>CPositioner::TrackingOverridden()</apiname></xref> then it should provide an implementation of <codeph>StopTracking()</codeph>. </info> </substep> <substep id="GUID-EFE1E5CA-E9A4-56BE-82C1-5A2EA31BD985"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-4DFC679F-F6F6-39A1-91DF-69661ABC0FA8"><apiname>CPositioner::StartTrackingL()</apiname></xref> must be overridden by the PSY <codeph>CPositioner</codeph> subclass. It is called by the Location Framework to signal that the Location Server has started a tracking session. The PSY can start the positioning technology specific device/protocol and keep it in state where position information can be obtained quickly. </info> <info>The periodicity of position updates requested by theclient application is passed as an input parameter to this method. If the PSY cannot support the periodicity, it must return fixes as frequently as possible. The default implementation for <codeph>StartTrackingL()</codeph> in <codeph>CPositioner</codeph> leaves with <codeph>KErrNotSupported</codeph>. If the PSY implementation returns <codeph>ETrue</codeph> from <codeph>TrackingOverridden</codeph> then it needs to provide an implementation of <codeph>StartTrackingL()</codeph>. </info> </substep> </substeps> <info>Figure 2 shows the steps that are involved when the Location Framework initiates a periodic position request from a PSY: </info> <info><fig id="GUID-B62DCC66-0C97-594A-A22F-EEC88E507924"><title> |
69 </codeblock> </stepxmp> </step> <step id="GUID-100F3359-EDCF-5555-A38B-B379F0A7C572"><cmd>Write code to handle periodic location requests (tracking) </cmd> <info>A client application can request periodic position updates from the Location Framework. This is known as tracking. If the client application continues to reissue position requests as soon as the last request completes then it receives periodic position updates. </info> <info>The Location Framework sends a position request to a PSY when a location update is required by a client. The PSY must be ready to give position information as soon as the Location Framework sends a request. A PSY needs to know about the requirement for periodic position requests if the underlying positioning technology needs to be kept powered in order to provide fast position updates. Conversely, a PSY can go into standby mode if it knows that it is a long time until the next request. </info> <info>To support tracking the PSY must implement the following virtual methods in <codeph>CPositioner</codeph>: </info> <substeps id="GUID-F84A38AA-F86B-5049-984D-296896BB7FAA"><substep id="GUID-65D1CB9C-B8AA-54AF-A4E0-0527F3BC0A52"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-EF23126A-7869-3113-9ED6-530BB57D66A2"><apiname>CPositioner::TrackingOverridden()</apiname></xref> must be implemented by the PSY <codeph>CPositioner</codeph> subclass to return <codeph>ETrue</codeph>. This indicates that the PSY implements specific logic to handle periodic position updates. The default implementation for <codeph>TrackingOverridden</codeph> in <codeph>CPositioner</codeph> returns <codeph>EFalse</codeph>. </info> </substep> <substep id="GUID-57D535CB-67A1-5027-92D7-4998926556E8"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-C0CCADDD-6CD8-37E9-BC7F-19ECF0F72C84"><apiname>CPositioner::StopTracking()</apiname></xref> must be overridden by the PSY <codeph>CPositioner</codeph> subclass. It is called by the Location Framework to signal that the tracking session has been closed so the PSY can put the positioning technology hardware into standby mode. The default implementation for <codeph>StopTracking() </codeph> in <codeph>CPositioner</codeph> does not perform any action. </info> <info>If a PSY implementation returns <codeph>ETrue</codeph> from <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-EF23126A-7869-3113-9ED6-530BB57D66A2"><apiname>CPositioner::TrackingOverridden()</apiname></xref> then it should provide an implementation of <codeph>StopTracking()</codeph>. </info> </substep> <substep id="GUID-EFE1E5CA-E9A4-56BE-82C1-5A2EA31BD985"><cmd/><info> <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-4DFC679F-F6F6-39A1-91DF-69661ABC0FA8"><apiname>CPositioner::StartTrackingL()</apiname></xref> must be overridden by the PSY <codeph>CPositioner</codeph> subclass. It is called by the Location Framework to signal that the Location Server has started a tracking session. The PSY can start the positioning technology specific device/protocol and keep it in state where position information can be obtained quickly. </info> <info>The periodicity of position updates requested by theclient application is passed as an input parameter to this method. If the PSY cannot support the periodicity, it must return fixes as frequently as possible. The default implementation for <codeph>StartTrackingL()</codeph> in <codeph>CPositioner</codeph> leaves with <codeph>KErrNotSupported</codeph>. If the PSY implementation returns <codeph>ETrue</codeph> from <codeph>TrackingOverridden</codeph> then it needs to provide an implementation of <codeph>StartTrackingL()</codeph>. </info> </substep> </substeps> <info>Figure 2 shows the steps that are involved when the Location Framework initiates a periodic position request from a PSY: </info> <info><fig id="GUID-B62DCC66-0C97-594A-A22F-EEC88E507924"><title> |
70 Figure 2. Handling periodic position determination request |
70 Figure 2. Handling periodic position determination request |
71 </title> <image href="GUID-474654BE-D73E-5249-B7E3-7F2656DAB190_d0e456780_href.png" placement="inline"/></fig> </info> </step> <step id="GUID-1FC0C372-4FA8-5F16-86DC-158F09F4246F"><cmd>Write code to handle request cancellation </cmd> <info>When the client requests cancellation of an outstanding location request from the Location Framework, the framework forwards the request to the corresponding PSY instance. The <codeph>CPositioner</codeph> provides a pure virtual method <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-D28C6BC6-69B8-3D69-BE46-5745C5B77A4D"><apiname>CPositioner::CancelNotifyPositionUpdate()</apiname></xref> that has to be implemented by the PSY in order to handle cancellation of a position request. </info> <info> <codeph>CancelNotifyPositionUpdate()</codeph> must be implemented to cancel any outstanding request in the PSY. Typically this involves cancelling some active object. If there is an outstanding request, it must be completed with the code <codeph>KErrCancel</codeph>. </info> <info>Figure 3 shows the steps that are involved when the Location framework initiates a cancel request for an outstanding position request. </info> <info><fig id="GUID-BC2EE2F2-4F13-5EFA-B80B-B79E90EA5B3E"><title> |
71 </title> <image href="GUID-474654BE-D73E-5249-B7E3-7F2656DAB190_d0e462625_href.png" placement="inline"/></fig> </info> </step> <step id="GUID-1FC0C372-4FA8-5F16-86DC-158F09F4246F"><cmd>Write code to handle request cancellation </cmd> <info>When the client requests cancellation of an outstanding location request from the Location Framework, the framework forwards the request to the corresponding PSY instance. The <codeph>CPositioner</codeph> provides a pure virtual method <xref href="GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350.dita#GUID-0CA8AEC1-FF5E-3556-ACBD-0D4277CF1350/GUID-D28C6BC6-69B8-3D69-BE46-5745C5B77A4D"><apiname>CPositioner::CancelNotifyPositionUpdate()</apiname></xref> that has to be implemented by the PSY in order to handle cancellation of a position request. </info> <info> <codeph>CancelNotifyPositionUpdate()</codeph> must be implemented to cancel any outstanding request in the PSY. Typically this involves cancelling some active object. If there is an outstanding request, it must be completed with the code <codeph>KErrCancel</codeph>. </info> <info>Figure 3 shows the steps that are involved when the Location framework initiates a cancel request for an outstanding position request. </info> <info><fig id="GUID-BC2EE2F2-4F13-5EFA-B80B-B79E90EA5B3E"><title> |
72 Figure 3. Cancelling a position determination request |
72 Figure 3. Cancelling a position determination request |
73 </title> <image href="GUID-502C26EB-BB1F-547C-B93B-8A516D545561_d0e456815_href.png" placement="inline"/></fig> </info> <stepxmp><codeblock id="GUID-8346C01C-AE15-5D30-9C66-4B2EB249B35F" xml:space="preserve">void CPosExamplePositioner::CancelNotifyPositionUpdate() |
73 </title> <image href="GUID-502C26EB-BB1F-547C-B93B-8A516D545561_d0e462660_href.png" placement="inline"/></fig> </info> <stepxmp><codeblock id="GUID-8346C01C-AE15-5D30-9C66-4B2EB249B35F" xml:space="preserve">void CPosExamplePositioner::CancelNotifyPositionUpdate() |
74 { |
74 { |
75 // Since the Example PSY can deliver a position very |
75 // Since the Example PSY can deliver a position very |
76 // fast it has been implemented synchronously which |
76 // fast it has been implemented synchronously which |
77 // means that there will never be an outstanding |
77 // means that there will never be an outstanding |
78 // request to cancel. |
78 // request to cancel. |