Dear All I have a VB program that uses the Richtx32.ocx. As I don't like to distribute a setup program with my VB program and WinXP seems to have Richtx32.ocx already included I thought that I just query whether this ocx is already registered and if not I register it via VB code. I have already found out how I can register a ocx via VB code but I don't know how to query whether it is already registered or not. Does anybody know how this can be done? Can the same application that uses a certain ocx first query whether it is registered or not or will the while application never start if it is not registered?
even if you register any ocx again it won't make a difference.. nyways in the case of richtx32.ocx or any ocx distributed with the OS, it's already registered...
if richtx32.ocx is not there your program will throw an exception..nd your querying for it's registered status won't make a difference cos the ocx is anyways needed...
to be on the safe side it's better to include it with your application....it's true that winXP may have it, but it's also possible that some other application using richtx32.ocx removes it upon it's uninstall
"Peter" wrote: > Dear All > I have a VB program that uses the Richtx32.ocx. > As I don't like to distribute a setup program with my VB program and WinXP > seems to have Richtx32.ocx already included I thought that I just query > whether this ocx is already registered and if not I register it via VB code. > I have already found out how I can register a ocx via VB code but I don't > know how to query whether it is already registered or not. > Does anybody know how this can be done? > Can the same application that uses a certain ocx first query whether it is > registered or not or will the while application never start if it is not > registered?
> Dear All > I have a VB program that uses the Richtx32.ocx. > As I don't like to distribute a setup program with my VB program and > WinXP seems to have Richtx32.ocx already included I thought that I > just query whether this ocx is already registered and if not I > register it via VB code. I have already found out how I can register > a ocx via VB code but I don't know how to query whether it is already > registered or not. Does anybody know how this can be done? > Can the same application that uses a certain ocx first query whether > it is registered or not or will the while application never start if > it is not registered?
If it is there, and is at least the version you need, re-registering it would not hurt. If it is not there, or is an older version, then you will need to install and register your version. No matter what the situation is you don't need to know if it is already registered.
-- Reply to the group so all can participate VB.Net... just say "No"
Peter wrote: > Dear All > I have a VB program that uses the Richtx32.ocx. > As I don't like to distribute a setup program with my VB program and WinXP
No one really likes it <g>. The problem is, not all operating systems even have the VB runtimes. If your target OS is limited exclusively to Win2k or XP, you can sometimes get away without a package if you use only MS controls.
> seems to have Richtx32.ocx already included I thought that I just query > whether this ocx is already registered and if not I register it via VB code. > I have already found out how I can register a ocx via VB code but I don't > know how to query whether it is already registered or not. > Does anybody know how this can be done? > Can the same application that uses a certain ocx first query whether it is > registered or not or will the while application never start if it is not > registered?
As others pointed out, re-registering a control doesn't hurt anything. I don't recall which one but I used to have at least one application that added a call to Regsvr32 to reregister a certain ocx everytime the computer was booted.
Also, if you start your app from Sub Main, you can setup an error trap that can detect the missing OCX and report it to the user or just go ahead and attempt to register it.
Sub Main will run before any forms are loaded so the app won't bomb immediately like it would if your startup object was Form1 (for example) and that contained an OCX that wasn't registered.
> Thanks for any help on this > Regards > Peter
-- Ken Halter - MS-MVP-VB - http://www.vbsight.com Please keep all discussions in the groups..
> Dear All > I have a VB program that uses the Richtx32.ocx. > As I don't like to distribute a setup program with my VB program and WinXP > seems to have Richtx32.ocx already included I thought that I just query > whether this ocx is already registered and if not I register it via VB code. > I have already found out how I can register a ocx via VB code but I don't > know how to query whether it is already registered or not. > Does anybody know how this can be done? > Can the same application that uses a certain ocx first query whether it is > registered or not or will the while application never start if it is not > registered?
> Thanks for any help on this > Regards > Peter
There are several ways you can verify the existence of a control. You could look for the component \%windir%\System32\RichTx32.ocx. You could open the Registry and look for RichTextLib.RichTextBox. You could perhaps "install" and register the component if was missing and then relaunch your application, or some other sort of mechanism. This latter exercise would require that a copy of the .ocx is available.
Frankly, IMHO, this is a silly way to approach the problem. Whether you "like" to provide a 'setup' with your VB application has little relevance (none actually). If you are going to utilize OLE/COM technologies then use the tools provided to insure a reliable install. "DLL Hell" is easy enough to descend into without going out of your way to manufacture alternative opportunities.
Learn how to create and use a 'setup' program. Period. Why re-invent the wheel?
You can use M$'s P&D (free) which is included with VB6, which is for what appears to be a simple setup.
On Thu, 2 Sep 2004 15:40:36 +0200, "Peter" <pete...@myrealbox.com> wrote:
>As I don't like to distribute a setup program with my VB program and WinXP >seems to have Richtx32.ocx already included I thought that I just query >whether this ocx is already registered and if not I register it via VB code.
Two solutions I know of: Either try to load the OCX and see if it generates an error (but it could load but be an older version than your program expects...), or do it the more thorough way by querying the Registry with the OCX's CLSID (that long, 128-byte hexa number that uniquely identifies an OCX.)
Here's what you could put in your project's Sub Main() to check before loading any form:
'If TestReg("word.prog") = False then... Function TestReg (ByVal sProgID As String) As Boolean On Error GoTo Trap Dim oMyObject As Object Set oMyObject = CreateObject(sProgID) TestReg = True Trap: End Function
My immediate reaction to the question was the same as the other two posts: why bother, just register it, it wouldn't hurt if it was there already. But on the second thought, the issue is not that simple.
If the OCX/DLL is your custom file, fine, you can register it as you want, you may register a newer version to replace older one, you can also to the opposite, register an older version to replace a buggy new version (due to some reason, anyway). As long as your app works.
But if the OCX/DLL is most likely included in Windows originally, things could turn ugly. Consider following situation:
1. The target Windows machine has newest OCX/DLL (Richtx32.ocx, in your case), which comes with Windows, or installed by other app(s)., being placed in, say, C:\WINNT\System32 2. You developed an app that uses the same OCX/DLL. 3. Your app's installation went ahead to register the OCX/DLL in C:\your app. Now all apps that use the OCX/DLL get it in this location. 4. User decided to remove your app later on. Every thing is removed, including the OCX/DLL. 5. Other apps that use the OCX/DLL now are broken.
So, the issue become: you must make sure the OCX/DLL is not uninstalled if it is shared. But even the uninstallation program is made that it does not remove the OCX/DLL, after uninstalling your app, you would left a single file (the OCX/DLL) in C:\Your app folder. More often than not, the user of that computer would think, "Gee, I just removed the App, why it not got cleaned up?", He then delete the "C\Your app" folder manually. Now your know what would happen.
Also, you may register an older version of the same OCX/DLL, while other app require the newer version (classical DLL hell issue).
So, I'd suggest to take extra caution to those OCX/DLL that may included in different version of Windows. However, I personally haven't had chance to deal this kind thing in my projects.
> Dear All > I have a VB program that uses the Richtx32.ocx. > As I don't like to distribute a setup program with my VB program and WinXP > seems to have Richtx32.ocx already included I thought that I just query > whether this ocx is already registered and if not I register it via VB code. > I have already found out how I can register a ocx via VB code but I don't > know how to query whether it is already registered or not. > Does anybody know how this can be done? > Can the same application that uses a certain ocx first query whether it is > registered or not or will the while application never start if it is not > registered?
> My immediate reaction to the question was the same as the other two posts: > why bother, just register it, it wouldn't hurt if it was there already. But > on the second thought, the issue is not that simple.
> If the OCX/DLL is your custom file, fine, you can register it as you want, > you may register a newer version to replace older one, you can also to the > opposite, register an older version to replace a buggy new version (due to > some reason, anyway). As long as your app works.
> But if the OCX/DLL is most likely included in Windows originally, things > could turn ugly. Consider following situation:
> 1. The target Windows machine has newest OCX/DLL (Richtx32.ocx, in your > case), which comes with Windows, or installed by other app(s)., being placed > in, say, C:\WINNT\System32 > 2. You developed an app that uses the same OCX/DLL. > 3. Your app's installation went ahead to register the OCX/DLL in C:\your > app. Now all apps that use the OCX/DLL get it in this location. > 4. User decided to remove your app later on. Every thing is removed, > including the OCX/DLL. > 5. Other apps that use the OCX/DLL now are broken.
> So, the issue become: you must make sure the OCX/DLL is not uninstalled if > it is shared. But even the uninstallation program is made that it does not > remove the OCX/DLL, after uninstalling your app, you would left a single > file (the OCX/DLL) in C:\Your app folder. More often than not, the user of > that computer would think, "Gee, I just removed the App, why it not got > cleaned up?", He then delete the "C\Your app" folder manually. Now your know > what would happen.
> Also, you may register an older version of the same OCX/DLL, while other app > require the newer version (classical DLL hell issue).
> So, I'd suggest to take extra caution to those OCX/DLL that may included in > different version of Windows. However, I personally haven't had chance to > deal this kind thing in my projects.
Or if a Vorgon warship was passing by and just happened to be scanning the user's computer while the registration was happening and the CLSID translated to an extremely unpopular insult and the user's computer is suddenly vaporized by a shocked and startled watch commander...
Or, just follow the rules. If there is a chance a needed component for your application may not already be installed - include a setup program to install it.
> "Peter" <pete...@myrealbox.com> wrote in message > news:1094132436.886647@zwei... > > Dear All > > I have a VB program that uses the Richtx32.ocx. > > As I don't like to distribute a setup program with my VB program and WinXP > > seems to have Richtx32.ocx already included I thought that I just query > > whether this ocx is already registered and if not I register it via VB > code. > > I have already found out how I can register a ocx via VB code but I don't > > know how to query whether it is already registered or not. > > Does anybody know how this can be done? > > Can the same application that uses a certain ocx first query whether it is > > registered or not or will the while application never start if it is not > > registered?
> > Thanks for any help on this > > Regards > > Peter
> Or if a Vorgon warship was passing by and just happened to be scanning the > user's computer while the registration was happening and the CLSID > translated to an extremely unpopular insult and the user's computer is > suddenly vaporized by a shocked and startled watch commander...
Those Vorgon's really are cheeky git's y'know. Had the ordasity to ask me if I'd buy em a pint the other day.....
> My immediate reaction to the question was the same as the other two posts: > why bother, just register it, it wouldn't hurt if it was there already. But > on the second thought, the issue is not that simple.
> If the OCX/DLL is your custom file, fine, you can register it as you want, > you may register a newer version to replace older one, you can also to the > opposite, register an older version to replace a buggy new version (due to > some reason, anyway). As long as your app works.
> But if the OCX/DLL is most likely included in Windows originally, things > could turn ugly. Consider following situation:
> 1. The target Windows machine has newest OCX/DLL (Richtx32.ocx, in your > case), which comes with Windows, or installed by other app(s)., being placed > in, say, C:\WINNT\System32 > 2. You developed an app that uses the same OCX/DLL. > 3. Your app's installation went ahead to register the OCX/DLL in C:\your > app. Now all apps that use the OCX/DLL get it in this location. > 4. User decided to remove your app later on. Every thing is removed, > including the OCX/DLL. > 5. Other apps that use the OCX/DLL now are broken.
> So, the issue become: you must make sure the OCX/DLL is not uninstalled if > it is shared. But even the uninstallation program is made that it does not > remove the OCX/DLL, after uninstalling your app, you would left a single > file (the OCX/DLL) in C:\Your app folder. More often than not, the user of > that computer would think, "Gee, I just removed the App, why it not got > cleaned up?", He then delete the "C\Your app" folder manually. Now your know > what would happen.
> Also, you may register an older version of the same OCX/DLL, while other app > require the newer version (classical DLL hell issue).
> So, I'd suggest to take extra caution to those OCX/DLL that may included in > different version of Windows. However, I personally haven't had chance to > deal this kind thing in my projects.
> "Peter" <pete...@myrealbox.com> wrote in message > news:1094132436.886647@zwei... > > Dear All > > I have a VB program that uses the Richtx32.ocx. > > As I don't like to distribute a setup program with my VB program and WinXP > > seems to have Richtx32.ocx already included I thought that I just query > > whether this ocx is already registered and if not I register it via VB > code. > > I have already found out how I can register a ocx via VB code but I don't > > know how to query whether it is already registered or not. > > Does anybody know how this can be done? > > Can the same application that uses a certain ocx first query whether it is > > registered or not or will the while application never start if it is not > > registered?
> > Thanks for any help on this > > Regards > > Peter
> Or if a Vorgon warship was passing by and just happened to be scanning > the user's computer while the registration was happening and the CLSID > translated to an extremely unpopular insult and the user's computer is > suddenly vaporized by a shocked and startled watch commander...
> Or, just follow the rules. If there is a chance a needed component for > your application may not already be installed - include a setup > program to install it.
Thank you all very much for your inputs. I think I have learnd a lot.
One more question to you: What Windows Version should have Richtx32.ocx included? Does MS specifies this somewhere? Should Win98 and upwards already include it and should it be automatically registered if there is a standard windows installation on the PC?
> Dear All > I have a VB program that uses the Richtx32.ocx. > As I don't like to distribute a setup program with my VB program and WinXP > seems to have Richtx32.ocx already included I thought that I just query > whether this ocx is already registered and if not I register it via VB > code. > I have already found out how I can register a ocx via VB code but I don't > know how to query whether it is already registered or not. > Does anybody know how this can be done? > Can the same application that uses a certain ocx first query whether it is > registered or not or will the while application never start if it is not > registered?
> Thank you all very much for your inputs. > I think I have learnd a lot.
> One more question to you: > What Windows Version should have Richtx32.ocx included? Does MS specifies > this somewhere? > Should Win98 and upwards already include it and should it be automatically > registered if there is a standard windows installation on the PC?
> Regards > Peter
Ha. You don't give up do you? <g>
The DLL Help Database is useful for tracking down information concerning versions and packages they are included with: Go to the database site and enter the name of the component you are interested in.
Looking through the versions listed, no O/S is mentioned (except for the NT 4.O Option Pack), but it appears to be consistently installed with Office Packages.
The MSDN does have a Platform site for each OS and there are published list of included files, but with slightly different OEM builds, releases, service packs, specific corporate images, vendor bundles, etc. I imagine the lists are not 100% reliable, but likely close.
It still strikes me as a waste, to spend all that time, trying to determine the existence of something, just to save not including a setup. Perhaps, you are attempting to perform an xcopy install or deliver some form of sleath product. In which case perhaps you are asking the wrong question.
<nt_consultin...@address.com> wrote: >It still strikes me as a waste, to spend all that time, trying to determine >the existence of something, just to save not including a setup. Perhaps, you >are attempting to perform an xcopy install or deliver some form of sleath >product. In which case perhaps you are asking the wrong question.
I guess the OP is mixing two problems: How to install a complete, working VB app on all the different flavors of Windows, and how to keep an installed application up to date. I'm back at looking at the second issue, ie. implementing Symantec's LiveUpdate.
Thanks again for your answer. Well, I will tell you the truth: I hate programs that needs to be installed first. I often had problems in the past when I have installed programs from others: they changed some dlls/ocx and other existing sw was not working correct anymore. You also need to take care to uninstall the software later again. I have also seen that even the VB P&D generates some errors now and then on different PCs especially if these PCs have different windows versions insalled in different languages.I you ship out just an exe file you don't need to take care on that. And my strategy is always: better to have less functionalities in your programs but don't use any activex that require a setup routine.
Maybe this can become a seperate thread to discuss in this newsgroup but for the moment I can tell you something about my current project:
It's, of course a simple VB program that is just an exe without any setup routine and I ship it to my customers around the world. I ever thought that one of them will once report that the VB runtime is missing but I never had this situation so far(over many years now). In this case I would send him the link on the internet to download and install the VB runtime, now after many years no customer ever reported that the VB runtime is missing on his PC. However, my problem starts now because I like to add unicode functionalities to my program but the MS textbox does not support it. I need to use a different control instead, I have seen that Richtx32 control does what I want. Because I like to continue my strategy to avoid any setup routine but extend my simple exe for unicode support I have a problem: the Richtxt32.ocx must be available on the customers PCs and it must be registered there. I thought I add the following routines to my program at startup: -check whether file richtx32.ocx is available on PC, if not report error message that this file is needed and end program, otherwise continue. -check whether richtx32 is registered(by trapping a runtime error), if not register it(found already some winapi calls that can do this) and continue. -load the form with the richtextbox
I will then watch how many customers will ask me for the file richtx32.ocx. If every 2nd customer asks for it then I need to change my concept(I am playing with some ideas to either put richtx32.ocx into the compiled exe or generate it the veriy first time via VB code...), if there are just a few customers then I let them download richtx32.ocx manually from a website and store it in system32 folder. My program would then register it automatically with the next start.
Of course if one would have an idea how to have unicode support with the standard vb controls(I just need a textbox) , maybe via winapi calls then I wouldn't need any external control at all...
Anyway, you can tell me tons of arguments to use a setup routine I will always look for ways to aviod it ;-)
>> Thank you all very much for your inputs. >> I think I have learnd a lot.
>> One more question to you: >> What Windows Version should have Richtx32.ocx included? Does MS specifies >> this somewhere? >> Should Win98 and upwards already include it and should it be >> automatically >> registered if there is a standard windows installation on the PC?
>> Regards >> Peter
> Ha. You don't give up do you? <g>
> The DLL Help Database is useful for tracking down information concerning > versions and packages they are included with: Go to the database site and > enter the name of the component you are interested in.
> Looking through the versions listed, no O/S is mentioned (except for the > NT > 4.O Option Pack), but it appears to be consistently installed with Office > Packages.
> The MSDN does have a Platform site for each OS and there are published > list > of included files, but with slightly different OEM builds, releases, > service > packs, specific corporate images, vendor bundles, etc. I imagine the lists > are not 100% reliable, but likely close.
> It still strikes me as a waste, to spend all that time, trying to > determine > the existence of something, just to save not including a setup. Perhaps, > you > are attempting to perform an xcopy install or deliver some form of sleath > product. In which case perhaps you are asking the wrong question.
