OpenCPN PlugIn Development

[cryptik]

Originally Posted by bdbcat

Ken...

Consider:
1. #define INSTALLS_CONTEXTMENU_ITEMS 0x00000040

2. extern "C" DECL_EXP int AddCanvasContextMenuItem(wxMenuItem *pitem, opencpn_plugin *pplugin );

Squiddio does this.....

Dave

Hi Dave, thanks for the quick response. I actually got that working. What I can't figure out is how to add it to the menu that appears when you hover over and right click on an AIS target.

See this capture... I can add to this normal menu. The "xxxxxxxx" entry is the one I was able to add.

https://imgur.com/a/vegaRFf

This next image is the context menu that appears when an AIS target is selected. Is it possible for me to add a menu item to this location from the plugin... or would I need to modify the OCPN base code?

https://imgur.com/a/wAyJoCZ

Essentially, what I want to do is be able to select an AIS target and send its information to my plugin... or at least enough info that allows me to look up the target in the target list.

There is a "copy MMSI" option in the AIS target context menu, but I was hoping for a tighter integration.

- thx
Ken

[bdbcat]

Ken...

"What I can't figure out is how to add it to the menu that appears when you hover over and right click on an AIS target."

Not implemented in current API.

Sorry
Dave

[Rasbats]

Just a thought. What about building your own AIS list? You have the stream of AIVDM messages. Could you filter as necessary using an MMSI or the location based on your mouse click? Then select from the list and just select the messages from that target?


Mike

[cryptik]

Hi Mike, that's actually not a bad idea. I may have to do that. That brings up another question for me. Is there no access made available to the current AIS target list? Here is my scenario. I have an MMSI that I want to track in my plugin. Is there an API exposed that will let me see the target list... or be notified when a particular target appears in the list?

If there is no access at all to the AIS target list... I guess I will need to go ahead and decode the AVDM messages as they come in.. looking for one with a particular MMSI.

Any advice would useful. I don't mind writing the code, I just don't want to reinvent the wheel if I don't have to...lol

V/r
Ken

[cryptik]

Nevermind...lol. I just looked at the plugin API header file in more detail. For some reason I missed all the declared external functions at the top. I can see the AIS target list access functions.

So, I will refine my question. I can call OpenCPN and ask it to give me the target list. Is there a way to get it to notify me when the list changes? I can override the SetAISSentence() method in the plugin, but this method does not appear to every get called. What is the recommended way to have my plugin triggered when it should go look at the target list again? I suppose I could setup a timer, but this seems inefficient.

v/r
Ken

[bdbcat]

Ken...

Your best approach will be to monitor the AIS message stream, and decode the messages that you are interested in yourself.

I don't expect to add more API functions to enhance the AIS data interface. We would never think of the complete and correct (i.e. useful) set of APIs beyond what you need now, anyway. Further, we would be adding complexity to the base program for the sake of one Plugin. Not a great tradeoff in the big picture...

Just grab the AIS parsing code from the base source, and duplicate it in your plugin as needed.

Good Luck
Dave

[cryptik]

Thanks Dave, I think that seems the right thing to do. One other quick question. I am confused as to what ODAPI is. I understand it can be used to draw boundaries and create objects. But... if I want to say draw a circle around a lat/lon position on the map... from within my plugin... do I need to use ODAPI or can this be done with what is available in the OpenCPN plugin API?

thx,
Ken

[bdbcat]

Ken...

You can draw directly on the chart using the API:

virtual bool RenderOverlay(wxMemoryDC *pmdc, PlugIn_ViewPort *vp);

Remember to set WANTS_OVERLAY_CALLBACK in the init function.

This is how wmm_pi draws declination map overlays, for example. Check it out.

Dave

[cryptik]

Thanks for pointing me in the right direction Dave. I was able to get the draw functions working for both the render and renderGL functions.

Off hand, do you know if there is a programmatic way to call the "Navigate to here" function in the context menu? I would like to be able to programmatically turn on the "Navigate to here" function given a specific waypoint as well as turn it off.

- thx
Ken

[cryptik]

Another newbie question here. I am currently building OpenCPN (debug) and my plugin using VS2013. I want to use C11 compiler features in my plugin development code. Is it possible to compile the plugin using gcc on windows (i.e. msys, etc.) and still run that plugin in the standard opencpn?

