Board index FlightGear Development Canvas

Canvas ND on another aircraft than Boeing and Airbus

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Mon Sep 26, 2016 10:10 pm

Hello,

To transform the old CitationX NavDisplay, I've studied the navdisplay.mfd, the navdisplay.styles and the wiki Canvas ND Framework.
So I know that I have to add a new hash in "navdisplay.styles" which is located in ".../Nasal/canvas/map".
That will not cause problems for others users that this file is not located in the airplane files ?
clm76
 
Posts: 204
Joined: Tue Oct 30, 2012 9:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2020.4.0
OS: Linux Mint 20.2

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Tue Sep 27, 2016 9:12 pm

everything you said is entirely correct - feel free to get in touch if you need any clarification/explanations regarding the docs/code that you can find.
It would be greatly appreciated if you could document your journey - I won't mind to review the corresponding code and extend the docs where needed.
My only request would be to help us review/extend the wiki docs accordingly, so that others can more easily do what you are doing.
In general, it would also be a good idea to get in touch with artix who has the most recent experience modifying the ND "framework" in a major way.
Apart from that, you will want to make sure that you understand Nasal basics, especially hashes.
Apart from that, the "framework" is sufficiently basic that you won't need to understand much/any OOP - it basically works by traversing a vector of hashes that contain callbacks that invoke each other, i.e. the first callback checks some configurable condition, and then there are true/false callbacks that will be invoked depending on the conditional check.
So it really is rather basic (but very convoluted) - you can definitely review the Boeing/Airbus code to learn how everything works, and even copy the existing code and modify it according to your requirements.
There are some "todo" items on our list (see the wiki), but for those you will want to really understand the .mfd file itself, which provides the underlying framework to make the *.styles stuff work - which really is all you (should) need to understand to add/customize other styles.

Note that in general, your final question seems to suggest that shipping such aircraft specifics would be a good idea - and it does sound good in theory, but in practice, the "framework" part of said code hasn't much evolved since its early days (which is heavily based on Gijs' original implementation that would only support a single aircraft/instrument, style and instance) - so that it really does make sense to add to a single *.styles file, and extend/modify the .mfd file according to any requirements, so that all aircraft, and aircraft developers, can benefit from the way this will unfold, regardless of their aircraft/priorities.

I think artix managed to break/work around this idea by using some very fancy/clever, and unprecedented, Nasal hacks - so if in doubt, get in touch with him or even just review his code.

Speaking in general, we were hoping for the ND stuff to become sufficiently generic so that it would primarily work in terms of what you see in the .styles file, and to let the .mfd file become sufficiently generic to also let other displays like the PFD be supported. Since then, many things have changed and happened - so that it would actually make sense to clean up the mfd file to use Richard's MFD framework, and prepare it for using Richard's Emesary framework, too.

As usual, spare time is our primary constraint - so, obviously anybody interested in using/extending the system is invited to get involved - if in doubt, feel free to get in touch with fgdata committers who can help you get your changes committed - I think Hyde, Richard and others have used the system more recently (see the wiki for details).

Finally, if you are familiar with OOP, the ND code will look fairly alien to you - but the whole .styles approach is there for a reason, it would at soem point be possible to make the whole thing totally declarative (think PropertyList XML), and to encapsulate concepts like animation handling, so that there is a single Nasal API implementing the details, which will also make it much easier to update all instruments/code using such APIs, which means that core changes will propagate much better, and more easily, than not using a purely declarative approach - which is the primary reason why we ended up using a bunch of embedded hashes, so that the whole thing could evolve beyond supporting just a single instrument, aircraft, instance or ND - i.e. for arbitrary MFDs, including Gijs' original PFD work.

The other use-case this approach can easily support is MFDs shown in GUI dialogs, even without requiring an actual aircraft/cockpit - including even independent instruments linked to different "source aircraft" (think AI/MP traffic nodes) - all of this is to say that there are no hard-coded dependencies to the aircraft, i.e. the whole thing is configurable via a driver hash, and the motivation for that was supporting avionics for arbitrary purposes, imagine AWACS aircraft with an actual ATC station, or showing traffic conflicts from different perspectives, or even just integrating MFDs with the tutorial system.

