On 5 August 2014 16:55, Dirk Hohndel <[email protected]> wrote: > On Tue, Aug 05, 2014 at 12:18:20PM +0300, Lubomir I. Ivanov wrote: >> On 5 August 2014 09:09, Dirk Hohndel <[email protected]> wrote: >> > >> > We know that the 32bit/Qt4 Windows installer has printing issues - so >> > that's not the main goal of testing :-) >> > >> >> actually it should all work the same way as the Qt5 build, except the >> table print is in raster. >> >> re: tmpfile() >> i remember Miika wrote the initial prepare_dives_for_divelogs() >> variant for the GTK version, but it used tmpnam() if i recall >> correctly. then i changed it to use tmpfile()...something in these >> lines. >> >> TBH, i didn't notice that the file goes in C:\ on Win7, simply because >> i use an administrator/root account. >> testing on WinXP SP2, it goes in .\ which is no better. > > I simply ripped all this out and reimplemented it to go to > C:\Users\<yourname>\AppData\Local\Temp or something. > > But of course now that I say this I don't know if I would have needed to > sing some magic incantations and burn the excrements of some MSFT > employees in order for this to work with non-ASCII (or non-Latin, or > non-something) characters in the localized path name components... > > Could you take a look at commit 3fd8e50044c7 ? >
yes, i saw it. in general, subsurface_fopen() should be used in case the temp path has special chars. on Win32. (patch attached) lubomir --
0001-Web-use-subsurface_fopen-for-non-ASCII-paths-on-Win3.patch
Description: Binary data
_______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
