[Shapelib] Re: shapelib improvements

Tom Kazimiers 2voodoo at gmx.de
Thu Dec 6 17:00:19 EST 2007


Mateusz Loskot schrieb:
> Tom Kazimiers wrote:
>   
>> Mateusz Loskot schrieb:
>>     
>>> Tom Kazimiers wrote:
>>>   
>>>       
>>>>> Bram de Greve wrote:
>>>>>       
>>>>>           
>>>>>> Mateusz Loskot wrote:
>>>>>>         
>>>>>>             
>>>>>>> Possible solution is to use Unicode-aware API availalbe on 
>>>>>>> Windows: _wfopen() (or CreateFile) Some time ago I ported
>>>>>>> Shapelib to use wide-character versions of I/O functions as I
>>>>>>> needed it on Windows CE (Unicode-only system).
>>>>>>>
>>>>>>> Unfortunately, I have lost these modifications but it isn't a
>>>>>>> big deal to do it.
>>>>>>>           
>>>>>>>               
>>>>>> I've done similar modification for pyshapelib (I choose _wfopen
>>>>>> because that's similar to what Python does), but as Frank is
>>>>>> going to implement CreateFile IO hooks anyway, I think we can
>>>>>> rely on that.  As long as he uses the Unicode versions of it,
>>>>>> that is =).
>>>>>>         
>>>>>>             
>>>>> Yes, I think so too.
>>>>>       
>>>>>           
>>>> I had this problem, too, as I needed to use this lib on win CE. And
>>>> ported shapelib to unicode. If you want, I can send the sources.
>>>>     
>>>>         
>>> Tom,
>>>
>>> Perhaps we could make a unicode branch of Shapelib.
>>> Frank's opinion is most important here, not mine
>>>   
>>>       
>> This would be a good thing!
>>
>>     
>>>>>> However, it still isn't without issues:
>>>>>>
>>>>>> The CreateFile IO hooks will still accept char* filenames, which
>>>>>> would be OK if we would treat it as UTF-8 and decode it with 
>>>>>> MultyByteToWideChar.  But that would cause an assymetry with the 
>>>>>> (default) tradition IO hooks that use fopen and still treats the
>>>>>> char* filenames as ANSI encoded (in whatever codepage is set by
>>>>>> the regionale).  If it looks like a duck ...
>>>>>>         
>>>>>>             
>>>>> Right, there is some inconsistency. However, I can't see any better
>>>>> option.
>>>>>       
>>>>>           
>>>> But if you use shapelib as a dll from another program, esp. a managed
>>>> code one (I use C#) - on windows CE you have the only option to call
>>>> with unicode parameters. This means you have to write wrappers which
>>>> to the transformation or one makes the dll unicode aware (this is
>>>> what I did). Are there any ways to get a managed to unmanaged call on
>>>> Win CE working with char?
>>>>     
>>>>         
>>> Doesn't marchaling to UnmanagedType.LPStr work?
>>> Also, CharSet attribute of DLLImport to control how encoding information
>>> is marshalled. CharSet.Ansi is default for C++, so Unicode->ANSI is
>>> translated automatically.
>>>
>>> Cheers
>>>   
>>>       
>> Sure it is on a "normal" desktop computer - but in Win CE environment
>> one can only choose CharSet.Unicode as the whole OS works only with unicode.
>> The UnmanagedType.LPStr I did not try out - I will test it. But since I
>> have read that Win CE can only handle unicode I doupt it  would work.
>>     
>
> Tom,
>
> What about declaring Shapelib wrapper function as taking byte[]
> Also, AFAIK it is also possible to use IntPtr for char* return type.
>
> Cheers
>   
Well this could work - but the result would also be a function that in
the end needs ASCII characters. I would like to see wide char functions
in C - as if you would want to open a asian shape file it would not work
with fopen, etc.
The other way arount could be better if we make everything wchar and
build char-wrapper funtions for compatibilty.

bye


More information about the Shapelib mailing list