All of this is not just prepared but actually working and very accessible to people not very familiar with coding - so even in the light of the current "design", it's a rather functional piece of a hack by most standards ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Fri Sep 30, 2016 7:38 am

Thanks for very interesting and instructive replay.

After many tests and learnings, i managed to modify symbols and fonts, size and colours, of existing Boeing symbols to adapt them to my aircraft.

And... I've some other questions :
1 - I read that to create a new symbol, we must create the files *.symbol, *.lcontroller and *.scontroller.
In the path ".../fgdata/Nasal/canvas/map", only WPT have these three files. APT, VOR FIX... have only *.symbol and *.lcontroller. Why ?

2 - navdisplay.mfd calls navdisplay.styles which calls "...Images/boeingND.svg" (or airbusND.svg). If I create a new symbol located in my aircraft path, how can I call it ?
clm76
 
Posts: 204
Joined: Tue Oct 30, 2012 9:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2020.4.0
OS: Linux Mint 20.2

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Sat Oct 01, 2016 11:16 am

The main thing to understand is that there is a "separation of concerns" in place - the design pattern used by the MapStructure framework is called "Model View Controller" (MVC). The wikipedia article goes into more detail - but basically this means that the appearance of the symbol is controlled separately, as is the position on the display and the update semantics/heuristics.

It is this separation of concerns that makes it possible to reuse a MapStructure layer for different purposes, which means not only separate aircraft/cockpits, but also use-cases beyond just aircraft, including AI/MP traffic, but also standalone use in GUI dialogs (without even a proper FDM being available).

In other words, it would be technically feasible, and straightforward, to display the cockpit view of a ND from the perspective of an AI tanker, or even AI missile - with navaids, airports and other traffic properly displayed.

Furthermore, this means that the apperance, layout, styling, size, color etc of individual layers/symbols can be individually controlled/overridden by specifying custom callbacks to customize the corresponding behavior.

If all you want to do is using custom symbols, you really only need to understand how to use an SVG editor like Inkscape, using the existing svg file as a template, and/or extending that to add new symbols to it.

For the time being, it would be best to add a corresponding aircraft-specific "layer" to that file and specifically use that - e.g. by ignoring Boeing/Airbus specifics, and using only the custom imagery you add.

The *.symbol/.lcontroller and .scontroller thing you mentioned is correct - but you really only need to understand those files if you want to add a totally new "layer". A layer is a new type of data that you'd like to display on the map, such as new navaids (think microwave landing system, new types of traffic (think spacecraft, satellites etc) or custom airports (think space shuttle landing sites)

If all you want to display is existing data, using a different visualization, you should be all set and can simply continue to use the existing layers (lcontroller) while overriding/customizing the apperance of the symbols using custom SVG items, and if necessary custom animation/update callbacks.

The scontroller files are symbol-controller files - whereas lcontroller files are layer-controller files.
A layer is a map layer, e.g. one displaying VORs, NDBs etc - each symbol can be separately controlled using a scontroller file, e.g. for animating symbols.
Obviously, many "map layers" get away with less sophisticated heuristics - e.g. an airport or navaid layer will merely need to display non-moving (static) symbols, because airports/navaids don't change position each frame - multiplayer/AI traffic is a different beast, it is more fancy because it's actually moving symbols that are visualized, so it may need to update individual symbols - the corresponding MapStructure layer is named "TFC" (for traffic), which is the common abbreviation seen on Boeing-style aircraft.

Regarding your 2nd question - those files don't actually "call" eachother, but they merely reference eachother - the .mfd file contains the core logic that can be customzed using the .styles file, which in turn contains a hash with styling specific heuristics for different aircraft, the SVG file is what is used to provide the artwork that is processed by the corresponding styles file.

Thus, as per Gijs' original recommendation, you should really only update/add to the SVG file to add support for your own aircraft specific symbols/artwork, and then add a corresponding aircraft specific entry to the .styles file - you really should not be adding aircraft specifics to your aircraft specific folder for the time being - this is primarily to discourage incompatible additions, but also to ensure that contributions are fostered in a central place that will benefit all aircraft developers - equally, it's a way to ensure that there will be some basic oversight - because all aircraft developers using the ND framework can keep track of all changes.