I know the plugin is a DLL that is loaded by Ocpn. Does it matter if that DLL is built using gcc or vs2013?

v/r
Ken

[cryptik]

One other related question.. the instructions for compiling OCPN with 2017 indicates that we should use the following line to build wxWidgets:

nmake /f makefile.vc BUILD=release SHARED=1 CXXFLAGS=/D_USING_V110_SDK71_ CFLAGS=/D_USING_V110_SDK71_ LDFLAGS=/SUBSYSTEM:WINDOWS“,5.01”

Is this correct? The reason I ask is that the 2013 instructions use D_USING_V120_SDK71_ and it seems that V110 would be an older SDK? I could not find any MS documentation on what these flags actually mean.

thx,
Ken

[transmitterdan]

Originally Posted by cryptik

One other related question.. the instructions for compiling OCPN with 2017 indicates that we should use the following line to build wxWidgets:



nmake /f makefile.vc BUILD=release SHARED=1 CXXFLAGS=/D_USING_V110_SDK71_ CFLAGS=/D_USING_V110_SDK71_ LDFLAGS=/SUBSYSTEM:WINDOWS“,5.01”



Is this correct? The reason I ask is that the 2013 instructions use D_USING_V120_SDK71_ and it seems that V110 would be an older SDK? I could not find any MS documentation on what these flags actually mean.



thx,

Ken

Ken,

The flags are not exactly MS runtime version specific. They are specific to the wxWidgets headers and linker steps. They control how wxWidgets interacts with MSW and Windows XP. They don’t really have a relationship to a specific runtime. I believe they are correct. It has been some time since I searched the wxWidgets headers to see which the flags are still needed. But I build everything in VS2017 these days and it works.

You can use VS 2017 to get more recent compiler features. But VS 2013 is the compiler of official O distribution because it will build a XP compatible executable. Plugins built with VS2017 cannot run inside the official O release. Once we go to VS2017 for O it gets harder to keep XP in the mix. Someone was working on using 2017 to build an XP compatible release. But in reality the amount of workarounds to keep XP compatibility is getting longer and longer. At some point it may become unworkable to keep XP as an official target for all plugins.

Someone tried to build O using mingw but that track is cold. I think a better solution would be to build O under CygWin. I would think that has a good chance of staying relevant for a few more years. But O users running Windows simply don’t want to download CygWin or mingw. The constant string of updates are not automatically applied and it takes a lot of data for users on cell or satellite links.

[seandepagnier]

opencpn compiled fine with mingw a few years ago. It probably still can. It also worked perfectly fine, and could be packaged into an installer that was few mb smaller than the msvc version.

Further, it cross-compiled from linux to make windows binaries and installers perfectly fine. The biggest disadvantage is, mingw is slower for compiling c++.

For unknown reasons, no one using windows was interested. It doesn't make any sense, but then again, using windows at all doesn't make any sense.

[cryptik]

thx for the response. I understand completely. In a perfect world, we would not have to support windows at all...lol.

One other question, VS2017 has a compiler setting "/permissive-" that turns on or off permissive mode. In 2017, this flag is set to "allow" permissive mode by default. Does anybody know how I would turn this off in a CMake file so that the cmake generator for VS2017 would set it to "/permissive-" (i.e. off)

EDIT: I think I got that wrong. In the VS2017 setup for the project ,there is a setting called "Conformance mode". By default, it is set to "Yes (/permissive-)". When compiling for the XP 141 toolchain, I get the following SDK error:

>c:\program files (x86)\microsoft sdks\windows\v7.1a\include\objbase.h(239): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier'

Looking thus up on google, it seems there is a problem with 2017 and the older SDK. MS posts indicated that they have not fixed all of them.

When I set the "Conformance mode" to "No", the problem goes away. How can I set this option as default in my CMake file when generating VS2017 code?

thx,
Ken

[rgleason]

Originally Posted by boat_alexandra

For unknown reasons, no one using windows was interested. It doesn't make any sense, but then again, using windows at all doesn't make any sense.

That may be so, but there are a lot of us and I tried MingW for awhile, not compatible with the main Win Dev platform.