(A)
Travis, I was able to solve the problem:
I had to copy LDView64.exe to LDView.exe.
Then the thumbnails reappeared magically. As the chain of invocation now here is
Explorer.exe (64bit) ------> LDViewThumbs64.dll ------> LDView.exe
, I therefore conclude that LDViewThumbs64.dll erroneously tries to access LDView.exe instead of LDView64.exe.
Do you agree?
(B)
Another problem: 32bit applications (for example, MLCad.exe) do _show_ the thumbnails now,
but they do not _generate_ them. As I have LDViewThumbs.dll sitting around
on my system, I had thought it would spawn LDView64.exe (on 64bit systems), and LDView.exe (on 32bit systems)
to generate them. However, it does not. I have 2 suspicions why it does not work:
- as we saw in (A), LDViewThumbs64.dll does not spawn LDView64.exe, but LDView.exe erroneously, thus, I suspect that LDViewThumbs.dll vice versa tries to spawn LDView64.exe and fails
- or, the problem could get caused by the TypeLib registry setting, which, even for 32bit processes, still points to the 64bit DLL (see above)
As a solution, I suggest that you use separate CLSID and TypeLib identifiers for 32bit and 64bit.
The current re-using of them adds much confusion. Tracing down errors would be much easier that way.
©
Travis, I also spotted a problem with the registry keys where you store the pathes for the additional files
(Dir001, Dir002, Dir003 and so on). Note that all instances of them (in the current configuration, in the
presets, and in the screensaver) are affected:
when you edit their list via the GUI, i.e., you add some and then you remove some,
in the registry relicts remain. For example, my editing in the GUI was to first setup 4 pathes,
then again delete some to just have one. What resulted in the registry was that settings
Dir001, Dir003, Dir004 (but no Dir002) were present.
I think that this can lead to the effect that when a user then again adds a second path via the GUI, this will create a Dir002,
and then after restarting LDView, suddenly 4 pathes will be present, because the gap is closed.
Could you check that code?
Travis, I was able to solve the problem:
I had to copy LDView64.exe to LDView.exe.
Then the thumbnails reappeared magically. As the chain of invocation now here is
Explorer.exe (64bit) ------> LDViewThumbs64.dll ------> LDView.exe
, I therefore conclude that LDViewThumbs64.dll erroneously tries to access LDView.exe instead of LDView64.exe.
Do you agree?
(B)
Another problem: 32bit applications (for example, MLCad.exe) do _show_ the thumbnails now,
but they do not _generate_ them. As I have LDViewThumbs.dll sitting around
on my system, I had thought it would spawn LDView64.exe (on 64bit systems), and LDView.exe (on 32bit systems)
to generate them. However, it does not. I have 2 suspicions why it does not work:
- as we saw in (A), LDViewThumbs64.dll does not spawn LDView64.exe, but LDView.exe erroneously, thus, I suspect that LDViewThumbs.dll vice versa tries to spawn LDView64.exe and fails
- or, the problem could get caused by the TypeLib registry setting, which, even for 32bit processes, still points to the 64bit DLL (see above)
As a solution, I suggest that you use separate CLSID and TypeLib identifiers for 32bit and 64bit.
The current re-using of them adds much confusion. Tracing down errors would be much easier that way.
©
Travis, I also spotted a problem with the registry keys where you store the pathes for the additional files
(Dir001, Dir002, Dir003 and so on). Note that all instances of them (in the current configuration, in the
presets, and in the screensaver) are affected:
when you edit their list via the GUI, i.e., you add some and then you remove some,
in the registry relicts remain. For example, my editing in the GUI was to first setup 4 pathes,
then again delete some to just have one. What resulted in the registry was that settings
Dir001, Dir003, Dir004 (but no Dir002) were present.
I think that this can lead to the effect that when a user then again adds a second path via the GUI, this will create a Dir002,
and then after restarting LDView, suddenly 4 pathes will be present, because the gap is closed.
Could you check that code?