I need a nudge in the right direction

[swift39]

Hi All,
So continuing to work through version 2 of my NAVRAD multi function RADAR, and using Mr. McElrath and many others advice I keep plugging away at small chunks and am making, to me, really good progress and am finding myself pleased with most of the results. But with everything I have come across a problem that after going at it at several different angles either I just don't understand the process or am completely looking at it the wrong way or in fact any combination of things.

What I am looking at having my gauge do is in the Flight Planner Page (Thank you very much again Bob and Karol) I have created a button that takes you to a Set Alternate Airport Page with what I hope to achieve is:

1.) When that button is pressed the page comes up with 10 airports nearest the set "Destination" airport in the Flight Planner. I am currently trying to use:

1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLatitude, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLongitude, Radians)  (>@c:NearestAirportCurrentLongitude, Radians) 
     11 (>@c:NearestAirportMaximumItems) 
    100 (>@c:NearestAirportMaximumDistance, NMiles)
      1 (>@c:NearestAirportCurrentLine)

as my nearest search parameters. I have also tried using (A:GPS WP NEXT LAT, Radians) and (A:GPS WP NEXT LON, Radians). The problems I will get to in a minute.

2.) The second thing I would like to happen is the user enters the airport ident, presses enter and the information is saved to what I am thinking an (L:VAR) using either Robbie McElrath's macros or similar. The saved information would be the airport Ident, airport name and city to be displayed on the Flight Planner Page. This process would also arm a switch, lets call it the "Divert" button.

3.) Then obliviously when the "DIVERT" button is pressed it creates a waypoint, deletes the destination and the Alternate is the new destination.

OK, all that being said, I am pretty confident with my ability with items two and three, mind you I thought that with item one.

Now the problem:
The two search parameters I am using are:

Nearest Airport Search (In relationship with the aircraft)

  (L:NearestAirportPage,bool) 1 ==
  (L:NearestAirportInit,bool) 1 and
  if{ 
  (A:GPS POSITION LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
  (A:GPS POSITION LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians) 
  500 (>@c:NearestAirportMaximumItems) 
  375 (>@c:NearestAirportMaximumDistance, NMiles)
  0 (>@c:NearestAirportCurrentLine)
  1 (>L:NearestAirportInit,bool) }

Nearest Airport Search (In relationship to the Destination Airport or Waypoint 1)

(L:SetAlternateAP,bool) 1 ==
(L:AltAirportInit,bool) 1 and if{
1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLatitude, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLongitude, Radians)  (>@c:NearestAirportCurrentLongitude, Radians) 
     11 (>@c:NearestAirportMaximumItems) 
    100 (>@c:NearestAirportMaximumDistance, NMiles)
      1 (>@c:NearestAirportCurrentLine)
      0 (>L:AltAirportInit,bool) }

I have tried the parameters as updates, by mouse clicks and combined updates and the results have been erroneous. I have had the following results:
1.) No display on either page and the Flight Planner doesn't work properly.
2.) One or the other Search parameters display on both pages and Flight Planner works properly sometimes.
3.) One search parameter displaying information but limited to the number of airports of the other search parameter and Flight Planner doesn't work properly.

Now I am painfully aware of the Asynchronous Operation of the GPS. But is this Really a conflict of the two searches? I have tried coding it to turn off the (call it the main search criteria) while in the Set Alternate Airport page and resume when exited, but to no avail. Do I need to utilize a cycle skipping technique or coding it wrong, looking at from the wrong angle or some other item I am completely missing? Basically what would be the best approach to this? The Nearest Airport search needs to be the main focus as the Flight Planner and other operations use it and the Nearest Destination Airport Search is only required in the Set Alternate Page.

A nudge (well a big push of a cliff maybe) on how to proceed would be greatly appreciated and hope I have explained this well enough.

Thanks Greg

 

[COBS]

Greg

A possible method might be ?

You need a " Loop " to generate a constantly updated listing of the
Nearest airports to your 'aircraft' , with a large Search distance.
( see page 29 0f the GPS Module handbook)

Then.
To get the " 10 that are Nearest to your Destination "
Define your Destination.
Then "Select and list' only 10 closest to your Destination.

Then define each individual line of your listing display page with the data that you might want to extract to transfer to a action.

A click on a individual line ( any of the 10 lines) will transfer required data
to your L:Var.

Cheers
Karol

 

[rpmc]

Greg,

Just try this first and see where you get:

(L:NearestAirportPage,bool) 1 ==
(L:NearestAirportInit,bool) 1 == and

(L:SetAlternateAP,bool) 1 ==
(L:AltAirportInit,bool) 1 == and

Bob

 

[rpmc]

You need a " Loop " to generate a constantly updated listing of the
Nearest airports to your 'aircraft' , with a large Search distance.
( see page 29 0f the GPS Module handbook)

To clarify, that is simply the loop that displays a line of information for each airport returned by the Nearest search. By itself, it doesn't update the search results. Greg's code probably contains such a display loop.

Based on his description, it looks like Greg needs to initiate the nearest airport search only at the moment his Set Alternate Airport Page button is pushed. Perhaps he doesn't need the nearest airport search to be continuously updated.

Bob

 

[COBS]

Sorry , but you still need to deal with locations.

Basically "Nearest" concerns the current user aircraft only. It lists airports
relative to your aircraft's current position.

The list of 10 airports that you are after are relative to a totally different location , that location is the Flt Pln Destination which happens to be the
largest numerical value of " FlightPlanWaypointIndex ".

You will have to define the destination , it is
the largest value of " FlightPlanWaypointIndex " , that is the one that
I previously said had to be defined .
Once Destination is defined you retrieve it's Lat/Long.

Then do a GeoCalc comparison of distances between,
(1) The destination Lat/Long ,
and
(2) The user aircraft Nearest airports Lat/Longs.
then
(3) Select and list only the Nearest airports that have the lowest
10 values of distance that the comparison determined.
(4) as said above the list of 10 airports that are now effectively the 10
nearest the destination (not the usual users nearest).
Define each of 10 lines as a click zone to enable your selection of
Alternate or Diversion arm
(5) Which ever line (Airport) is selected can then be used as a Replacement for your Previous Destination.

From the code provided above I can see no reference to the Destination or it's location.

Cheers
Karol
PS: Greg your second bit of code is a cross between two things
1. the first part appears to define only a Direct To (DTO)
2. the latter part reverts to using Variables that are only applicable to a User aircraft Nearest , will not work.

 

[COBS]

Greg

I have serious doubts that the method that I suggested is practical.
If you conducted a Flight Plan from New York to Seattle-Tacoma then the number of Airports involved in a whole of flight plan Nearest search would
probably number at in excess of 2,000 , therefore it would not be a feasible proposition for long flights through regions populated with a high density of Airports.

As far as I can see the GPS module and it's variables are limited to search from
your aircraft based on it's current position,
" c:NearestAirportCurrentLatitude/ c:NearestAirportCurrentLongitude "

Did you try something along the following lines in your testing ?

(A:GPS WP NEXT LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
  (A:GPS WP NEXT LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians)

Cheers
Karol

 

[swift39]

Thank you very much Gentlemen,

I am going to work backwards here and hopefully my approach and reasoning make sense, I mean no offense and just going to try and explain where I am at and what I am thinking, please correct me if am wrong...

I agree Karol I think your approach is very large approach to what I feel is a simple approach and a matter of changing the search parameters when entering the set alternate airport page. I could be wrong though...

As far as I can see the GPS module and it's variables are limited to search from
your aircraft based on it's current position,
" c:NearestAirportCurrentLatitude/ c:NearestAirportCurrentLongitude "

The way I understand the nearest search parameters is yes you need search from c:NearestAirportCurrentLatitude/c:NearestAirportCurrentLongitude, but it is derived to what you input into these. Which of course is typically the current aircraft position. So by changing the input to

1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLatitude, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLongitude, Radians)  (>@c:NearestAirportCurrentLongitude, Radians)

or 

