Ocpn-Draw and Boundary

[jongough]

Gerhard,
I must admit the plugin has been going through quite a lot of changes as I fix it up based on user feedback. I am hoping that the rate of change will now slow down as I think many of the bugs have now gone. There may be minor changes going in as users find issues, but could you try the latest, 655, patch and see if there are any glaring issues? I know we found some with internationalisation and windows, so I would be very interested if there are issues with the Mac.

Thanks
Jon

Originally Posted by CarCode

Jon,
I have once tested draw_pi with Mac OS X El Capitan and wxWidgets 3.1.0. After some changes to avoid crashes and asserts I got it working last year and the *.dylib still works with OCPN 4.2. I guess it was your code from August and September last year. I abandoned the project at this time seeing your code changes each day. You can find my attemps to compile your code at this time at:
https://github.com/CarCode/Cocoa-OCP...lugins/draw_pi

If I have some sparetime I will update your code and try it again. However it will be of no use for others because I use my own environment.

Gerhard

[Hakan]

Jon
Thanks but received the following while built in VS13:

 Creating library C:/Builds/OCPN/ocpn_draw_pi/build/Release/ocpn_draw_pi.lib and object C:/Builds/OCPN/ocpn_draw_pi/build/Release/ocpn_draw_pi.exp
EBLProp.obj : error LNK2019: unresolved external symbol "class PlugIn_Position_Fix_Ex g_pfFix" (?g_pfFix@@3VPlugIn_Position_Fix_Ex@@A) referenced in function "public: virtual bool __thiscall EBLProp::SaveChanges(void)" (?SaveChanges@EBLProp@@UAE_NXZ)
C:\Builds\OCPN\ocpn_draw_pi\build\Release\ocpn_draw_pi.dll : fatal error LNK1120: 1 unresolved externals


C:\Builds\OCPN\ocpn_draw_pi\src\EBLProp.cpp(73): warning C4067: unexpected tokens following preprocessor directive - expected a newline
C:\Builds\OCPN\ocpn_draw_pi\src\EBLProp.cpp(120): warning C4067: unexpected tokens following preprocessor directive - expected a newline
C:\Builds\OCPN\ocpn_draw_pi\src\ODPropertiesDialogImpl.cpp(164): warning C4067: unexpected tokens following preprocessor directive - expected a newline
C:\Builds\OCPN\ocpn_draw_pi\src\ODPointPropertiesImpl.cpp(82): warning C4067: unexpected tokens following preprocessor directive - expected a newline

Håkan

[jongough]

Håkan,
Just found this myself. Patch 656 fixes this.

Regards
Jon

Originally Posted by Hakan

Jon
Thanks but received the following while built in VS13:

 Creating library C:/Builds/OCPN/ocpn_draw_pi/build/Release/ocpn_draw_pi.lib and object C:/Builds/OCPN/ocpn_draw_pi/build/Release/ocpn_draw_pi.exp
EBLProp.obj : error LNK2019: unresolved external symbol "class PlugIn_Position_Fix_Ex g_pfFix" (?g_pfFix@@3VPlugIn_Position_Fix_Ex@@A) referenced in function "public: virtual bool __thiscall EBLProp::SaveChanges(void)" (?SaveChanges@EBLProp@@UAE_NXZ)
C:\Builds\OCPN\ocpn_draw_pi\build\Release\ocpn_draw_pi.dll : fatal error LNK1120: 1 unresolved externals


C:\Builds\OCPN\ocpn_draw_pi\src\EBLProp.cpp(73): warning C4067: unexpected tokens following preprocessor directive - expected a newline
C:\Builds\OCPN\ocpn_draw_pi\src\EBLProp.cpp(120): warning C4067: unexpected tokens following preprocessor directive - expected a newline
C:\Builds\OCPN\ocpn_draw_pi\src\ODPropertiesDialogImpl.cpp(164): warning C4067: unexpected tokens following preprocessor directive - expected a newline
C:\Builds\OCPN\ocpn_draw_pi\src\ODPointPropertiesImpl.cpp(82): warning C4067: unexpected tokens following preprocessor directive - expected a newline

Håkan

[jongough]

Rick,
Patch 657 should fix the issue with width and style on the EBL properties panel.

Jon

Originally Posted by rgleason

....

I tried the new EBL feature again, while running TDan' python VDRplayer and the Hakefjord file from Hakan. It works! The only trouble I had was changing the port and starboard angles, colors and pixel weights because the menu seems to be affected by the data coming from the player. There is a frequent blink in the menu when data is received or written, which makes it difficult to select from the dropdown for the number of pixels for example. You must complete an action before the next blink, or you loose your place. This makes it difficult to set parameters. Can it be fixed?

......

[jongough]

Hi,
If you want to try patch 657 under windows you will find an install file here:
https://www.dropbox.com/s/i0sr3vf238...win32.exe?dl=0

Regards
Jon

[Hakan]

