SetPath

[NewsArchive]

Is there a SetupBuilder way to SetPath(), or do I need to call a DLL
for that?

And if I do that, will it cause any problems with a setup?

Jeff Slarve

[NewsArchive]

To cover my having no clue, Jeff, might I ask what you're trying to
accomplish by changing the path?

Could you maybe accomplish it with the Run Command Line item?

Jane

[NewsArchive]

This has to do with my calling of a DLL as a support file, but it has
some dependencies that it can't find on loading.

It was my hope that temporarily setting the search path to my %TMPDIR%
before loading the dll would solve that problem.

Jeff Slarve

[NewsArchive]

Well, them a command line thing wouldn't help as that would only set the
path for that session.

Are the dependencies also located in the %TMPDIR% folder?

I had a similar issue with installing dongle drivers. The manufacturer
provides an executable installation program, but I wanted to wrap it in
something more user-friendly and branded to me rather than to them.

I ran it manually on my machine, and was able to extract its components
(DPInst64.exe, xml files, sys files, etc.) and include those components as
support files in my SB project.

But it stopped working when Friedrich changed the behavior of %TMPDIR% so
that it was no longer the "real" user's temp folder but rather a GUID-named
sub folder of it.

What I wound up doing was having my script copy the files out of %TMPDIR%
and into the "real" temp folder. I used the "split source string at last
occurrence of search string" function to get the "real" folder name (pic).
I delete the files when I'm through.

There is a script item to "Set Temporary File Folder", but I've never played
with it.

Jane Fleming

[NewsArchive]

Hi Jane -

I must be tired. I'm not seeing how copying the files to the actual
temp folder would assist with this, unless perhaps the temp folder is
in the user's path. Or was that part just anecdotal to my need to muck
around with stuff and might need to roll up my sleeves a little? :)

But the answer is yes about the dependencies being in the same support
files, and indeed, are in the %TMPDIR% folder when the setup runs.

Using Procmon, I can see it attempting to find the lsp*.dlls in
various places, and failing. It preferred to look in my "documents"
folder to the one where the actual calling dll resided.<g>

But I guess it makes sense. It's looking for the path relative to the
..exe, I guess.

I just want to setpath() to my %TMPDIR% folder temporarily, and I
think it will be groovy.

Jeff Slarve

[NewsArchive]

Anecdotes? I'm full of anecdotes!

More grasping at straws. In that case, I think it was hard-coded to use the
user's temp folder.
But the point was that I copied the support files to where they would work
and then cleaned up afterwards.

Jane Fleming

[NewsArchive]

Jeff,

> Is there a SetupBuilder way to SetPath(), or do I need to call a DLL
> for that?
>
> And if I do that, will it cause any problems with a setup?

The DLL search order in Windows is as follows:

1. The directory from which the application loaded.

2. The system directory.

3. The 16-bit system directory (if available).

4. The Windows directory.

5. The current directory.

6. The directories that are listed in the PATH environment variable.

The temporary Windows folder is not in that search order. I checked it and
the following should work (I can upload my LSZip demo source code if you are
interested). See attached screenshot. Use the SetCurrentDirectory Windows
API to set the current folder to %TMPDIR% before you call the DLL and you
should be done.

BTW, the above works for SB5, SB6 and SB7.

Does this help?

Friedrich

[NewsArchive]

Brilliant!

Jane Fleming

[NewsArchive]

Ah. Okay, that makes sense. I saw my DOCUMENTS folder being searched
in procmon, but that was just a coincidince because my .exe was there.

>
>5. The current directory.

Jeff Slarve