(A:GPS WP NEXT LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
  (A:GPS WP NEXT LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians)

All I am doing is changing the parameters of the nearest search from the aircraft position to another position (Destination Airport). I do think at this point either one of the above should work. Stress should!

Based on his description, it looks like Greg needs to initiate the nearest airport search only at the moment his Set Alternate Airport Page button is pushed. Perhaps he doesn't need the nearest airport search to be continuously updated.

At this point I think Bob hit the nail on the head. I can think of only three instances where I need nearest airport information two from the current aircraft position (Nearest Airport Search/Flight Planner) and the Alternate Airport function using the Destination Airport. So using that train of thought why am I have the search continuously update? So I have gone back to preforming the search through the mouse clicks. Which are as follows:

Nearest Airport Search

<Click>
      (L:NearestAirportPage,bool) ! (>L:NearestAirportPage,bool)
   0 (>L:AirportInfoMenu,bool) 0 (>L:MFDMainMenu,bool)
  
   0 (>L:AltAirportInit,bool)
   1 (>L:NearestAirportInit,bool)

      (L:NearestAirportPage,bool) 1 ==
      (L:NearestAirportInit,bool) 1 == and
      if{ 
      (A:GPS POSITION LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
      (A:GPS POSITION LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians) 
500 (>@c:NearestAirportMaximumItems) 
375 (>@c:NearestAirportMaximumDistance, NMiles)
  0 (>@c:NearestAirportCurrentLine) }
</Click>

Alternate Airport Search

<Click>
  0 (>L:FlightPlanDisplay, bool)
  1 (>L:SetAlternateAP,bool) 
  0 (>L:NearestAirportInit,bool)
  1 (>L:AltAirportInit,bool)

     (L:SetAlternateAP,bool) 1 ==
     (L:AltAirportInit,bool) 1 == and if{
  1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLatitude, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
  1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLongitude, Radians)  (>@c:NearestAirportCurrentLongitude, Radians) 
 11 (>@c:NearestAirportMaximumItems) 
100 (>@c:NearestAirportMaximumDistance, NMiles)
   1 (>@c:NearestAirportCurrentLine) } 
</Click>

In the respective element section in the visibility tags are:

Nearest Airport Display

<Visible>
(L:NearestAirportPage,bool)
  (A:GPS POSITION LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
  (A:GPS POSITION LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians) 
500 (>@c:NearestAirportMaximumItems) 
375 (>@c:NearestAirportMaximumDistance, NMiles)
   0 (>@c:NearestAirportCurrentLine)
</Visible>

Alternate Airport Display

<Visible>
(L:SetAlternateAP,bool)
  1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLatitude, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
  1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLongitude, Radians)  (>@c:NearestAirportCurrentLongitude, Radians) 
 11 (>@c:NearestAirportMaximumItems) 
100 (>@c:NearestAirportMaximumDistance, NMiles)
   1 (>@c:NearestAirportCurrentLine)
</Visible>

which as is only displays the Alternate Airport on both pages. So assuming this is a sound approach and coded correctly I am leaning to believe there is a conflict within the gauge, forcing the Alternate Search to be the dominate search parameter.

Really open to your thoughts and opinions, I going back to see if I am on the right track and thank you both so very much

Greg

Just to update I took out everything in my gauge even remotely related to airport searches other than the two explained here and still the same with the alternate search being displayed in both pages. Continuing to work through this and open to any suggestions... Thanks again
Greg

 

[swift39]

Ok I am pleased with myself, I actually figured this out and thanks Bob for the comment about the requirement for the update. My problem was using the <Visible> statement.

So there may be a better way of doing this, but this works:

I added another <Element> into each page removing the airport search out of the <Visible> tag.

Nearest Airport Search

<Element>
      <Select>
      <Value>
            (L:NearestAirportPage,bool) 1 ==
            (L:NearestAirportInit,bool) 1 == and if{ 
            (A:GPS POSITION LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
            (A:GPS POSITION LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians) 
        500 (>@c:NearestAirportMaximumItems) 
        375 (>@c:NearestAirportMaximumDistance, NMiles)
          0 (>@c:NearestAirportCurrentLine) }      
      </Value>
      </Select>
    </Element>

Alternate Airport Search

  <Element>
    <Select>
    <Value>
        (L:SetAlternateAP,bool) 1 ==
        (L:AltAirportInit,bool) 1 == and if{
        1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLatitude, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
        1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLongitude, Radians)  (>@c:NearestAirportCurrentLongitude, Radians) 
       11 (>@c:NearestAirportMaximumItems) 
      100 (>@c:NearestAirportMaximumDistance, NMiles)
        1 (>@c:NearestAirportCurrentLine) }
    </Value>
    </Select>
    </Element>

Tested it and it completes the search within the entered parameters. I tried using the

 (A:GPS WP NEXT LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
  (A:GPS WP NEXT LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians)

and it never worked it would still display only 10 airports, but with the nearest airport search information. I will also have to incorporate a search into the Flight Planner as depending on which was last search it is of course using that information. Anyways thanks and I will update as my progress continues in completing this function. Thanks again

Greg

 

[COBS]

Congratulations , well done .

How are you advising the Alternate search what the destination airport
c:FlightPlanWaypointIndex number is ?

I presume you read the Index number from a Flight plan listing ,
then enter that number at L:SetAlternateAP, elsewhere in you instrument ,
or
are you getting the instrument to automatically detect the largest
c:FlightPlanWaypointIndex number for the current Flt Pln.

Cheers
Karol

 

[rpmc]

How are you advising the Alternate search what the destination airport
c:FlightPlanWaypointIndex number is ?

Apologies for speaking for Greg here, but as I recall from discussions of the development of Greg's gauge, his flight plans are two waypoints only - departure and destination. Unless his FP's are now more complex, the required index is always 1 and that's what Greg shows in his code snippets.

Bob

 

[swift39]

Thanks Karol,

If I am understanding your question I used

1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLatitude, Radians) (>@c:NearestAirportCurrentLatitude, Radians) 
1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointLongitude, Radians)  (>@c:NearestAirportCurrentLongitude, Radians) 
       11 (>@c:NearestAirportMaximumItems)