Jon
657 builds fine and fixed the EBL creation issue.
Thanks/ Håkan

[Hakan]

@Translators
Crowdin (ocpn_draw_pi.pot) is now updated. A couple of new strings are added.

Jon, my head may be week but how should I understand the "-P/-S" for the EBL angle?
"EBL Angle (-P/+S)"

Håkan

[NEVERMIND]

Originally Posted by Hakan

@Translators
Crowdin (ocpn_draw_pi.pot) is now updated. A couple of new strings are added.

Jon, my head may be week but how should I understand the "-P/-S" for the EBL angle?
"EBL Angle (-P/+S)"

Håkan

Like this view1:
it is the angle between the north

like this view 2:
it is the angle between the boat

Jean Paul

[Hakan]

Paul
Thanks, I understand that the EBL angle is the angle from north but what are the letters "-P/-S" abbreviations of?
Håkan

[NEVERMIND]

I think it was Startboard (triboard) and Port (babord)

Jean Paul

[Hakan]

Jean Paul
Of course!!! My head was week then.
Thanks/ Håkan

[jongough]

Håkan,
I am not sure I have the words/abbreviations correct yet. But the EBL angle is really meant to be used when the line rotates with the boat, so it gives the angle between COG/HDT and the EBL. You can still use this field when the line does not rotate with the boat, and it is used in the same way, but if the boat COG/HDT changes then this field will also change. This field was/is a 'work in progress' as I try to get EBL's to work correctly when the boat rotates.

If you find the wording confusing, can you suggest something else. I used -P/+S to help myself understand, but I did realise it 'may' be an issue for others. If you are using linux you can only enter '-180' <-> '180' in this field as there is a check on that. Unfortunately, in windows you are not limited to this, so you can put in -360 and get a line straight in front of you, or 540 and get one straight behind you. It does work, but it can be confusing.

Jon

[CarCode]

Originally Posted by jongough

Gerhard,
I must admit the plugin has been going through quite a lot of changes as I fix it up based on user feedback. I am hoping that the rate of change will now slow down as I think many of the bugs have now gone. There may be minor changes going in as users find issues, but could you try the latest, 655, patch and see if there are any glaring issues? I know we found some with internationalisation and windows, so I would be very interested if there are issues with the Mac.

Thanks
Jon

Jon,
could you please tell me which compiler you are using?
I have had a look at the latest code you provided obviously build 657.
It includes strange things like this:

#ifdef WIN32
     some code
#else WIN32
     some code
#endif WIN32

That makes no sense. Which compiler allows that? If you want a reminder you must comment out the second and third "WIN32" like this:

#ifdef WIN32
     some code
#else // WIN32
     some code
#endif // WIN32

This is only a simple example but I found several other problems in your code. I strongly suggest you should use a smarter compiler which alerts you of such things.

After all I got compiled and run your version on Mac OS X but there are still about 37 issues to fix. When it works a little bit smoother I'll upload the code to my github. However I don't use cmake nor gcc and I compile my plugins not as standalone to avoid double code.

Gerhard

[jongough]

Gerhard,
I use GCC and MS VS 2013, I do get warning messages, but I have been living with them, I have now removed the text that causes the issues on #else and #endif.

The only double code is maintained in the 'ocpnsrc' directory and I am trying to reduce the need for that by creating my on versions. The 'ocpninclude' directory is needed to provide the header files, but many of these are needed because OCPN header files include others. I would like to remove these, but I cannot without making OD susceptible to changes in OCPN.

Windows is far stricter and more difficult to make work than linux. It even has its own 'special' way of doing things in wxWidgets, hence the issues with internationalisation.

If you need to know what files are copied from OCPN look in the file named 'copy-ocpn-files' in the root directory of OD. I use this to copy all the files I need from OCPN when it changes and I need the changes to make OD work, i.e when the PlugIn API changes.

I have tried building a Mac OSX virtual machine and did have one working, but it was an old version, 10.4 I think. But without Mac hardware it is rather difficult as you need 'hacked' versions of the kernel and it never seems to work quite right.

If you find issues with the build or the run time let me know and I will try to update the code for you.

Patch 658 removes the extra text on the #else and #endif statements.

Jon

[Hakan]

Originally Posted by jongough

Håkan,
I am not sure I have the words/abbreviations correct yet.............

Got that, thanks

If you find the wording confusing, can you suggest something else. I used -P/+S to help myself understand, but I did realise it 'may' be an issue for others. If you are using linux you can only enter '-180' <-> '180' in this field as there is a check on that. Unfortunately, in windows you are not limited to this, so you can put in -360 and get a line straight in front of you, or 540 and get one straight behind you. It does work, but it can be confusing.

No, it's OK for me. I've translated P/S to the Swedish abbreviations for Port/Starboard. I was just "slow headed" (English??)
Navigation issues can be confusing so a sophisticated plugin like this can of course be demanding. We've to learn haven't we?

Thanks/ Håkan