Query whether OCX is already registered
Peter
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
Gaurav - http://www.gauravcreations.com
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
--
Gaurav Creations
Bob Butler
news:1094132436.886647@zwei
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"
Ken Halter
> 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..
Ralph
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.
M$'s Visual Installer (free) which is perhaps the better product for XP.
http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/download.aspx
An excellent 3rd party product, Inno Setup.
http://www.jrsoftware.org/isinfo.php
Or if you want to spend some money -Wise:
http://www.wise.com/wps.asp
Or, a couple of dozen of others. Just do a Google search.
-ralph
Fred
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
More infos for the second method:
http://www.mvps.org/emorcillo/vb6/com/index.shtml
http://www.experts-exchange.com/Programming/Programming_Languages/Visual_Basic/Q_20575124.html#8274917
http://vbaccelerator.com/home/VB/Utilities/ActiveX_Documenter/article.asp
Fred.
Norman Yuan
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" <pet...@myrealbox.com> wrote in message
news:1094132436.886647@zwei...
Ralph
"Norman Yuan" <nob...@nowhere.no> wrote in message
news:ORt0B6P...@TK2MSFTNGP11.phx.gbl...
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.
-ralph
Steven Burn
news:O$gOTGQkE...@TK2MSFTNGP09.phx.gbl...
> 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.....
--
Regards
Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk
Keeping it FREE!
Steven Burn
"If it's your own OCX/DLL, run the reg anyway, if not, use an installer to
determine whether to install/reg/replace it"
--
Regards
Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk
Keeping it FREE!
"Norman Yuan" <nob...@nowhere.no> wrote in message
news:ORt0B6P...@TK2MSFTNGP11.phx.gbl...
Tim Baur
"What's 6 * 7?"
"Ralph" <nt_cons...@address.com> wrote in
news:O$gOTGQkE...@TK2MSFTNGP09.phx.gbl:
Peter
Hi
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
"Peter" <pet...@myrealbox.com> schrieb im Newsbeitrag
news:1094132436.886647@zwei...
Ralph
"Peter" <-> wrote in message news:ujnxjLSk...@TK2MSFTNGP15.phx.gbl...
>
> Hi
>
> 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.
http://support.microsoft.com/default.aspx?scid=/servicedesks/fileversion/default.asp?vartarget=msdn
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.
-ralph
Fred
<nt_cons...@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.
Fred.
Peter
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 ;-)
Regards
Peter
"Ralph" <nt_cons...@address.com> schrieb im Newsbeitrag
news:uh89ikS...@TK2MSFTNGP11.phx.gbl...