to determine the search parameters of the Alternate Airport search. It displays 10 airports close to the destination. The next step is the user will enter the IDENT for the desired alternate airport and the will save to an (L:Var). I am trying to use Robbie McElrath's set of Macros to save strings to (L:Vars) which I hope will achieve four bits of information. Three of this will be displayed on the Flight Planner Page giving the Alternate Ident, Name and City and the fourth the IDENT (L:Var) will arm another button that when pressed will add/delete waypoints to make the Alternate Airport the Destination Airport.

What I have started with the Macro's is this:

Mouse Section:

<!-- Set Alternate Airport BUTTON -->
  <Area Left="478" Top="635" Width="100" Height="25">
    <Visible>(L:EnterAltAP, bool)</Visible>
    <Cursor Type="Hand"/>
    <Click>
    0 (>L:EnterAltAP, bool)
    'A' (>@c:IcaoSearchStartCursor)	
    (L:ALT-AP-4,number) chr (L:ALT-AP-3,number) chr 
    (L:ALT-AP-2,number) chr (L:ALT-AP-1,number) chr scat scat scat (>@c:IcaoSearchEnterChar) 
    (@c:IcaoSearchMatchedIcaosNumber,number) 0 &gt; 
    if{ (@c:IcaoSearchCurrentICAO) (>@c:FacilityICAO) 
     (@c:FacilityIdent) @FromString(L:AltAP_IDENT) 
     (@c:FacilityName) @FromString(L:AltAP_Name)
     (@c:FacilityCity) @FromString(L:AltAP_City) }
    0 (>L:ALTAPEntry, enum) 
    0 (>L:ALT-AP-1,enum) 0 (>L:ALT-AP-2,enum) 0 (>L:ALT-AP-3,enum) 0 (>L:ALT-AP-4,enum)
0 (>L:SetAlternateAP,bool)	
1 (>L:FlightPlanDisplay,bool)			
</Click>
  </Area>

Key Section:

<!--**************** Set Alternate Airport ****************-->
<On Key="Alphanumeric"> 
<Visible>(L:ALTAPEntry, enum) 1 ==</Visible>
(L:ALT-AP-3,enum) (>L:ALT-AP-4,enum)		
(L:ALT-AP-2,enum) (>L:ALT-AP-3,enum)
(L:ALT-AP-1,enum) (>L:ALT-AP-2,enum)
(M:Key) (>L:ALT-AP-1, enum) 
@ReadKB(L:AltAP_IDENT)	
@ReadKB(L:AltAP_Name)
@ReadKB(L:AltAP_City)			
</On>

From the Flight Planner Page Element:

 <String>%FLIGHT PLANNER\n\n
          %DEPARTURE AIRPORT:\t\t\t%(0 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointIdent))%{if}%((@c:FlightPlanWaypointIdent))%!s!\t\t
          %{else}%Flight is Direct To%{end}%\n
          %(0 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointICAO) (>@c:FacilityICAO) (@c:FacilityName))%!s!\t\t\t\t
          %((@c:FacilityCity))%!s!\n\n
          %DESTINATION AIRPORT:\t\t\t%(1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointIdent))%!1s!\n
          %(1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointICAO) (>@c:WaypointAirportICAO) (@c:WaypointAirportName))%!s!\t\t\t\t
          %((@c:WaypointAirportCity))%!s!\n\n
          [COLOR="Red"]%ALTERNATE AIRPORT:\t\t\t%(@ToString(L:AltAP_IDENT))%!s!\n
          %(@ToString(L:AltAP_Name))%!s!\t\t\t\t%(@ToString(L:AltAP_City))%!s!\n\n[/COLOR]
          %DISTANCE TO DESTINATION:\t\t%((@c:FlightPlanWaypointDistanceTotal, nmiles))%!.1f!\{dpl=nm}\n
          %HEADING TO DESTINATION:\t\t%((@c:FlightPlanWaypointMagneticHeading, degrees))%!03d!\{dplo=M}\n    
        </String>

