%_sb_errorcode% = -1

[NewsArchive]

What does that mean (%_SB_ERRORCODE% = -1) when attempting to call a
function in a support dll.

Bad Jeff was calling a dll, but not checking %_SB_ERRORCODE%
afterwards.

I just assumed that someone would yell at me if there was a problem,
but it was a silent sort of yell. Funny how theories are defeated when
you read the documentation.

This is a fairly consistant problem, but only on certain machines, but
I don't know the common obstacle yet.

The support file does get extracted, and it definitely resides inside
%TMPDIR%.


Jeff Slarve

[NewsArchive]

Okay, I suspect new dependencies in the support dll. Will report back,
if that's not it. But I'm guessing it is.

Jeff Slarve

[NewsArchive]

Hi Jeff,

> Okay, I suspect new dependencies in the support dll. Will report back,
> if that's not it. But I'm guessing it is.

Yes, I think it's a missing dependency. It's also possible that 1.) it's
caused by "DLL file not found" or 2.) "DLL function not found". Error -1 is
returned if the LoadLibrary API failed.

Friedrich

[NewsArchive]

Thanks Friedrich -

What would you suggest that I do in this case:

1. I have a support dll that has (linked in, not dynamic) dependencies
on LSPUZIP.DLL and LSPZIP.DLL
2. In my "support files" section on my SB7 project, I have my dll and
the 2 LSZip files.
3. On a "virgin" machine, when I run my setup, I can see via procmon
that it's looking for these LSZip files on various points of my system
path, but not in the %TMPDIR% folder where the support DLL was loaded
from (and the files exist).

How do I force my DLL to find it's dependencies in its own folder?

Thank you.

Jeff Slarve

[NewsArchive]

Hi Jeff,

I have to check this and will get back to you.

Friedrich

[NewsArchive]

Hi Jeff,

>
> How do I force my DLL to find it's dependencies in its own folder?
>

See my reply in the "SetPath" thread and the following demo source codes:

http://www.lindersoft.com/projects/d...pendencies.zip

The above SetupBuilder .exe will call into sbdll.dll which is statically
linked to the lspuzipx.dll. The current directory is set and reset.

Does this help?

Friedrich

[NewsArchive]

BTW, the call to the GetCurrentDirectory Windows API is not really required
here because we have a built-in "Get System Info (Current Folder)"
available. But in this example, I demonstrate how to use "Call DLL".

I think I'll add a new built-in "Set Current Folder" script function to
streamline the process.

Friedrich

[NewsArchive]

Thanks for all of your help.

If you want to REALLY streamline the process, how about a checkbox on
the "Call DLL" function to include the dll's folder on the path, but
check with Jane first<g>

Jeff Slarve

[NewsArchive]

(e.g. push/pop the path to/from the folder where the dlls reside
before/after calling)

>dll's folder on the path,

Jeff Slarve

[NewsArchive]

> (e.g. push/pop the path to/from the folder where the dlls reside
> before/after calling)

To be honest, I don't know if such an automated "change current folder
mechanism" would cause negative side effects. I have to investigate it.

Friedrich