Thank you. done: Thread: Error 481 - Invalid picture in compiled exe (vb6 sp6) in Win7 II
Should I try to remove my off topic posts to this Thread?
No, just let your new thread develop naturally. I'm sure that most (if not all) of the people who might help you will have also read this thread.
Good Luck,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I haven't used that OCX in years. I use an API alternative, which I like much better. There are several versions of procedures using API calls for common dialogs floating around, but I can post mine if you like.
Alternatively, let me try and make a manifest for ComDlg32.OCX. I'm just going to generate it, and let you do the testing.
Also, I've been working on a tutorial for all of this. It's basically done, just not yet moved to Tutorials Forum. It can be found here.
Good Luck,
Elroy
EDIT1: Don't forget to re-direct to a "Dependencies" sub-folder if you're doing that. Something like...
Code:
<file name="Dependencies\comdlg32.ocx">
Last edited by Elroy; Sep 15th, 2017 at 04:13 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
If you wind up using that ComCtl32.ocx manifest and it works, let me know and I'll add it to the tutorial.
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Thank you. Oh well, I cannot win them all (same 339 Component 'COMDLG32.OCX' or one of its dependencies not correctly
registered: a file is missing or invalid error)
Manifest Creator accepted the file and added it to the resource file.
I am just using it to print from one of my forms (open a printer selection dialog form). Does that fit with what you use?
Hi Elroy,
I can give you what ever you may want of my tiny text program: zCOMDLG.exe
It runs on my Development Host windows 7 (x64) PC. When I close it, the printer selection dialog form opens, which I, then, [Cancel].
On my test windows 10 (x64) PC, when zCOMDLG.exe is started it has the Run-time error 339.
Everything, else has been working there, with the fixed resource files.
Googling does not lead to any obvious solutions to my problematic Dependencies\COMDLG32.OCX.
Really, all I'd probably need is a copy of the manifest file you're using.
I'll try to use the ComDlg32.ocx in a SxS way while I'm waiting on your post and let you know.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Okay, anderci, all seems to be copacetic for me. I'll outline the steps I just went through:
Create a "New Folder" on my desktop.
Create a default project, saving Form1 and Project1 in "New Folder". (Edit: And put a Command1 button on the form.)
Copied and pasted the manifest from my post #43 above. I just put it in a file named manifest.txt.
Loaded and opened the VB6 Resource Editor.
Drug the manifest.txt into my project (into the Resource Editor), and renamed it to Type=#24 and ID=1.
Opened the Project/Components... and added the ComDlg32.ocx from SysWOW64 to my project.
Placed a copy of the CommonDialog control on my Form1.
Added the following code to my Form1:
Code:
Option Explicit
Private Sub Command1_Click()
CommonDialog1.ShowColor
End Sub
Ran the project in the IDE just to test it. It ran fine.
Compiled the project into a Project1.exe (same "New Folder" folder).
Ran Project1.exe and got the following error (which was expected):
Made a copy of my ComDlg32.ocx from my SysWOW64 folder and placed in this "New Folder".
Tried running Project1.exe again, and it ran fine:
Notice that I didn't redirect things to a "Dependencies" folder, but that shouldn't make any difference so long as the manifest file matches where the OCX files are.
I hope that can help in some way,
Elroy
Last edited by Elroy; Sep 16th, 2017 at 08:43 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I do my VB6 development in a VMWare virtual WinXP PC hosted on my Win7(x64) PC
I use MANIFEST CREATOR II to assemble my zCOMDLG.res
My NSIS script pulls the File "C:\WINDOWS\system32\COMDLG32.OCX"
Last edited by anderci; Sep 16th, 2017 at 09:05 PM.
Ok, anderci, I just did a Notepad++ compare between yours and mine, and there's only the addition of the "Dependencies\" sub-folder redirection. Therefore, for you, the ComDlg32.ocx should be in a "Dependencies" sub-folder immediately beneath wherever your executable is.
Also, I was expecting to see a much larger manifest. The manifest you just posted is for a project that ONLY wants to use the ComDlg32.ocx in a SxS way. I thought you were developing a project that was using several OCX files.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Also, I'm sitting in a restaurant with my laptop right now, and don't have access to a printer. In fact, I won't have access to a printer until Monday. Else, I'd try more precisely what you're doing.
Maybe someone else has some ideas in the interim.
Truth be told, if you're getting the printer dialog, I'm not sure your problem has to do with the OCX or the SxS approach.
Does it work if you forget the SxS, and just use the registered version of ComDlg32.ocx? (in SysWOW64 or System32)
Good Luck,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Hi Elroy,
I have created tiny programs for each OCX file. that is the only dependency used. At this point I have more tiny apps than primary programs.
I created one that uses no OCX files because I was having issues with the existence of an icon in the form.
I think I'm missing something here. If you're able to open the printer dialog like you show in post #49, I'm not sure I know what the problem is.
Is there still a problem? If so, please outline it for me.
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
My tiny test app, zCOMDLG.exe works on my development PC environments because they are 'tainted' by development activity (all manner of dependency files exist and are registered).
On a fresh Windows 10 (x64), however, it does not work. I expect that most people that might my use my primary free applications (reg-free) would have PCs not used for development. I do not want the addition, use or removal of any of my applications to effect any other operations on their PCs. All four of my primary applications can make use of the ability to send some content to a printer.
:
CommonDialog1.Flags = cdlPDReturnDC + cdlPDNoPageNums
CommonDialog1.Flags = CommonDialog1.Flags + cdlPDAllPages
CommonDialog1.ShowPrinter
:
Last edited by anderci; Sep 18th, 2017 at 06:52 AM.
Does it work if you forget the SxS, and just use the registered version of ComDlg32.ocx? (in SysWOW64 or System32)
I might be understanding you.
In the test Win10(x64) PC, I do not find any COMDLG32.ocx. Instead, I find COMDLG32.dll. Running there I get these messages:
On my development host win7(x64) PC, both tiny apps work. In that SysWOW64 there are: (COMDLG32 .Dep, .dll and .OCX) In that System32 there is COMDLG32.dll
On my development virtual winxp(x32), I find, in system32: (COMDLG32 .Dep, .dll, .oca and .OCX)
Both tiny apps work there.
I hope I have understood you. Thank you for your responses.
First, your problem is not really related to whether or not you're using the SxS technology (i.e. a manifest and managing your own OCX files).
Secondly, unless you're setting up API call declarations (which I don't think you are), you absolutely must have the ComDlg32.OCX, and that's true regardless of whether you're using SxS or not.
Okay, on your Win10(x64) computer, you've got to get a copy of ComDlg32.ocx on it, one way or another. The easiest thing to do would be to copy it from your Win7 machine, and place it into the C:\Windows\SysWOW64 folder, then open a CMD window, navigate to C:\Windows\SysWOW64, and then type in: regsvr32 cmddlg32.ocx
After doing that, the version of your program that does not have a manifest should start working on that Win10 machine.
Now, there are a couple of other ways to handle this. A second way would be to put your program onto the Win10 machine with some kind of installation process (rather than just copying it). Any decent program that "prepares" your program for distribution should recognize that your program needs the ComDlg32.ocx file. And then, when your program is "installed" on the Win10 machine, that ComDlg32.ocx will be placed into the SysWOW64 folder and registered. This is what installers do.
Yet another way to solve this problem is to set your program up with a manifest (with the necessary SxS stuff in it for the ComDlg32.ocx), and then make sure that the ComDlg32.ocx is in the "Dependencies" sub-folder on the Win10 machine (if that's the way you've set up the manifest file). I'll assume that you'll just do manual copies onto your Win10 machine to get that set up.
Basically, the bottom line is that your program must find that ComDlg32.ocx file to work, either through SxS or through the registry and then in the SysWOW64 folder. Actually, without a manifest, your program will not know to look in SysWOW64. It will go to Windows registry to find it, and the registry will tell it to look in SysWOW64. That's why, if you're not using SxS, it's important that you use regsvr32 to register the OCX (as explained above), or you use an installer that does that part for you.
Ok, I feel like I was somewhat redundant in all the above. I hope that information helps you to find a way forward.
Good Luck,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I have a question I am not sure whether I can ask here.
I am using a 3rd-party ocx (from ccrp) and I have a preference to rename it to with an extension of dll instead of ocx. I have tested the renamed file registered in SysWOW64 as well as unregistered with sxs manifest. It looks to be working as normal. It is not codesigned and I intend to codesign it with my cert in case some Windows or anti-virus/malware may become troublesome with unsigned dll. (I notice that all MS dll and ocx are codesigned.)
I have a question I am not sure whether I can ask here.
I am using a 3rd-party ocx (from ccrp) and I have a preference to rename it to with an extension of dll instead of ocx. I have tested the renamed file registered in SysWOW64 as well as unregistered with sxs manifest. It looks to be working as normal. It is not codesigned and I intend to codesign it with my cert in case some Windows or anti-virus/malware may become troublesome with unsigned dll. (I notice that all MS dll and ocx are codesigned.)
I wonder if there is any gotcha by renaming it?
But what's the point to rename its extension?
I would prefer not to do it. Perhaps you don't have a problem now, but who knows, may be an antivirus could flag is as suspicious or something.
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
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
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).
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
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.
Last edited by anderci; Sep 20th, 2017 at 06:29 PM.
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)
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?
Last edited by anderci; Sep 21st, 2017 at 10:16 AM.
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.
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 attached res file let you have the ocx in your Dependencies folder. Tested working.
After numerous interruptions, I finally replaced my zCOMDLG.res with your comdlg32EL.res and it also worked for me.
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.
Originally Posted by anderci
Reply With Quote