On Thursday 11 September 2014 07:14:54 Emmanuel Thomas-Maurin wrote:
> I've had a similar problem previously, with non-ascii (for instance
> cyrillic) user names in app data dir on windows. The trick was to use
> 'wide char' win32 API functions which all return UTF-16 encoded
> strings, then convert to UTF-8 (with g_utf16_to_utf8()).
>
Thanks. This looks like a useful avenue to try out.
The wide char win32 is completely alien to me. Do you have some pointers to get
me started ?
Especially some example code would help me a lot.
I'm running into the bad filename conversion in two ways:
1. Users can specify an override directory via the GNC_DOTGNUCASH_DIR
environment variable.
I'm currently reading this via g_getenv, but it returns the wrong result.
2. In the absence of the environment variable, the default path is being
created starting from
the value of g_get_home_dir. This as well returns the wrong result.
Geert
> On 09/11/2014 03:25 AM, Fernando Rodriguez wrote:
> > On Wednesday 10 September 2014 5:07:03 PM Fernando Rodriguez wrote:
> >> On Wednesday 10 September 2014 7:37:28 PM Geert Janssens wrote:
> >>> Hi,
> >>>
> >>> I'm stuck on the following issue. Program is GnuCash on Windows.
> >>>
> >>> Consider the following code snippet:
> >>>
> >>> struct stat statbuf;
> >>> gchar* dirname = g_strdup(g_getenv("GNC_DOTGNUCASH_DIR");
> >>> gint rc = g_stat (dirname, &statbuf);
> >>>
> >>> switch (errno)
> >>> {
> >>>
> >>> case ENOENT:
> >>> // Directory doesn't exist
> >>> // Here is code to create it which I cut for brevity
> >>> break;
> >>>
> >>> case EACCES:
> >>> // Directory can't be accessed
> >>> exit(1);
> >>>
> >>> case ENOTDIR:
> >>> // Not a directory
> >>> exit(1);
> >>>
> >>> default:
> >>> // Unknown error
> >>> exit(1);
> >>>
> >>> }
> >>>
> >>> // Continue code with valid, existing directory
> >>> ...
> >>>
> >>> So this snippet reads the value of environment variable
> >>> GNC_DOTGNUCASH_DIR and tests whether this is a valid directory.
> >>>
> >>> This works fine when GNC_DOTGNUCASH_DIR uses a limited character
> >>> set like ascii. For example when set to "c:\gcdev\geert" this
> >>> works well and the code continues.
> >>>
> >>> However if set to for example:
> >>> c:\gcdev\Łukasz
> >>> Things go wrong (note the unusual Ł).
> >>>
> >>> In this case the code branches into case ENOENT and creates a
> >>> directory named c:\gcdev\Lukasz (note the plain L now)
> >>> Before it continues.
> >>>
> >>> Setting a breakpoint at rc=g_stat... and examining the value of
> >>> dirname at that point also shows it to have a value of
> >>> c:\gcdev\Lukasz (with plain L).
> >>>
> >>> So it seems I'm losing diacritical information here and I can't
> >>> pass the right directory to my code to use.
> >>>
> >>> What should I do to get the real value from the environment to be
> >>> able to access the true directory ?
> >>>
> >>> Thanks,
> >>>
> >>> Geert
> >>>
> >>> P.S. my locale settings are all "Dutch_Belgium.1252" except for
> >>> LC_ALL which is empty.
> >>> _______________________________________________
> >>> gtk-app-devel-list mailing list
> >>> gtk-app-devel-list@gnome.org
> >>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >>
> >> Well gchar is a typedef for char so it only supports ascii. I think
> >> you'll probably have to use Win32 API calls on Windows to access
> >> multibyte file names.
> >>
> >> Also according to the documentation you should use GStatBuf instead
> >> of struct stat on Windows to get consistent behaviour on different
> >> compilers.
> >>
> >>
> >>
> >> _______________________________________________
> >> gtk-app-devel-list mailing list
> >> gtk-app-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
> > Actually try using g_utf8_strncpy() instead of g_strdup(). I'm not
> > sure if that'll get you all the way as the docs say g_stat calls
> > the standard library functions and AFAIK those dont support
> > unicode/multibyte filenames.
> >
> >
> >
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
