[BUG] Option "Integrate MultiPar in Shell" is always unchecked

[Urgehal]

Hello there,

i recognized following issue:
I checked the option "Integrate MultiPar in Shell" in Multipar's Options, then the Shell was finally activated.
But when I go again into "Options", the field stays unchecked, even when Multipar's Shell is working and active.

Regards...

[Yutaka Sawada]

MultiPar might fail to search registory entry about shell extension. When it cannot detect the entry, the check-box becomes unchecked. I will review the code. If you want to change setting, you may enable/disable the shell extension by command-line still.

BTW, some information are helpful. What is your OS ? Where did you install MultiPar ? Do your environment has something non-standard ? If I will not find the bug point, I may ask more information including registory tree. Mail is ok, if you want privacy.

[Urgehal]

If you want to change setting, you may enable/disable the shell extension by command-line still.

"Enable" works just fine, but when I need to disable it, I have to do it via cmd & regsvr.

BTW, some information are helpful.

Shame on me, I forgot that :).

OS: Win7 x64 SP1 (german)
MultiPar: v1.1.8.6
Install-Path: D:\Programme\Komprimierung\MultiPar1186

"Do your environment has something non-standard ?"
Mhh, no, not really.

Kind regards.

[Yutaka Sawada]

 MultiPar see a key in a registry entry. The key is written at the last of installing shell extension DLL. You check the registry entry;
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved"

 Is there a key of following ?
Name = {333EFDA5-A74E-4df4-A225-92A7AF81F29A}
Type = REG_SZ
Data = MultiPar Shell Extension

1) If the key does not exist, installation was failed.
2) If the key exists, read access was failed.

 I am not sure how is the access right to HKEY_LOCAL_MACHINE on Windows 7. If reading access by your user account is refused by OS, you should test it by changing your privilege. I made a sample application (CheckReg.exe) to show the result. Double-click it, then two dialogs will open one by one, first for HKEY_LOCAL_MACHINE and second for HKEY_CLASSES_ROOT. How is the result at your normal environment ? If you login the PC with higher privilege like admin account, is the result changed ?

 When the problem is caused by your privilege, I may change the checking registry key to another key in HKEY_CLASSES_ROOT. If you don't have access right to HKEY_CLASSES_ROOT also, I cannot solve your problem. Because I don't know detail of your case at this time, I wait your reply and will try possible solution.

[Urgehal]

Hello Yutaka,

sorry for the late answer.

"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved"

 Is there a key of following ?
Name = {333EFDA5-A74E-4df4-A225-92A7AF81F29A}
Type = REG_SZ
Data = MultiPar Shell Extension

Yep, key exists.

I am not sure how is the access right to HKEY_LOCAL_MACHINE on Windows 7. If reading access by your user account is refused by OS, you should test it by changing your privilege.

Ok, I started MultiPar with admin privileges, but the issue still exists. That option "Integrate MultiPar in Shell" stays disabled, even when it's clearly activated and working.

I made a sample application (CheckReg.exe) to show the result. Double-click it, then two dialogs will open one by one, first for HKEY_LOCAL_MACHINE and second for HKEY_CLASSES_ROOT. How is the result at your normal environment ?

By starting that CheckReg.exe with my ordinary user privileges I see only one dialog. See screenshot (checkreg.png).

If you login the PC with higher privilege like admin account, is the result changed ?

Nope, same result with admin privileges.

Many thanks for your quick help :).

Kind regards

[Yutaka Sawada]

 Thank you for test. I searched about Windows 7 for a while. On Windows 7 (with Internet Explorer 8 ?), Win32API SHGetValue function may not read value from HKEY_LOCAL_MACHINE. I changed the function to RegQueryValueEx in new test application. Will you test with the new sample ? If it cannot read value in HKEY_LOCAL_MACHINE still, I will change the reading target key.

[Urgehal]

Ok, I tested the new CheckReg.exe.

I started it via my user privileges, and following 2 dialogues popped up.

First one:

---------------------------
Error of RegQueryValueEx (HKEY_LOCAL_MACHINE)
---------------------------
Das System kann die angegebene Datei nicht finden.


---------------------------
OK   
---------------------------

"Das System kann die angegebene Datei nicht finden." means "The system cannot find the specified file."

Second Dialog:

---------------------------
pvData of SHGetValue (HKEY_CLASSES_ROOT)
---------------------------
data is '{333EFDA5-A74E-4df4-A225-92A7AF81F29A}'

---------------------------
OK   
---------------------------

Result is the same when I start it via admin privileges.
Many thanks for your help :).

Kind regards

[Yutaka Sawada]

 The mechanism of registry redirect/reflection on 64-bit OS seems to be changed at Windows 7. While the GUI is a 32-bit application, Shell Extension DLL for 64-bit OS is 64-bit DLL, and HKEY_LOCAL_MACHINE is affected by WOW64. I change the checking entry to HKEY_CLASSES_ROOT, and it return the installed path of DLL. So that, MultiPar GUI will confirm the DLL is associated with itself. Please test with the new version. If it shows a dialog with DLL's path, it works well.

[Urgehal]

CheckReg_2011-06-27

---------------------------
Error of SHGetValue (InprocServer32)
---------------------------
Das System kann die angegebene Datei nicht finden.


---------------------------
OK  
---------------------------

"Das System kann die angegebene Datei nicht finden." means "The system cannot find the specified file."

[Yutaka Sawada]

 When 32-bit application access to the entry under "CLSID", 64-bit OS 's "Registry Redirect" redirects the access to Wow6432Node. Because you install 64-bit DLL (32-bit DLL is not installed), there is no entry of 32-bit DLL.

 I modified the checking entry on 64-bit OS at next version. Though the install path is not checked, there is no problem, unless you install multiple times on different place. (Normally users install to only one place.)