WeatherFax ...

[HUR450502]

Hi Rick,

sorry, but just saw your inquiry:

You simply go to the Windows Control Panel.

There you select "Regional Settings & Language"

On this menu you select "Additional Settings"

And then under the menu option for numbers you set the decimal point and the "thousands comma" - you see on the picture the changes I made, where you read "Dezimaltrennzeichen" (Decimal point I guess in English) there was a comma, which I changed to a decimal point and under "Symbol fur Zifferngruppierung" the "Thousands comma" ther was a point previously. ..... This was it .... ok???
Control Panel.JPG Views: 136 Size: 302.9 KB ID: 93295" style="margin: 2px" />

Best regards,

Uwe

[rgleason]

Thanks Uwe.
How the devil does Opencpn have control over Windows System Settings like that?

1. Is there some way that Opencpn could check those Windows settings and give the user a warning to change?
2. We certainly should have a note in the Windows instructions.

[CarCode]

Originally Posted by rgleason

Thanks Uwe.
How the devil does Opencpn have control over Windows System Settings like that?

1. Is there some way that Opencpn could check those Windows settings and give the user a warning to change?
2. We certainly should have a note in the Windows instructions.

This is normally done by the wxWidgets locale in the source code but weatherfax has a bug here.
Gerhard

[HUR450502]

Hi Rick,

I do not believe, that OpenCPN has control over these settings, but it is controlled by them... I am not a windows expert, but there should be a possibility to check these settings and then act accordingly (this is at least the reason for these regional settings), however, if you use internally another numbering system, then this will not work.

An example is Excel, it works perfectly with any input e.g. you take a file from the US with decimal point, if you use a "German" Excel, it just changes them to commas and calculates correctly. However, if you export this spreadsheet to e.g. a textfile, then this textfile contains the decimal commas..... If you want to change this, then you need to change these regional settings and you then get decimal points again.