The long term vision really was to make the whole .styles/.svg mapping fully declarative (potentially turning the hash into PropertyList-XML at some point), and having only the .mfd file containing generic Nasal code, that would be augmented through c++ space additions over time (think for animation handling). At that point, there would only ever be a single point to update if/when new Canvas features become available, without any of the aircraft having to be updated inevitably.

Equally, that would make it possible to further generalize the navdisplay.mfd file to be use-case agnostic, i.e. also usable for other MFDs, like Gijs' original PFD.

Thus, depending on the aircraft you are working, the best advice would be to either adapt existing SVG files, or use one of the existing files as a template ,customize that, rename the whole thing and use that when instantiating the ND (see the wiki instructions) - at that point, you will have your own "ND style", consisting of 1) a custom SVG file, an additional entry in the styles file, and a matching instantiation block for your ND.nas file.

However, do note that the way this whole thing was originally designed, your $FG_AIRCRAFT directory is supposed to only ever contain the instantiation logic and not any aircraft specifics, which are really supposed to go into the base package, to help grow a library of general purpose ND related symbology/files, but also a library of general-purpose update/animation routines contained in the navdisplay.styles files, as well as new/custom MapStructure layers in $FG_ROOT/Nasal/canvas/map

This is the only sane way to ensure that we can grow and generalize a general-purpose framework for ND/MFD handling purposes, without people adding tons of custom Nasal code to their aircraft that will never be easily reusable by other aircraft/developers.

Note that we fully realized that the current "design" is far from perfect, but it turned out to be really accessible to non-coders, and it was specifically created to foster contributions and involvement benefitting developers mutually by "forcing" them to collaborate (e.g. anything that Gijs created can be reused by Hyde and vice versa) - equally, all MapStructure layers can be used by arbitrary aircraft, and in arbitrary GUI dialogs.

All this was largely motivated by wanting people to contribute to $FG_ROOT (the base package) instead of coming up with fancy avionics that are highly aircraft specific and usually impossible to reuse elsewhere without using massive copy&paste.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby D-ECHO » Sat Oct 01, 2016 11:45 am

@Hooray, do you always type these huge pages-long texts yourself or are they copied from the wiki? ;D
It's somehow impressive :D
D-ECHO
 
Posts: 2460
Joined: Sat May 09, 2015 1:31 pm
Pronouns: Bea (she/her)
Version: next

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Sat Oct 01, 2016 12:03 pm

D-ECHO wrote in Sat Oct 01, 2016 11:45 am:@Hooray, do you always type these huge pages-long texts yourself or are they copied from the wiki? ;D
It's somehow impressive :D


Actually, the opposite is usually the case: I tend to respond on the forum, and then copy useful stuff over to the wiki, to help provide a "goto-place" for people having similar questions in the future.

Besides, I actually once helped rewrite some ND related code and came up with the whole "hashes-with-vector-with-callbacks" approach which makes the whole thing a little convoluted and messy, but extremely accessible to non-coders, because it's a very declarative thing - so it makes sense to document the whole thing, because it would only take a Python/Nasal script to turn this hash-stuff into a PropertyList-XML file with embedded Nasal code (or even generic tags at some point).

But I do hope that people will review what we have in terms of docs and ask for help on the forum, and maybe get involved in helping maintain/update the corresponding docs over time, even if just by documenting their own journey using/extending and adapting the ND code for other aircraft.

As a matter of fact, it would actually be great to document the steps for adding a custom CitationX implementation - so I do hope that I can provide sufficient information for clm76 to come up with a rough protoype that he can adapt accordingly. It's not overly complicated actually, and does not require much in terms of programming to come up with a custom SVG file containing said symbols, and a copied NDStyles entry to add custom heuristics for the CitationX specifically

Over time, the ND code, and the Canvas system will greatly benefit from growing such a library of ND "styles"
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Sat Oct 01, 2016 10:07 pm

I understand your point of view to not implement canvas code nasal in aircraft path... but imagine that I finalize the CitationX ND display and export it in the navdisplay.mfd, navdisplay.styles and others : Then, I think that you will update() this files in a new (or updated) version of fg. If any user wants to load or use the aircraft with a not updated version of Fg, he will encounter many errors, no ?

