Printable View
Hello,
I am providing to regular users an app that use Windows common controls (comdlg32.ocx, MSCOMCTL.OCX..).
Can I assume that Windows common controls (comdlg32.ocx, MSCOMCTL.OCX..) exist And are registered in clients computers (Win7 and Win10) or should I provide and register them during the app installation?
If so, is there a way that even standard users without admin rights could register these controls?
Thanks for any clarification
Avi
Thread moved from the 'CodeBank VB6' forum (which is for you to post working code examples, not questions) to the 'VB6 and earlier' forum
I would not assume those are installed on every pc. Even if they are, you may have some issues. Read this thread for a little scary fun.
If the only thing you use the common dialog for is selecting files, consider an API substitute. You can find them in the codebank and many other places on the web. Advantage is a modern file browser & no ocx dependency. Search key terms: unicode open save file, or api open save file
The common controls v5 should be available on the target systems. They can be skinned to look like system controls when using a manifest; however, they have less options that the v6 control and can be harder to use.
I don't know of any way for a Standard User to register OCXs supplied with or created using VB6. That's because they are designed to be registered per-machine, so elevation is required.
However many of them can be used without registration if a carefully created manifest is used, at least on Windows XP SP1 and later.
Sadly though that feature was added to Windows in order to support VB6 programs, Microsoft never released any tools for doing this with VB6. Instead the only tools they provide are those intended to support .Net programs, and come with umpteen versions of Visual Studio .Net released after VS 6.0 came out. Even if you have those installed it isn't obvious how to use them with VB6 applications.
There are 3rd party tools such as MMM, the loose clone of that UMMM, and the commercial product Side-by-Side Manifest Maker.
None of these are for casual users though. It is easy to use them improperly and make quite a mess on target systems if you don't understand how things work. For example never dump ActiveX DLLs and OCXs "next to" (same folder as) a VB6 EXE, or the runtime will find them if not already properly registered and try to register them on first use. If the program is not running elevated this can cause messy virtualized registration of the libraries and might break other applications that also use those classes and controls.
This "breakage" normally occurs when you remove your copies of these libraries but leave the registry pointing to these files. Other programs subsequently installed are broken now because the registry points to your copies, which were removed.