Problem running IRender after loading Twilight.

[Al Hart]

@chris_at_twilight said:

Certainly Twilight is not actively impacting it.

With Twilight not loaded, it looks for arobjects.dll in:

c:\Program Files\Google\SketchUp 7, --- then in
c:\Windows\system32
c:\Windows\system
c:\Windows, --- and then in the current folder,
c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt
(where it finds it)

With Twilight loaded, it looks in

c:\Program Files\Google\SketchUp 7, --- then in
c:\Program Files\Google\SketchUp 7\Twilight, --- then
c:\Windows\system32
c:\Windows\system
c:\Windows,

but never in c:\Program Files\Render Plus System

Does Twilight make a ruby call, or a Windows call, to change the DLL search path?
(I am wondering because it looks in the twilight folder before the windows folder)

If so, then we could make a similar call to add "c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt" to the DLL search path.

Thanks,

[Chris_at_Twilight]

@al hart said:

@chris_at_twilight said:

Certainly Twilight is not actively impacting it.

Does Twilight make a ruby call, or a Windows call, to change the DLL search path?
(I am wondering because it looks in the twilight folder before the windows folder)

If so, then we could make a similar call to add "c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt" to the DLL search path.
Thanks,

Yes, exactly. If you set your search path immediately before loading the dll, that should resolve the problem. This is probably a good idea no matter what because, according to Microsoft, the DLL search that is finding the arobjects.dll is looking in the "current path". Since many things can influence the current path, it's probably not safe to rely too much on it.

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

[Al Hart]

@chris_at_twilight said:

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

I presume you are doing this in Ruby.

I suspect you are not restoring the search path, because Twilight still seems to be in it when IRender nXt is trying to load its DLL.

Can you send the two lines of Ruby code? (set path and restore path).
I want to see why the restore path is (apparently) not working.

[Al Hart]

@chris_at_twilight said:

If you set your search path immediately before loading the dll, that should resolve the problem.

Thanks for your help on this, we are setting ENV["PATH"] before loading the DLL and it seems to work better now.

[Chris_at_Twilight]

Sorry for the confusion. I meant, with the next release, this will be added. The current publicly available release does not 'reset' the dll search path.

The code I'm using is Windows API. SetDllDirectory (more on it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx )

[Al Hart]

@chris_at_twilight said:

Sorry for the confusion. I meant, with the next release, this will be added. The current publicly available release does not 'reset' the dll search path.

The code I'm using is Windows API. SetDllDirectory (more on it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx )

AHA.

I turns out that we were using SetCurrentDirectory() to define the DLL path, and depending on the LoadLibrary defaults which include the current directory.

When you call SetDllDirectory(), with a path name, the current directory is no longer used, so our logic no longer worked.

If you had called SetDllDirectory() again with a blank name to reset it, then the current directory logic is restored. So that is what was causing the original problem.

We are going to switch to using SetDllDirectory() ourselves, which will eliminate this problem, but we both need to be carefull to reset it so we don't mess up anyone else who is depending on the current directory method of loading DLLs

[Chris_at_Twilight]

@al hart said:

We are going to switch to using SetDllDirectory() ourselves, which will eliminate this problem, but we both need to be carefull to reset it so we don't mess up anyone else who is depending on the current directory method of loading DLLs

@chris_at_twilight said:

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

My suggestion exactly. It's already been implemented in Twilight and will be in place in the next release.

[Al Hart]

We have released new versions of IRender nXt which fix this problem.

Thanks for your help Chris.