I know I don't have the the macro's programmed right and still trying to figure out how to use them properly, because the above code just gives me a display of three IDENTS (see pics). I am thinking it is in the Key section, but need to read more of Bob's link to figure it out, but feel I am getting close.

The link to Robbie McElrath's Macros:
http://www.fsdeveloper.com/forum/showthread.php?t=94088

Sorry about the long windedness of my response and hope I answered your question. Thanks Again

Greg

 

[swift39]

Apologies for speaking for Greg here, but as I recall from discussions of the development of Greg's gauge, his flight plans are two waypoints only - departure and destination. Unless his FP's are now more complex, the required index is always 1 and that's what Greg shows in his code snippets.

Bob

No worries and Thanks Bob,

Yes my gauge is still only using two waypoints with the edition of one on stand-by in a (L:VAr), if I can call it that, that when activated becomes waypoint number 1.

Thanks Again
Greg

 

[COBS]

Greg

See the thread at following link
http://www.fsdeveloper.com/forum/showthread.php?t=427754

The following will return your required info for your Alternate

<String>%Name: %((@c:FacilityName))%!s!</String>		
<String>%City: %((@c:FacilityCity))%!s!</String>
try
%DESTINATION AIRPORT:\t\t\t%(1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointIdent))%!1s!\n
%(1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointICAO) (>@c:WaypointAirportICAO) (@c:FacilityName))%!s!\t\t\t\t
%((@c:FacilityCity))%!s!\n\n

Cheers
Karol

 

[COBS]

Or try

 %DESTINATION AIRPORT:\t\t\t%(1 (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointIdent))%!1s!\n
          %((@c:WaypointAirportName))%!s!\t\t\t\t
          %((@c:WaypointAirportCity))%!s!\n\n

Cheers
Karol

 

[rpmc]

The following will return your required info for your Alternate ...

Karol, I completely agree with your approach of fetching and displaying the alternate airport string info using gps variables in a element string when such info needs to be displayed. This is far easier than storing this string information using Robbie's LVars and then retrieving and displaying that information.

String storage doesn't appear to be necessary in Greg's specific application because the FlightPlanWaypointIndex (or the Ident or the ICAO) is always known and the desired airport string info can therefore be retrieved from the database at any time.

Greg, if you really need to store the airport Ident that the user selects as the alternate airport, then I would suggest use of a simple shift register technique rather than Robbie's string storage macros. There is a description of it in the GPS Guidebook. Robbie's macros allow storage of strings up to 64 characters long, but airport Idents are max 4 characters, so a shift register technique is the better choice.

If you're just going to display some of the alternate airport information, then I would follow Karol's suggestion.

Have fun,

Bob

Greg - my mistake - it looks like your application does call for storing the alternate airport Ident. The User chooses the alternate airport Ident after the nearest airport search is displayed. At some time later, the User may decide to activate the Flight Plan change to alternate destination airport using the stored Ident.

With that in mind, I would use a shift register to store the Ident because that technique is far better suited to a short string like an Ident and you wont need all of Robbie's macros.

When the change to the alternate airport is activated, then you retrieve the stored Ident and use it to create a new flight plan waypoint using FlightPlanNewWaypointIdent. Or, concatenate the retrieved Ident to the end of A_ _ _ _ _ _ (the letter A followed by six spaces) and use FlightPlanNewWaypointICAO. Set this as Index 1 and then delete Index 2 (the original destination airport).

 

[swift39]

Thanks to both of you,

Yes I agree the shift register technique (would be simpler) and using (@c:FacilityName) or (@c:WaypointAirportName) would do the job. But as I think Bob understands what I am no trying to achieve is when the user enters the IDENT of an Alternate Airport it is really doing nothing at that point, I will try and explain.

