| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2020.1 | TLSETUP didn't expect the CFC DLLs to be moved. | XANADU::cascobay.zko.dec.com::TAMARA::STJEAN | Bob St.Jean | Thu Mar 06 1997 11:56 | 32 |
| Brian,
The CFC, XTI and the other TL DLLs that are normally installed in
the \Windows and \Windows\System directories should work if they
are moved to a network TL directory. You would have to make sure
that network directory is on the path, which it probably already
is. The references to the DDLs in Office.ini would have to be
changed.
Other apps might be installing or expecting the TL DLLs to be
in the system directory. Even TL ECO installs. So you would have
to make sure there aren't duplicates.
Your problem is that the File Cabinet definition code in TLSETUP
is only expecting the CFC DLLs to be in the \Windows\System
directory. I just checked the code to verify this. It's not
smart enough to figure out that the CFC files are not there and
might be in the TL directory.
For now, I think the user would have to manually edit Office.ini
to fixup the DLL= path value for any new file cabient or any file
cabinet whose type was changed.
This part of TL wasn't designed to expect that the DLLs might be
moved. I don't know if there are other parts of TL that would
have the same problem. Enter a PTR and perhaps someone will look
at it.
Bob
|
| 2020.2 | What about DLL search path ? | BACHUS::COLLART | Li p'ti fouineu - Dtn 856-8796 | Wed Mar 12 1997 11:22 | 28 |
| >
>Other apps might be installing or expecting the TL DLLs to be
>in the system directory. Even TL ECO installs. So you would have
>to make sure there aren't duplicates.
>
>Your problem is that the File Cabinet definition code in TLSETUP
>is only expecting the CFC DLLs to be in the \Windows\System
>directory. I just checked the code to verify this. It's not
>smart enough to figure out that the CFC files are not there and
>might be in the TL directory.
>
Hello Bob,
I thought a DLL was always called by Windows that will search in well
defined locations (current directory, Windows directory, Windows\system
directory and the DOS path).
Isn't it the case for TLSETUP ? Customer is using Windows 3.1 .
Thanks for light
Eric Collart
MCS Brussels
|
| 2020.3 | | XANADU::cascobay.zko.dec.com::TAMARA::STJEAN | Bob St.Jean | Wed Mar 12 1997 12:43 | 19 |
| Eric,
The problem is that TLSETUP creates a "DLL=<path><CFCSPI.DLL>" for
each file cabinet resource section it creates/modifies in Office.ini.
It expects that the CFC SPI DLLs are always in the Windows System
directory, so for <path> it simply puts the path to that directory.
CFC.DLL then loads the DLL based on this fullpath.
One might argue that CFC.DLL should have alternate means to
locate it's SPI DLLs should the initial load fail.
PTR this if you want it changed someday. An IPMT isn't really
appropriate, since this is working as designed. Unless it's a
suggestion IPMT.
Bob
|
| 2020.4 | Thanks for clarification | BACHUS::COLLART | Li p'ti fouineu - Dtn 856-8796 | Thu Mar 13 1997 02:29 | 30 |
|
Hello Bob,
>
>The problem is that TLSETUP creates a "DLL=<path><CFCSPI.DLL>" for
>each file cabinet resource section it creates/modifies in Office.ini.
>It expects that the CFC SPI DLLs are always in the Windows System
>directory, so for <path> it simply puts the path to that directory.
>CFC.DLL then loads the DLL based on this fullpath.
>
Ok, now problem fully understood...thanks for clarification.
>
>PTR this if you want it changed someday. An IPMT isn't really
>appropriate, since this is working as designed. Unless it's a
>suggestion IPMT.
>
OK, we'll do a PTR and report this to customer....
Thanks for support
Eric Collart
MCS Brussels
|