My program works fine on my computer and my laptop. But, when i install it on my mothers computer, it cant find the TABCTL32.OCX file for the tabbed dialogs. The file is in her system directory though.
Any ideas on why it cant find it?
Printable View
My program works fine on my computer and my laptop. But, when i install it on my mothers computer, it cant find the TABCTL32.OCX file for the tabbed dialogs. The file is in her system directory though.
Any ideas on why it cant find it?
The first thing that occurs to me is that it was not installed properly.
Most likely either the file itself isn't where you think it is, or else it is there but is not registered at all or not registered globally How much do you know about filesystem and registry virtualization? Those are key topics for anyone trying to use VB6 in the post-XP world.
I'm not sure what else could result in the set of symptoms you have.
Well, it was installed by ActualInstaller. I set it to register the OCX file, but still didnt work. Now i installed the program with the P&K wizard set-up. Installed and works fine.
So, something with that installer.
Never saw nor used this ActualInstaller so no idea what its pros and cons would be.
Where did it install the file and what OS?
Win7 and installed in the SysWOW directory. I tried it on my son's PC and it really had issues with the OCX file. But, installing with the P&K wizard, worked just fine. Gotta be with registering those files.Quote:
Originally Posted by DataMiser
Get Regocx32.exe from the VB 6.0 install disc from directory \Common\Tools\VB\Regutils. Copy it into the windows\System32 (or system) folder.
Open a dos command and enter REGOCX32.EXE "C:\WINDOWS\SYSTEM32[or system]\myocxcontrol.OCX" (seems the quotes are required on my system -Windows 7.
The command does not offer feedback of success or failure but it worked for me. Of course myocontrol must be in the C:\Windows\System32[or system]
folder
More info here: https://support.microsoft.com/en-us/kb/198038
I would ignore the advice in post 6.
Use a proper installer. Do not resort to manually registering controls as suggested there that can cause you lots of issues if you are not very careful with it.
I agree 100%.Quote:
Originally Posted by DataMiser
Manually registering components (OCX/DLL) isn't a good choice, because tec Windows 'counter' (that register the numer of applications used by the component) will not updated.
This could cause serious damage to the system and the applications that use that component.
I certainly wouldn't argue with those suggesting the method I used may not be the best - I'm not knowledgeable enough to know the finer nuances (or even the coarser ones). But I did it, it worked, and I find it peculiar that Microsoft (at least implicitly) supports the idea by including it in a knowledgebase article - but then I suppose maybe there are times when this can't be trusted either.
Alright, I'm confused. What's the "tec Windows counter"?
I wasn't under the impression that a DLL or OCX kept track of how many applications used it. Rather, the way I've always understood things is that, any application that needs a particular DLL or OCX, simply looks in the registry for it, checks that its version is equal to or greater than the one it needs, and then uses it (based on the registry information). In this way, programs (during installation) could update DLLs and OCXs without (hopefully) disrupting other programs that also used them. And also, it didn't really matter whether the DLL or OCX file was registered through an installer or manually.Quote:
Originally Posted by gibra
If any of that is wrong, I'd be delighted to learn how.
Also, basically, the only (and LARGE) downside to this "version checking" approach is when a newer version of a DLL or OCX changes the way some call works such that it fouls up programs that expect it to work in an older way. This is very specifically known as DLL hell.
I had also written a response to meopilite but was having connection problems. I'll post it immediately after this post.
Regards To All,
Elroy
I have no idea why my text won't post, but I've just attached it as a .txt file.
It's basically to meopilite.
See attached.
Sorry, but what you write is completely wrong.Quote:
Originally Posted by Elroy
Windows keeps track of the number of applications using a specific component, as long as these is not installed through an installer program (which is identified by Windows).
I explain it in a simple way:
when the user installs a program that uses a component called XYZ.OCX, if that is not present in the system is added to the register, and the counter is set to 1.
If instead the XYZ.OCX component is already installed, the counter 1 will be incremented by 1.
I.e. if the component is used by 4 applications (correctly installed with a Setup) then the counter should be 4.
When the user removes a program, using the uninstall utility, Windows decrements the counter by 1.
If the user removes all 4 applications that use the component, then the counter is decremented until it becomes zero.
In this case Windows communicates to the user that the component is no longer used by any application and asks if want to remove it.
The user, correctly, answers yes, and the file will deleted.
When you using Regsvr32.exe to register the same component, the mechanism described above does not occur, that is, the counter is not incremented.
So it happens that when you uninstall an application that uses it, Windows does not know that the applications concerned are 5 instead of 4.
Therefore, once removed all the 4 applications, the 5th application that uses XYZ.OCX no longer work.
Conclusions
Now, if you do this only on your computer, you are free to do what you want.
But when you distribute applications to third parties, customers, etc. it is extremely important that you do things right, ricshiare without compromising the system of others.
It would be very serious if a customer uninstall your app and then find that other applications do not work anymore, because your removed the arbitrary files.
Which happens more often than you think...
This is the main reason why need to use a installer to create setup to make installations, in correctly and professionally way.
Interesting gibra. What you say makes sense.
I guess I haven't kept up with that because I haven't used an installer OR registered any OCX or DLL files in ages and ages. Once I got the side-by-side (.manifest) stuff going, I abandoned installers like the plague.
It's good to know how it works, but that also all sounds like another factor in what I'd call DLL hell if you ask me. IMHO, the only good reason for an installer is to get the program in the list of "installed programs", and to instruct Windows how it would be uninstalled. Other than the core OS files, I just feel that files shared by multiple programs that don't even know of each other is just asking for trouble.
Regards,
Elroy
I'm sticking with PDW. Its old, but works everytime on every PC I try it on.
Sitting here thinking and reading about OCX files.....
Microsoft says some OCX are not redistributable. One such file is the COMDLG32.OCX. So, the common dialog control should be already on everyone's PC. Makes sense, every PC is gonna need a Print, Open, and Save dialog. So, say I dont include that OCX file with my package. But, my program needs to use that file. How is my installer gonna register the file as needed if I dont include it in the package?
So now we're back at the original question. My program wont 'find' the common dialog control.
I don't know where you read that but that does not ring true.Quote:
Originally Posted by meopilite
In your VB folder there is a file titled redist.txt the list is long and comdlg32.ocx is there.
Here is a small snippet from that file
As you can see that control is redistributableQuote:
REDISTRIBUTABLE CODE - Extended Use:
comct232.ocx
comct332.ocx
comctl32.ocx
comdlg32.ocx
You should include it in your package
ok, thnks.
heres the MS link... read about middle of page under More Info. https://support.microsoft.com/en-us/kb/216368
That page does not mention the ocx it does mention the dll which of course you should not include but you do need to include the ocx
Quote:
Comdlg32.dll (Not redistributable)
i've had to hunt for these reference files on many occasions, often when its an unusual or proprietary ocx, activex or such. when i create my package for distribution i always force the vb wizard to install the required dll,ocx, etc in the same directory where the executable is located, rather than re-install them into the system directories. then whenever the user decides to 'uninstall' the program, the uninstall will only remove those local files, and not ones used (possibly) by other executables. keeping them all in one place also allows the user to do a 'dirty' uninstall by wiping that one program directory. the relatively small size of these duplicate files on most user computers is minimal, unless the user has already littered the disk with other stuff.
Sounds like a plan, but will your program find the dll's in the App directory instead of System directory? I suppose if thats where they are told to be installed........Quote:
Originally Posted by hapticz
I use Inno Setup. My neutral versions Redist folder is filled from the "MSMs to Libraries" from Dilettante:Quote:
Originally Posted by meopilite
http://www.vbforums.com/showthread.p...s-to-Libraries
http://www.vbforums.com/showthread.p...ommon-Controls --> path to Extract.exe
I extract the missing files from VB Service Pack 6 or VB6CD. My beta example works for the moment, but the constructive critics are admitted :-) .
INNO SETUP HELP:Code:[Files]
;Visual Basic 6.0 Runtime Files
Source: "C:\Redist\OLEPRO32.DLL"; DestDir: {sys}; OnlyBelowVersion: 6.0; Flags: 32bit uninsneveruninstall regserver restartreplace sharedfile
Source: "C:\Redist\OLEAUT32.DLL"; DestDir: {sys}; OnlyBelowVersion: 6.0; Flags: 32bit uninsneveruninstall regserver restartreplace sharedfile
Source: "C:\Redist\msvbvm60.dll"; DestDir: {sys}; OnlyBelowVersion: 6.0; Flags: 32bit uninsneveruninstall regserver restartreplace sharedfile
Source: "C:\Redist\ASYCFILT.DLL"; DestDir: {sys}; OnlyBelowVersion: 6.0; Flags: 32bit uninsneveruninstall restartreplace sharedfile
Source: "C:\Redist\COMCAT.DLL"; DestDir: {sys}; OnlyBelowVersion: 6.0; Flags: 32bit uninsneveruninstall regserver restartreplace sharedfile
Source: "C:\Redist\STDOLE2.TLB"; DestDir: {sys}; OnlyBelowVersion: 6.0; Flags: 32bit uninsneveruninstall regtypelib restartreplace sharedfile
Source: "C:\Redist1-SYSSP6\VB6ES.DLL"; DestDir: {sys}; Flags: 32bit uninsneveruninstall onlyifdoesntexist noregerror
;Dependencies Controls Files
Source: "C:\Redist\MCI32.OCX"; DestDir: {sys}; Flags: regserver 32bit uninsneveruninstall sharedfile restartreplace
Source: "C:\Redist\comctl32.ocx"; DestDir: {sys}; Flags: regserver 32bit uninsneveruninstall sharedfile restartreplace
Source: "C:\Redist\ComDlg32.OCX"; DestDir: {sys}; Flags: regserver 32bit uninsneveruninstall sharedfile restartreplace
Source: "C:\Redist\MSCOMCTL.OCX"; DestDir:{sys}; Flags: regserver 32bit uninsneveruninstall sharedfile restartreplace
Sharedfile FLAG
Specifies that the file is shared among multiple applications, and should only be removed at uninstall time if no other applications are using it. Most files installed to the Windows System directory should use this flag, including .OCX, .BPL, and .DPL files.
Windows' standard shared file reference-counting mechanism (located in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs) is used to keep track of how many applications depend on the file. Each time the file is installed, the reference count for the file is incremented. (This happens regardless of whether the installer actually replaces the file on disk.) When an application using the file is uninstalled, the reference count is decremented. If the count reaches zero, the file is deleted (with the user's confirmation, unless the uninsnosharedfileprompt flag is also specified).
If Setup is run more than once, the reference count for the file will be incremented more than once. The uninstaller will decrement the reference count the same number of times, however, so no references are leaked (provided the UninstallLogMode [Setup] section directive isn't changed from its default setting of append).
When this flag is used, do not specify {syswow64} in the DestDir parameter; use {sys} instead. Even though {sys} and {syswow64} map to the same underlying directory in a 32-bit mode install, the path name must exactly match what every other existing installer is using; otherwise, a second reference count for the file would be created, which could result in the file being removed prematurely. If you need to install a shared file to the 32-bit System directory in a 64-bit mode install, specify {sys} in the DestDir parameter and additionally include the 32bit flag.
sharedfile
Specifies that the file is shared among multiple applications, and should only be removed at uninstall time if no other applications are using it. Most files installed to the Windows System directory should use this flag, including .OCX, .BPL, and .DPL files.
Windows' standard shared file reference-counting mechanism (located in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs) is used to keep track of how many applications depend on the file. Each time the file is installed, the reference count for the file is incremented. (This happens regardless of whether the installer actually replaces the file on disk.) When an application using the file is uninstalled, the reference count is decremented. If the count reaches zero, the file is deleted (with the user's confirmation, unless the uninsnosharedfileprompt flag is also specified).
If Setup is run more than once, the reference count for the file will be incremented more than once. The uninstaller will decrement the reference count the same number of times, however, so no references are leaked (provided the UninstallLogMode [Setup] section directive isn't changed from its default setting of append).
When this flag is used, do not specify {syswow64} in the DestDir parameter; use {sys} instead. Even though {sys} and {syswow64} map to the same underlying directory in a 32-bit mode install, the path name must exactly match what every other existing installer is using; otherwise, a second reference count for the file would be created, which could result in the file being removed prematurely. If you need to install a shared file to the 32-bit System directory in a 64-bit mode install, specify {sys} in the DestDir parameter and additionally include the 32bit flag.
Remarks
If a file already exists on the user's system, it by default will be replaced according to the following rules:
1.If the existing file is an older version than the file being installed (as determined by the files' version info), the existing file will be replaced.
2.If the existing file is the same version as the file being installed, the existing file will not be replaced, except if the replacesameversion flag is used and the content of the two files differs.
3.If the existing file is a newer version than the file being installed, or if the existing file has version info but the file being installed does not, the existing file will not be replaced.
4.If the existing file does not have version info, it will be replaced.
Certain flags such as onlyifdoesntexist, ignoreversion, and promptifolder alter the aforementioned rules.
If Setup is unable to replace an existing file because it is in use by another process, it will make up to 4 additional attempts to replace the file, delaying one second before each attempt. If all attempts fail, an error message will be displayed.
Setup registers all files with the regserver or regtypelib flags as the last step of installation. However, if the [Setup] section directive AlwaysRestart is yes, or if there are files with the restartreplace flag, all files get registered on the next reboot (by creating an entry in Windows' RunOnce registry key).
the default search location (as i once read in the MS knowledge base) was the exe (or rather the loader) looks for what it needs in the same folder itself is in, THEN it starts searching through the defined windows OS path subdirectories such as system, system32, others and then looks into the REG for other defined paths (those ones usually modified by the various installer programs).Quote:
Originally Posted by meopilite
the OS does seem to fall back to the legacy path methods once so critical in the w95, XP era. the various DLL and other basic dynamic support files that are common should be where the OS expects them, but having your own NON-shared DLL's OCX's etc for your singular use will be used without problems.
as the OS keeps each program in its own 'private memory allocation area', they will never cross paths, theoretically at least. BUT, once your start doing cute buffer overuns and get memory addressing to the point of near blue screen, then its your own fault for having issues. messing with the API parameters in callous ways can be a direct means to crash your self and end up spending wasted hours doing debugs.
thats where all the error trapping come in, the OS does its own error checking to prevent some and your program should do its own checking to maintain ZERO memory leaks and such.