The user has ten alternate airports through the search portion, they then select one, enter the Ident via keyboard and the Select Alternate Page closes and returns to the Flight Planner Page.

Now to the user they see they alternate airport information hopefully something like this

ALTERNATE AIRPORT: CYVR
Vancouver Intl Vancouver, British Columbia

Visually the user, for all looks and appearances, has a completed Flight Plan with Alternate, when all that has actually happened is the information has been stored to a string and laying dormant until needed.

My rational for this process is I am thinking that if I add the Alternate Airport to the waypoint list right off the hop and the user fly's from Point A to Point B then the GPS is going to arm the leg to Point C (The Alternate Airport). I am just basing this on my knowledge of creating sail plans on the ships, which I don't want, right now I am looking at the user fly's the plan and if decides to divert to the Alternate it is a button push away which then adds it to the waypoint list otherwise when they create a new flight plan the Alternate Information is cleared and the process starts again.

Now correct me if I am wrong but I think this approach prevents me from using Karol's suggestion.

As for the use of shift register technique vs. Robbie's Macros. If I was just going to use the IDENT yes that makes perfect sense (you have taught me that in the past, thank you), but again in my mind with this information being "Stored" for potential future use and not wanting part of the Flight Plan until needed with the wish to have three pieces of information displayed on another page (for aesthetic purposes), would Robbie's Macro's be the best choice?

I was thinking the Macros because of the length of the name of some airports and city's, well as we all know can be rather large.

To sum it up this will give the user the option of setting up an Alternate Airport without creating any conflicts/undesired results in the gauge with the information being stored until needed.

This is just my train of thought and if either of you think your approach is the simpler or better/proper route to follow I am more than willing to pursue them, as the end result for me ultimately is proper and best practice coding techniques to which when it comes to both of your work I pale in comparison.

Hope this explains my current position on this project.

Have a great weekend
Greg

 

[ddawson]

You need a second GPS interface...

 

[rpmc]

Now correct me if I am wrong but I think this approach prevents me from using Karol's suggestion.

In a literal sense, yes, because Karol's suggestion requires that the Flight Plan has already been edited to include the alternate airport as the revised FlightPointWaypointIndex 1.

would Robbie's Macro's be the best choice?

I was thinking the Macros because of the length of the name of some airports and city's, well as we all know can be rather large.

You certainly can do it your way and store the city name using Robbie's macros during your alternate airport selection sequence - that is, when the User enters via keyboard their desired alternate airport Ident after the NearestAirport search has concluded, but before "activation" of the alternate airport. That will work.

Alternatively (and this is what I would do), you can store only the alternate airport Ident using a simple shift register technique and retrieve the city name from the gps database whenever you want to display it, even if the alternate airport is not part of the active Flight Plan (the User hasn't "activated" it yet, and it is not yet FlightPlanWaypointIndex 1).

To do that, concatenate the Ident with A_ _ _ _ _ _ to form, for example A_ _ _ _ _ _ CYVR and that becomes the airport ICAO (airport Idents are unique, so this concatenation shortcut always works and an ICAO search is not needed). Then, the gps variables WaypointAirportCity or FacilityCity will return the alternate airport city name. An ICAO transfer is involved so you need a brief cycle skipping step, and you need to remember to use the char operator to convert the ASCII code that is actually stored in the L:Vars into the string characters. Descriptions and XML examples of all of this are in the GPS Guidebook.

If the User ultimately decides to "activate" the alternate airport, then you retrieve the stored Ident and use it to edit the existing active flight plan using FlightPlanNewWaypointIdent. Or, concatenate the retrieved Ident to the end of A_ _ _ _ _ _ (the letter A followed by six spaces) and use FlightPlanNewWaypointICAO. Set this as Index 1 and then delete Index 2 (the original destination airport). Adding a new Flight Plan waypoint and deleting a waypoint are described on page 120 of the Guidebook.

If I understand your intentions correctly and if you follow these ideas, I don't see that you will require a second gps interface.

Bob

 

[ddawson]

...
If I understand your intentions correctly and if you follow these ideas, I don't see that you will require a second gps interface.
Bob

You're quite correct, of course. A second interface is not required. My post was meant more in the spirit of "Wouldn't it be nice if"
Putting one together actually proved a little easier than I thought, as its just a matter of creating a module and passing everything through it.

 

[rpmc]

Putting one together actually proved a little easier than I thought, as its just a matter of creating a module and passing everything through it.

A second gps unit with cross-fill?

Bob