Windows & importing dives

Lubomir I. Ivanov neolit123 at gmail.com
Tue Mar 5 10:39:24 PST 2013


On 5 March 2013 19:24, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> On 5 March 2013 18:46, Dirk Hohndel <dirk at hohndel.org> wrote:
>> Miika Turkia <miika.turkia at gmail.com> writes:
>>
>>> Seems that XSLT files are not found in Windows if subsurface is
>>> invoked by opening a data file (and selecting subsurface as a program
>>> to handle it). E.g. I use file exploder to double click on
>>> testdives.DLD and select subsurface to handle the DLD files.
>>
>> Interesting. Windows is such an odd OS in the way things are found - I
>> wonder what the CWD is when starting an app like this. And how it is
>> able to switch back to its own executable path - as that is how we
>> attempt to find the files.
>>
>> Lubomir, do you know more about this?
>>
>
> i think for that to work in a clean way, we need to obtain the process
> path (e.g. /proc/self/exe)
>
> char buf[MAX_PATH];
> GetModuleFileName(NULL, buf, MAX_PATH);
>
> the buffer includes the executable name e.g. "<c:\....>\myfile.exe" so
> it has to be stripped.
>
> the result then has to be put _in front_ at mark <P> using concat (of
> sorts), but obviously on runtime:
> static const char *xslt_path = <P> XSLT ":xslt:.";
>
> but also check if the XLST build for Windows accepts full paths with
> drive letters.
>

i've just realized that the localization is not working as well when
e.g. opening a .DLD file from the desktop, which means that the
process working directory has to be changed, otherwise the location of
all relative path assets is lost.
GetModuleFileName still has to be used, but then there is a method
called SetCurrentDirectory which will have to accept the stripped
path, unless there is a method that does both things at once.

lubomir
--


More information about the subsurface mailing list