Quite apart from that, to test my ND on the MFD display, I overwrite the PFD with the Boeing ND code, to have the two ND's next to the each other, with only Airports displayed.
But, surprise !... when I increase the range, for example from 40 to 80 nm, only a few APT are displayed on the both ND.
Image

When I decrease the range, for example from 100 to 80, much more airports (all in the range ?) are displayed.
Image

Note : On my ND (MFD), all the airports are displayed during about 1 second when the range decrease, then disappear.

Is it a bug ?

The code for the ND on the PFD is the 777 ND.nas.
My code (on the MFD) is this one :
Code: Select all
var MFD_canvas = {
   new: func() {
      var m = {parents:[MFD_canvas]};
      m.canvas = canvas.new({
         "name": "MFD",
         "size": [1024, 1024],
         "view": [900, 1024],
         "mipmapping": 1
      });
      m.canvas.addPlacement({"node": "ND.screen"});
      var mfd = m.canvas.createGroup();
      canvas.parsesvg(mfd, "Aircraft/CitationX/Models/Instruments/MFD/MFD.svg");

      ### NavDisplay ###
      myMap = mfd.createChild("map");
      myMap.setController("Aircraft position");
      if (range.getValue() != nil) {
         myMap.setRange(range.getValue());
      }
      myMap.setTranslation(450,485);

      var r = func(name,vis=1,zindex=nil) return caller(0)[0];
      var type = r('APT');
      var style = {scale_factor:0.8, color_default:[0,1,0.9],line_width:4,label_font_color:[0,1,0.9],label_font_size:30};
      myMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,style:style);

      ### Texts init ###
      m.text = {};
      m.text_val = ["wx","bank","tcas","sat","tas","gspd","clock",
                           "chrono","navDist","navId","navTtw","navType",
                           "hdgAnn","main","range","hsi","rangeL","rangeR"];
      foreach(var i;m.text_val) {
         m.text[i] = mfd.getElementById(i);
      }
        ......
               
clm76
 
Posts: 204
Joined: Tue Oct 30, 2012 9:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2020.4.0
OS: Linux Mint 20.2

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Sun Oct 02, 2016 7:23 am

You are right, and that is exactly the reason why artix ended up using the approach you can find being used on the A320-neo (?).
However, keep in mind that you need to be enormously experienced to make that work - artix definitely had prior coding experience, tons of it I would say.
Personally, I would not be able to pull that off so quickly, despite having been involved in the corresponding Canvas/ND code, and despite still being familiar with it.
And in the light of the current release schedule, the best option is to simply extend the framework and file a merge request - once that is in, you can still come up with "glue" bindings to make the whole thing work for older FG versions (which basically is what artix's compat module is doing).
But still, if you don't have a strong coding background and if you don't want to familiarize yourself with SG/FG internals, you are better off doing it the conventional way.


What you describe sounds not like a bug in the ND code, but like a bug in your bindings handling code (the myCockpit_switches hash).
Keep in mind for that to be an actual bug, it would have to show up prominently on other aircraft using the ND framework already - e.g. the 747 or the 777.
If you cannot reproduce an issue there, it's most likely something related to your own aircraft.
Personally, I tend to recommend to use a separate GUI dialog for prototyping new avionics - i.e. a standalone Canvas GUI dialog to integrate everything.

If you simply reused existing code without adapting it, it's unlikely to work unless you also update the corresponding bindings/properties and placements to be valid.
Which is to say that if the the display does not update when clicking a cockpit hotspot, that hotspot event is not properly propagated to the framework - which is usually because of missing/invalid properties (think typos)

But again, given the nature of your questions, I would definitely recommend to only explore using artix's approach once you have the basic thing working, otherwise the whole experience may become very frustrating, because creating the glue code is certainly a challenging experience, especially in the light of your current questions, and that your current Nasal/Canvas and FG background may be insufficient to do this sort of thing quickly.

Like I said, it would take me quite a bit of work to even just remotely understand what sort of glue code needs to be copied into the aircraft directory to make it work.
If you are feeling really brave, review artix's work in the A320-neo repository - but I personally, I would not bother with it until you have the thing fully working "as is".
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby clm76 » Sun Oct 02, 2016 5:01 pm

Is it a bug ?

After checking, the 777 have the same problem !...
Example with range = 80nm :
With range increased from 40 to 80nm : only 3 airports
Image

with range decreased from 160 to 80nm : 8 airports
Image

More airports by decreasing the range than increasing. ???
clm76
 
Posts: 204
Joined: Tue Oct 30, 2012 9:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2020.4.0
OS: Linux Mint 20.2

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Sun Oct 02, 2016 5:17 pm

If you can reproduce the problem with several other aircraft, it's most likely that the corresponding property isn't triggering an update/redraw event - if in doubt, I would first check that this is the case by testing the 777 and 747 (independently), and then get in touch with Hyde/Gijs - you should be able to determine the property that isn't triggering the update, and then take it from there - in general, it is worth pointing out that this is unlikely to be a difficult bug to nail down, simply because there is only a single 5-line routine registering the corresponding event handlers, and it seems to be working for all the other "events" (myCockpit_switches) - thus, it is most likely that the corresponding binding or property simply doesn't invoke the redraw/update handler.

Personally, I would suggest to also try to reproduce the same issue using the map-canvas.xml dialog (equipment menu IIRC), that would tell you if the problem is in aircraft related code, or if it's in one of the MapStructure layers (e.g. VORs, NDBs, DME etc)

http://wiki.flightgear.org/Canvas_MapStructure
Image

There also is a pure/Canvas-only test dialog available via the DEBUG menu:
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby wkitty42 » Sun Oct 02, 2016 5:41 pm

when i've seen this, i've attributed it to the removal of smaller airports and keeping only the larger ones... is that wrong?
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9147
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Sun Oct 02, 2016 6:30 pm

yeah, the OP is right: if increasing the range from X to Y does not show the same number of airports as when decreasing the range from Y to X, then it's a "bug" - i.e. in the sense that one of the two actions does not seem to trigger the corresponding update/redraw.
But it's not like it's a complicated issue - like I said, it's most likely a single listener/callback that isn't invoked, usually because of some kind of missing binding, and/or typo in a property name.

However, what you describe would be possible to implement, and as far as I understand, "size-based filtering" is indeed applied to airports shown by the hard-coded ND.

It's not like it would be difficult to implement with the Nasal/Canvas ND - there already is a so called "searchCmd" method that is used for all sorts of filtering, this is also where the AI/MP MapStructure layer (called TFC) filters the corresponding /ai nodes in the property tree.

To exclude/filter airports accordingly, all that is required is coming up with the corresponding criteria (e.g. number of runways and length) and then conditionally include/exclude those - which is to say, it would take roughly ~5 lines of Nasal code that would need to be added to APT.lcontroller

But as far as I remember (not having looked at those files in years), nothing like this is currently implemented - so it really is most likely an actual bug if it can be reproduced with different aircraft using the ND component
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Gijs » Mon Oct 03, 2016 9:10 am

The ND (and map) does filter airports based on their runway length (can be adjusted through /sim/navdb/min-runway-length-ft), but this is independent of range. The behaviour described here is different, so I'll try to have a look at the code later today.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Gijs » Mon Oct 03, 2016 7:40 pm

Right, the problem is that the airports are loaded before the map is drawn. The searchCmd (in Nasal/canvas/map/APT.lcontroller) uses the current range of the map, so at the time of loading airports that's still the old range :-( I need to re-familiarise myself with MapStructure to see if I can fix this. Maybe Hooray remembers how it all works?
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Canvas ND on another aircraft than Boeing and Airbus

Postby Hooray » Tue Oct 04, 2016 4:42 pm

I am not sure that I understand your analysis of the problem or that I agree with it - searchCmd() is a method that will be invoked whenever a layer needs to be updated - thus, any relevant state changes (including range of the map) should be picked up automatically.
Thus, the first step would be enabling/adding a print() statement there to print something to the console whenever the APT.lcontroller file's searchCmd() method is invoked, and then loading fgfs to change the corresponding settings and see if the callback is triggered or not, and then take it from there.

Looking at the lcontroller via: http://wiki.flightgear.org/Canvas_MapStructure_Layers
The latest version seems to be this: https://sourceforge.net/p/flightgear/fg ... controller

So, my suggestion would be to uncomment the first line in the searchCmd() method to see if the APT query is updated once the map's range is changed.
Likewise, it may make sense to debug.dump(range) prior to the if block
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 5 guests