arkasha wrote:wow.
that's a seriously weird one.
can you post the output of the whole process onto this channel (you can select/copy/paste from the digle "console" screen)?
I guess the reason that i'm confused is that there's no point at which we rely on the system to supply us with '.' vs. ',' in the software; everything's explicit. i wonder if delphi's float-parsing code automatically picks up your regional settings? do your filename periods get substituted to commas when you localize?
thanks for using our software, and for presenting me with an interesting challenge.
-a
No, filename periods dont get substituted in the operating system, it is still still in the format "foo.bar".
With the setting in the International and Language control panel set to Danish, DiGLE's console info is as follows :
- Code: Select all
DiGLE
Version 0.1.0 (Beta 1)
found maps:
===========
Amager-DK (Amager.mappack)
<choose mappack> (empty.mappack)
København-DK (KBH.mappack)
Washtenaw County, MI (TGR26161.mappack)
commencing login query...
Authentication Succeeded for Dutch
proceeding...
making request for:
Lat: 12.49182
Lat: 12.66013
Lon: 55.79055
Lon: 55.62475
...
retrieving data...
saving...
uncompressing gzip...
parsing received data in C:\Documents and Settings\Stumbler User\Skrivebord\JiGLE-0.7.1\data\København-DK.WiGLE...
received 0 stations.
With the international and language setting set to English (USA) or set to Danish with and adjusted so decimal period and number group character is equivalent to the US format, DiGLE's output is as follows :
- Code: Select all
DiGLE
Version 0.1.0 (Beta 1)
found maps:
===========
Amager-DK (Amager.mappack)
<choose mappack> (empty.mappack)
København-DK (KBH.mappack)
Washtenaw County, MI (TGR26161.mappack)
commencing login query...
Authentication Succeeded for Dutch
proceeding...
making request for:
Lat: 12.49182
Lat: 12.66013
Lon: 55.79055
Lon: 55.62475
...
retrieving data...
saving...
uncompressing gzip...
parsing received data in C:\Documents and Settings\Stumbler User\Skrivebord\JiGLE-0.7.1\data\København-DK.WiGLE...
received 2942 stations.
Looking at the unpacked .gz file (the .WiGLE file), in both cases show the data is present and has been downloaded, so it's not a problem in the backend on the server. It's definitely the client.
Of the top of my head I would guess WiGLE uses the system setting for the decimal point, and therefore doesn't recognise the Lat/Lon data in the .WiGLE file as valid because it uses a period as the decimal point.
When you parse the .WiGLE file, do you read the lat/lon data up to the period for the degrees, and after the period for the decimal part of the Lat/lon, or do you read the whole field in as a char, and then use Delphi functions to convert to a float in one go ? Might be there the culprit lays if the second option is the one you use..
.ns1 files loaded in DiGLE with Danish number format loads, the console says it found the correct number of stations, but the map window stalls with a blank screen, and when the map window is maximised, a warning dialogue box with the message " Floating Point division by Zero" and an OK button appears.
With English (USA) or decimal and numbergroups character substituted, it works perfectly.
The only WiScan file I can test with, are WiScan exported files from NS.
When set to standard Danish numbers format, DiGLE exhibits the same behaviour: Can't find any stations in the file.
When set to English (USA) or adapted the Danish numbers format, it works without a hitch.
WiScan+ files I haven't been able to test, but my guess is that the behaviour would be the same.
If you want, I can test with JiGLE as well.. Just say the word.
Just my 0.02€'s worth....
Dutch.