Printable View
Yeah, I've got to agree with Eduardo. Chosk, what possible advantage are you gaining by renaming it? It seems like all downside to me.
Everyone knows that OCX files are actually ActiveX DLL files that are just typically used for custom controls. You're not really changing that fact by renaming it.
Good Luck,
Elroy
chosk, Thank you for responding.
The top, zCOMDLG, example has comdlg32.ocx in its .\Dependencies folder, using what I believe to be the SxS process.
That comdlg32.ocx and the manifest incorporated in the .res file in the build 'do not play well together'.
The bottom, zzCOMDLG, is an experiment, not using the SxS process.
Elroy, Thank you for your response.
Re: Your third suggestion, in post #58 paragraph 6:
I copied the comdlg32.ocx from my development host Win7(x64) PC's SysWOW64 folder into a ..\_Win7SysWOW64_dlls folder and had my NSIS script use that in its SxS? /process.
Oh well, that zCOMDLG tiny test app worked on development winxp, win7, but not on test win10 (same 339 error).
Hi anderci,
I ran regsvr42 on comdlg32.ocx in my Win7 and this is what I get. The only part I edit is the version number to match the ocx I have which is 6.1.98.16. It default to 1.0.0.0. I did not test it maybe you can give a try and see how. This one has all the different type of dialogs - open, color, print, font, help.
The manifest filename default to: comdlg32.sxs.manifest
Code:<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type="win32"
name="comdlg32.sxs"
version="6.1.98.16" />
<file name="comdlg32.ocx">
<comClass
description="Microsoft Common Dialog Control, version 6.0 (SP6)"
clsid="{8F0F480A-4366-4737-8265-2AD6FDAC8C31}"
threadingModel="Apartment"
progid="MSComDlg.CommonDialog"
tlbid="{F9043C88-F6F2-101A-A3C9-08002B2F49FB}" />
<comClass
description="Microsoft Common Dialog Control, version 6.0 (SP6)"
clsid="{F9043C85-F6F2-101A-A3C9-08002B2F49FB}"
threadingModel="Apartment"
progid="MSComDlg.CommonDialog"
tlbid="{F9043C88-F6F2-101A-A3C9-08002B2F49FB}" />
<comClass
description="Common Dialog Open Property Page Object"
clsid="{7629CFA2-3FE5-101B-A3C9-08002B2F49FB}" />
<comClass
description="Common Dialog Color Property Page Object"
clsid="{7629CFA4-3FE5-101B-A3C9-08002B2F49FB}" />
<comClass
description="Common Dialog Print Property Page Object"
clsid="{3C4F3BE5-47EB-101B-A3C9-08002B2F49FB}" />
<comClass
description="Common Dialog Font Property Page Object"
clsid="{3C4F3BE3-47EB-101B-A3C9-08002B2F49FB}" />
<comClass
description="Common Dialog Help Property Page Object"
clsid="{3C4F3BE7-47EB-101B-A3C9-08002B2F49FB}" />
</file>
</assembly>
Hi chosk,
Thank you very much for your response and suggestion.
I did name it ComDlg32.OCX.manifest
In the manifest, I changed to <file name="Dependencies\comdlg32.ocx"> (where I install my dependency files).
The ComDlg32.OCX file I have pulled in from my win7 SysWOW64 folder is the same version.
Manifest Creator II processed your manifest smoothly.
I built and installed in my winxp virtual PC it gave an error:
(This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.)
In the manifest, I changed the AssemblyIdentity name="comdlg32,ocx" and got the same error on my winxp virtual PC.
I installed and ran on my host win7 PC and got a different error:
(The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.) so I ran sxstrace and got:
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = Wow32
CultureFallBacks = en-US;en
ManifestPath = D:\Program Files (x86)\Clark_Anderson\zCOMDLG\zCOMDLG.exe
AssemblyDirectory = D:\Program Files (x86)\Clark_Anderson\zCOMDLG\
Application Config File =
-----------------
INFO: Parsing Manifest File D:\Program Files (x86)\Clark_Anderson\zCOMDLG\zCOMDLG.exe.
INFO: Manifest Definition Identity is zCOMDLG,processorArchitecture="x86",type="win32",version="1.0.0.4".
ERROR: Activation Context generation failed.
End Activation Context Generation.
I hope this makes sense to someone.
Thank you, again.
Hi anderci,
You are right. The manifest created with regsvr42 does not work. Same error as yours.
I just tried Elroy's (post #43) and it works.
Attached is my test project files.
Hi chosk,
Thank you for responding and for the test example. If I run it within the VB project, it works for me very well.
Beyond that I must be going astray. I did a File/Make comdlg_test.exe.
In that winXP virtual PC, I ran the resulting comdlg_test.exe in that project folder: I got a (comdlg_test Run-time error 7: Out of memory).
I modified one of my NSIS scripts and created an install file for it.
I used that install package on the same winXP virtual PC. That comdlg_test.exe had the same error.
I installed it on my win7(x64) host PC. running that copy of comdlg_test.exe still resulted in the (comdlg_test Run-time error 7: Out of memory)
Does anyone have any ideas where I went astray?
Hi anderci,
Did you copy comdlg32.ocx into the same folder as the compiled exe?
I get "Error 7: Out of memory" if I do not have the ocx there.
Forum rules do not allow attaching the ocx so I left it out of the zip.
Hi chosk, thank you.
Yes. The magic! I have my NSIS script putting the dependency files in a Dependencies subfolder. I merely copied the ComDlg32.OCX file from the Dependencies subfolder into the install folder and it works! (for both the winXP virtual PC and the win7(x64) host PC).
Next it is to figure out all of the differences between your successful test and my failing test. Again, thank you.
I notice you have two .res files (comdlg32EL.res, comdlg32rs42.res), whereas I have one (zCOMDLG.res).
Your comdlg32rs42.res is quite similar to my zCOMDLG.res. My zCOMDLG.res has an extra section (trustInfo).
Did you use Manifest Creator II to make comdlg32EL.res from the manifest in Elroy's (post #43)? , then add it to the files in your project.
And following that, did you use Manifest Creator II to create comdlg32rs42.res to complete the package?
Hi anderci,
The attached res file let you have the ocx in your Dependencies folder. Tested working.
Hi chosk,
I may be starting to understand your process?:
1) create .res files from the manifest for each dependency file.
2) from these add the appropriate .res files to your project files.
3) create the .res file for your project from its .vbp file
I have a folder of dependency file manifests.
1) I (again using Manifest Creator II) start with the project .vbp file
2) add to it from the appropriate dependency manifest files.
3) export it to create the project .res file.
4) add that project .res file to the project files.
My process works sometimes. Yours works!
Have I described your process correctly?
Hi anderci,
I use only 1 res file. If I am not wrong, can only use 1 res file. I put all the sxs info into 1 manifest file, also the theme, trust, program icon, etc. and then use RC.EXE to create the res file from the manifest. I also have a section that described my program's identity in assemblyIdentity, example:
The example here is to strip down to only comdlg32 to help make sure it works for you.Code:<assemblyIdentity
version="6.0.0.0"
processorArchitecture="X86"
name="MyCompany.DataManager.taDM"
type="win32" />
<description>DataManager</description>
I actually downloaded Manifest Creator II, but don't know how to use it.
Hi chosk,
I guess I over simplified and will have to come back for a closer examination...
MANIFEST CREATOR: this may help? http://www.vbforums.com/showthread.p...est-Creator-II
I downloaded from that thread. Guess I have to spend more time with it.Quote:
Originally Posted by anderci
After numerous interruptions, I finally replaced my zCOMDLG.res with your comdlg32EL.res and it also worked for me.Quote:
Originally Posted by chosk
My next test step was to, using Manifest Creator II, 1) Begin with my zCOMDLG.vbp file, 2) Append/Merge Manifest (your comdlg32EL.res file), 3) Export Manifest into my zCOMDLG.res file, 4) Make the zCOMDLG.exe
YEA! That shows me a path to fix my primary applications that use more than this one .ocx dependency file! Thank you very much!
OK, I followed the path/process for each of my primary applications:
1) [The Manifest]>[From File] Application.res
2) Scrolled through the tree to find errant comdlg32.ocx entry
3) Carefully right clicked on that line immediately left of 'File: Dependencies\comdlg32.ocx'
4) Selected Delete from Tree and confirmed the action
5) [The Manifest]>[Append/Merge Manifest] (your comdlg32EL.res file) I renamed it to comdlg32ocx.res.
6) [The Manifest]>[Export Manifest] into Application.res
7) Then I was able to save and make my Application.exe!
The results worked on both of the Windows 10(x64) and Windows 7(x64) test platforms.
Here is the last live link I can find on Fusion Technology in Windows:
Isolated Applications and Side-by-side Assemblies