Hello friends,
I'm developing an ActiveX ocx control.
So, I'm trying to find a way how to get the info if my control (ActiveX) is installed allready on this machine.
Any ideas?
Printable View
Hello friends,
I'm developing an ActiveX ocx control.
So, I'm trying to find a way how to get the info if my control (ActiveX) is installed allready on this machine.
Any ideas?
A simple Controls.Add("InstallTest", "MyControl.ProgID") should do it (wrapped by an Error-handler)
BTW, that's just one of the advantages of regfree deployment (to avoid things like that,
since every App would use their own "local Copy" of the OCX - using the right version,
the consuming Exe was developed against and tested with - so, this way multiple versions
of the same OCX can then be used in parallel, by different Apps).
Did you managed to host your "Dynamic-Form-Engine" in an AX-Dll already?
(since that would ease regfree deployment and siting quite a bit).
Olaf
Normally an installer checks to see if an ActiveX library dependency is already registered (published). So if you are using a proper installer then you have nothing to do.
You might also read through:
How can I tell whether a DLL has been registered?
Quote:
Given that DLL registration can encompass arbitrary operations, there is no general-purpose way of determining whether registration has taken place for an arbitrary DLL.
To determine whether a DLL has been registered, you need to bring in domain-specific knowledge. If you know that a DLL registers a COM object with a particular CLSID, you can check whether that CLSID is indeed registered.
Thank you guys for the tips.
###########################
dilettante:
Thank you. I'm having a specific situaltion. I'm creating a usercontrol that extends Microsoft Excel with new Userform control.
The idea is to give the Microsoft Excel users the possibility to easy, fast and error free create data entry forms that is having a ton of new features versus the built-in data entry form in Excel. Something like the Access is having but not so complicated.
The users can freely redistribute and share the workbooks that they have create to others, and here is the catch. If the new user doesn't have the usercontrol, the Excel will crash or the new user will not be able to use the workbook.
To be able to freely redistribute "runtime" to everyone, the project will be financed with the commercialy available Designer used to design new, or edit this Virtual Forms.
Your referece that the installer needs to handle this has give me the second way to test the presence of the control. My setup (NSIS) creates some registry entries that are also removed when the app is uninstalled, so beside the solution presented by Olaf there is also this solution.
Thanx dilettante!
###########################
Olaf:
Thanks for the tips, the Add sounds great, the regfree sounds even better.
Ohhhhhhhhhhhhhh, I'm surprised!!!
You remember me with my problem (challenge) :-)
No, I didn't managed to resolve my 64-bit problem. :-(
I tried to understand, but don't know where to start.
The problem are that the usercontrol is having visual interface that acts like Main menu treeview, the control is having some custom propreties, methods, objects and events.
Some events also returns the result back to control.
My plan, or I thought, that I go with the 32 bit version commercialy, and then when I get some founds to beg you guys to help me with the 64-bit version. I can't expect, or ask, you for help if I don't have the financial compensation method worked out.
The project is interesting to users, the facebook page without advertising and with few posts is having 1800+ funs and growing daily. There are hundreds of users downloading and playing (testing) the project, despite the fact that I have not yet written documentation.
And the project is only few months in the public space. (Don't ask me how many years I worked on it. :-) )
But 80% of them grumble about the lack of 64-bit version. Without that they can't create the apps for their users to distribute to them, because they can't insist on only 32-bit version of the Office. (The vb6 user base is still small, but growing :-) )
Some of them are saying that it is still a little complicated to use, but this is doable with time and optimization of the Designer application.
I don't have any more time, I have to release commercial version, or there will be no version at all.
I hope that with the 32-bit version I will soon get some results, so that I can build a team and to be able to hire you guys for these difficult challenges.
Oh, for everyone else who don't know about what we are talking about, we are talking about my latest project Virtual Forms for Excel. Take a peek here: http://virtual-forms.com
The question is:
which came first?
chicken or the egg
team or money
I still don't understand why something like that has to come in an OCX.
Maybe we should clear this up first (before we talk about regfree mode and 64Bit-mode,
which both would be a lot easier when you just switch your Project-Type to 'ActiveX-Dll').
You mentioned a kind of "EntryPoint-Control" (which offers several "Design-choices" in a kind of Menu).
Let's say (for ease of communication) that this Menu-Entry-Control of your Framework
is called DesignerMenu.ctl, sitting as a Public Control in your OCX-Project.
So, is there any real reason that speaks against "converting that DesignerMenu.ctl" into a
DesignerMenu.frm (containing the very same Controls, throwing the very same Events,
then shown (from within e.g. Excel-VBA) as a PopUp-Form like:
Copying what's placed (with regards to SubControls) on your DesignerMenu.ctlCode:Private WithEvents oDesignerMenuPopup As cDesignerMenuPopUp '<- this being just a small Public "Starter-Class"
'... then triggered from somewhere (e.g. from an Excel-AddinMenu-Entry or an Excel-Addin-Button
Set oDesignerMenuPopup = New cDesignerMenuPopUp
oDesignerMenuPopup.SomeProperty1 = SomeUserSettings
oDesignerMenuPopup.SomeProperty2 = SomeUserSettings
oDesignerMenuPopup.SomeProperty3 = SomeUserSettings
oDesignerMenuPopup.ShowModal
onto a Project-Private DesignerMenu.frm takes about 2 minutes - another 10
minutes might be needed, to replace all the UserControl-internal EventHandlers
to Form-internal EventHandlers by replacing the String "UserControl_" with "Form_"
inside the DesignerMenu.frm Code-Module.
Best thing about that is, that you can test the whole conversion-attempt already
directly within your UserControl-Project (reserving the final switch to a Dll-Project
until everything works out well) - meaning that you can include the new
DesignerMenu.frm in parallel to your existing DesignerMenu.ctl in that test-phase.
Olaf
also is there any issue just moving right to an ActiveX EXE, that can be used in both 32bit and 64bit office?
For the record, Industry standard is to use 32bit office. (because of the many drivers and plugins that are not available 64bit)
I remember Originally 64bit office was only available as a download - not even available on the install Media/DVD.
64bit office is quite pointless. Who actually edits 5Gig spreadsheets?
It gets even more complicated with the latest access runtime (ACE) where you can only have either 64bit _or_ 32bit installed - not both. *shakes head*
Wow Olaf,
this sounds very, very interesting.
:)
No, for the moment, nothing comes to my mind why this would not be possible.
I will post here how it goes.
This really gives hope!
Olaf
I'm talking about you with my facebook folowers
:-)
https://www.facebook.com/exceluserfo...54268191397597
I must first publish a commercial version of this application as it is currently, to do that I need to record a commercial video with tutorial and my voice first, put the store online, create price list, a little documentation writing, and then I will devote all my time to your instructions.
I must first see the interest, whether there is a commercial aspect for this project, so that we can move to the next step. And the next step is ???????????????
Yes, thats right, :) , 64-bit version and the regfree with a lot of help from Olaf Schmidt and the community right here on vbforums.com
I'm so happy that there is a hope and a big potential for this project
:)
apart from all the above,
as you are only working in excel you can add references at run time, so you do not need to have a missing reference and should be able to determine if it exist, by trying to add it, you would then also have to add your usercontrol at runtime
if not existing a simple message to obtain the usercontrol from.......
I'd rather when we'd leave all this non-technical stuff out of the discussions on this forum,Quote:
Originally Posted by Davor Geci
since I consider places like this - well, a kind of "refuge" (where we can just be the nerds we are underneath,
not having to maintain the "business-facade", which is part of our jobs far too often)...
I don't really understand that, since the deployment-format (OCX or Dll - or even the complete encapsulation withinQuote:
Originally Posted by Davor Geci
an ActiveX-Exe as Dex was suggesting) can have a quite large influence on the success of of a COM-based solution.
Switching the OCX-project over to a Dll-Project would be the easiest (and fastest in 32Bit-mode) one to accomplish -
(with code-changes in only a dozen lines - and perhaps "100 new written ones" for a new Excel-Interface-Class - and that's it).
Your main-codebase (what all those dynamic Forms do inside the compiled Binary) will not have to be touched -
or re-tested, it's really just the relative small "interfacing-part with Excel or other COMponent-consumers" which
has to be changed slightly, to work "in Dll-Mode".
What I'm trying to say is, that it's "just a days work" - and a real worthwhile one IMO - because what you don't want is,
(e.g. having shipped the whole thing as an OCX and with a "UserControl" as the Interface), to force your then *already existing*
customers to a rewrite of their Interfacing- and Startup-Sequences, in case you ship it one year later as a Dll.
To correct your comment above...Quote:
Originally Posted by Davor Geci
There will be no real "64-bit-version" or something like that...
Your (still VB6-compiled) Dll will always be a 32Bit one, this way usable directly *InProcess* from within Excel-32Bit
without any performance-loss (but allowing easier regfree instancing than your former OCX).
As for 64Bit - what can be done (for Users who have only the 64Bit-version of Excel installed) -
is a (relatively well, but somewhat slower working, because then running OutOfProcess) workaround,
which will use an additional *Process* (the ActiveX-Exe which was set to "Thread per Object"-mode at compile-time),
to offer up the Interface-Classes of your 32Bit-Dll over InterProcess-COM-Marshalling to the Excel-64Bit-consumers.
And it's just a single line of VB6-code you need (in an ActiveX-Exe) to accomplish that.
(This single line being an instancing Call like CreateObject - or in case of regfree-mode -
the GetInstance-call as it is contained in DirectCOM.dll)
So that's also "nothing to talk about really" (code-wise), also doable in "just one day" before you
ship your first version.
For better understanding - here's two textbased "encapsulation-diagrams" for you (note the bracket-placements):
32Bit-InProcess-mode after loading your Dll directly (either from a registered version or regfree):
[ 32Bit-Excel-Process <-Class-interfaces are accessed directly-> [32Bit-Dll-Binary] ]
64Bit-OutOfProcess-mode after loading your Dll over an ActiveX-Exe:
[ 64Bit-Excel-Process [thin, autocreated 64Bit Interface-Proxies] ] <-Class-interfaces are marshalled-OutOfProcess> [Active-X-Exe [32Bit-Dll-Binary] ]
Olaf
You are right,
so I'm moving from the usercontrol to private form all the interface staff, and the public events, properties and methods to a public class.
Also the version compatibility I need to start from beginning and persist with binary compatibility.
In Project Group Change the project name from VirtualForm_control, to something like VirtualFormDLL (we will have also the ActiveX exe project later)?
Yep - and over a Public Method of your Public Class you can start the internal (PopUp-)Form modallyQuote:
Originally Posted by Davor Geci
and from inside that Private Form you can then re-delegate the Events from the Forms internal Controls
over into the Public-Class, which then "re-raises" these Events to the outside world.
That's not really much "new coding" - only a re-arrangement of already existing Code-Blocks per Copy&Paste
(from your former Public UserControl to the new combination of "Private Form and Public Class")
The ActiveX-Exe is the least amount of work, because you can write it once in a generic fashion,Quote:
Originally Posted by Davor Geci
then compile it, switch on its Binary-Compatibility - and it will work with *any* 32Bit-ActiveX.dll for years.
E.g. in an ActiveX-Exe Project, named AXClassStarter, having a single Public Class cCOM32
(with the setting "Thread per Object"):
The entire Code in cCOM32 would be:
And that's it already - now compile the thing, set Binary-Compatibility on it -Code:Public Function CreateInstance(ProgID As String) As Object
Set CreateInstance = CreateObject(ProgID)
End Function
'maybe accompanied by:
Public Function CreateInstanceRegFree(FullPathToDll As String, ClassName As String) As Object
Set CreateInstanceRegFree = GetInstance(FullPathToDll, ClassName) '<- e.g. when using DirectCOM.dll for regfree instancing
End Function
and check it out with e.g. VBA from inside an Excel-64Bit instance:
The Methods and Properties of MyObj32 will be callable from inside the 64Bit Excel-Process now.Code:Set MyObj32 = CreateObject("AXClassStarter.cCOM32").CreateInstance("SomeLib.SomeClass")
Olaf
Yes,
Olaf it works!!!
Took some time to create it, but it works.
You are saying that the Methods and Properties of MyObj32 are callable from inside the 64Bit Process.
Is there a way to also pass and receive the events from<>to dll (via ActiveX EXE AXClassStarter) and the 64-bit?