The point is, I do not know how the calculations are done in the calibration mechanism - for some reason the commas are just ignored. You can easily check this (now I know), if you would change your regional settings to German (decimal comma and thousands seperator points. When you then want to calibrate a fax, you will see at the bottom of the calibration screen under Size "1,00" and W/H "1,00" while the "True width Ratio" (still greyed) shows "1.00"

So, obviously the mechanism in the calibration does not realize this different type of input or mixes them. However, the calibration calculation is done correctly.... So, very confusing, I think, Sean needs to have a look into this, I am convinced, that this can be handled internally without the need to involve the user.

But speaking about this - there may be other points in OpenCPN, where miscalculations happen due to these regional seetings, which just haven't been detected.... So, I think a thorough evaluation is necesary here, otherwise it also wouldn't make sense to offer a language option during install and just force everybody to use the English version and numbering settings..... OK???

So, in short:

1. We need to evaluate, if there is a method to detect the regional setting and based on this ensure that calculations are done correctly, using regional numbering schemes.
2. We too would need to evaluate - if point 1. leads to the ensurance, that this is possible - if there are other areas in OpenCPN who too are vulnerable to regional settings and if they too have this error..

Possibly quite some task.... Maybe Marius has any ideas?? As said before, I am no expert in this and would have to "learn" how this is / could be done.... Sorry .....

Best regards,

Uwe

[rgleason]

Gerhard,

This is normally done by the wxWidgets locale in the source code but weatherfax has a bug here.

Can you explain further? Should weatherfax really be checking the delimiters in Windows settings? How would you suggest fixing this?

[HUR450502]

Hi Rick,

don't know, if this helps, but I meantime too believe there is an error in the weatherfax plugin (I was thinking maybe windows itself, but I believe I am wrong there).

Following situation:

1. I changed the regional settings back to "German", decimal comma, etc.
2. I calibrated the .TIFF image and saw at the bottom (Coordinates mapping correction) under Size and W/H "1,00" instead of "1.00"
3. Close OpenCPN (this is important to store the .ini, etc. files, and then re-open OpenCPN - then -
4. I went to weatherfax "Retrieve" => "Internet" => "Passage Weather" => "Mediterranean" => "Retrieve Selected (COAMPS 000)" and got an error "Resulting image has negative dimensions, aborting"
5. Clicked on O.K. and the plugin went to the "calibration" menu displaying the image and - that is the interesting point - at the bottom (Coordinates mapping correction) Size displays now "1.00" and W/H displays as well "1.00" - so no decimal comma but a decimal point.....
6. NOW I imported the track, and it shows up smoothly as it should be......
7. Closed OpenCPN and re-opened, and it opened exactly at the right location, etc. however, when you wanted to retrieve another internet fax, you end up again at the "negative dimensions" error message. But you do not have any distorted tracks.
8. Now again calibrated the fax image and it showed up correctly, track not distorted.
9. Closed OpenCPN and re-opened. OpenCPN showed Overzoom somwhere in the middle of North America, when zooming out the track was distorted.....

So, long story, I think Gerhard is right, somewhere in the calibration area when calibrating images from files there must be a problem, as calibration from internet input (after having done points 1 - 3) seems to work correctly and does not have any influence on the tracks etc. ....

Is it Sean's plugin?? I believe, he needs to have a look into this.... OK?? The xxWidgets, etc. seem to work correctly.....

Best regards, Uwe

[CarCode]

Originally Posted by rgleason

Gerhard,

Can you explain further? Should weatherfax really be checking the delimiters in Windows settings? How would you suggest fixing this?

Open the file "chart1.cpp" in an editor and search for a string called "locale".
You will see then.
Gerhard

[rgleason]

chart1.cpp (In Opencpn src folder)

bool g_bPreserveScaleOnX;

about *g_pAboutDlg;

wxPlatformInfo *g_pPlatform;
wxLocale *plocale_def_lang; <-----LINE 583
wxString g_locale;
bool g_b_assume_azerty;

Gerhard, that is helpful. Is there a way to determine how
wxLocale
is used? In opencpn? In Weatherfax?
Is this an Opencpn thing or a Weatherfax problem?

wxLocale also occurs in:

options.cpp

extern wxLocale *plocale_def_lang; <----LINE 189
extern OCPN_Sound g_anchorwatch_sound;
extern bool g_bMagneticAPB;

pluginmanager.cpp

extern wxAuiManager *g_pauimgr;
extern wxLocale *plocale_def_lang; <---LINE 72
extern ChartDB *ChartData;

Search for wxLocale in the weatherfax src folder finds nothing.

[CarCode]

wxLocale is a wxWidgets feature while setlocale() is an OS specific function.
To know more about this please read the docs.
Gerhard

[mrm]

Originally Posted by rgleason

Thanks Uwe.
How the devil does Opencpn have control over Windows System Settings like that?

1. Is there some way that Opencpn could check those Windows settings and give the user a warning to change?
2. We certainly should have a note in the Windows instructions.

It is rather a matter of consistently choosing a locale across an application and its modules and sticking with the choice. Let me provide an example in C:

#include <locale.h>
#include <stdio.h>

int main()
{
  double number = 1234567.89 ;

  setlocale(LC_NUMERIC, "en_US.utf8");
  printf("In en_US locale the number is formatted as: %'.3f\n", number);

  setlocale(LC_NUMERIC, "de_DE.utf8");
  printf("In de_DE locale the number is formatted as: %'.3f\n", number);

  setlocale(LC_NUMERIC, "pl_PL.utf8");
  printf("In pl_PL locale the number is formatted as: %'.3f\n", number);

  setlocale(LC_NUMERIC, "POSIX");
  printf("In POSIX locale the number is formatted as: %'.3f\n", number);

  setlocale(LC_NUMERIC, "C");
  printf("In C locale the number is formatted as: %'.3f\n", number);

  return 0;
}

When compiled and run, the following output is expected:

In en_US locale the number is formatted as: 1,234,567.890
In de_DE locale the number is formatted as: 1.234.567,890
In pl_PL locale the number is formatted as: 1234567,890
In POSIX locale the number is formatted as: 1234567.890
In C locale the number is formatted as: 1234567.890

A note to the users is not necessary, because users are not expected to modify data in configuration files directly, although some users may think otherwise because files are in human readable format

[rgleason]

Thanks, I found locale.h referred to in Opencpn/src in three files, but not weatherfax.
cpl_config.h
cpl_port.h
cpl_conv.h

It is rather a matter of consistently choosing a locale across an application and its modules and sticking with the choice. Let me provide an example in C:

So in wonder where weatherfax is inconsistent, it just accepts Opencpn setting I believe.

[mrm]

Originally Posted by rgleason

Thanks, I found locale.h referred to in Opencpn/src in three files, but not weatherfax.
cpl_config.h
cpl_port.h
cpl_conv.h

So in wonder where weatherfax is inconsistent, it just accepts Opencpn setting I believe.

If you read my statement as a suggestion that weatherfax is inconsistent it was not my intention at all and I apologise for maybe poor wording on my part. It was intended as a more generic advice to any readers who might want to write some code.

Marius

[HUR450502]

Originally Posted by mrm

A note to the users is not necessary, because users are not expected to modify data in configuration files directly, although some users may think otherwise because files are in human readable format

I fully agree Marius, this should be the correct appproach. Mid ocean you wouldn't want to modify system parameters, which you would not fully understand...... And we don't want to be the excuse for some kind of "VESTAS" disaster, no??

So, now we simply need to find out, where either this setting is missing or - by any means - has been reset and - then - correct this.

Honestly - I would have lost interest for long already, if this plugin wouldn't have been so excellently done as it is. An excellent user interface, excellent standard resources, etc. Just great. Now there is one little problem and I am convinced, that that can be solved. Sorry, that I cannot be of more help, as most of this is a bit "after my time", however, I trust, that we get this fixed and, as mentioned earlier, Marius, you are directing into the right direction...

Best regards to all and thanks,

Uwe

[rgleason]

Thanks Uwe,

I am not able to fix this. Your description helps to explain the problem:
http://www.cruisersforum.com/forums/...ml#post1696818

So, now we simply need to find out, where either this setting is missing or - by any means - has been reset and - then - correct this.

Hopefully Sean will be able to fix it. I have not heard from him for awhile, and there was a typhoon in the Philippines. I hope he is ok.

[HUR450502]

Yes Rick,

knowing that the "Alexandra" is in the Phillippines, I thought about that. They say "Hagupit" wasn't as desastrous as "Hayan", however, strong enough to kill people and destroy ships and buildings, etc.

For sure Sean will have other things to do right now. Let's hope he and his boat survived unharmed. Would be great to get some feedback how things are.

Sean, all the best,

and best regards to Rick et al. ,

Uwe