Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Loading an OCX at runtime

Status
Not open for further replies.

robdon

Programmer
May 21, 2001
252
ES
Hi,

Is there any way to load and use an OCX control at runtime?

I would like to load a specified OCX and then dispay it on a form at runtime.

Thanks,

Rob D.

ProIV Resource Centre
 
Well, also, the way to do this is VB specific as well. So, the way to load and run an OCX at runtime is to first set a reference to it in the components menu. Then, you can draw an instance of your control on a form or whatever.

Basically, whatever you can do with, say, a command button in VB, you can do with any control in an OCX file once you have referenced it as in use by your project.

HTH

Bob
 
Hi,

The only problem is I want to specify the OCX as runtime.

At design time I dont know what OCX's can be added to my application.

I want people to select an OCX and I then draw it in my app.

So I need to be able to do everything at runtime...

Thanks,

Rob.

ProIV Resource Centre
 
Havent dont that bit yet, but I presume there is a API or maybe I need to go through the registry to get all registered OCXs.

Just to make it a bit clearer....

I'm writting a editor for a 4GL called ProIV. In Proiv you can create a 'screen' that you can add controls to, including user specified OCXs.

My editor is displaying the ProIV screens in a GUI screen painter, bit like the VB6 design mode.

So, if they specify an OCX, I need to load it up and display it in my screen painter.

Rob.

ProIV Resource Centre
 
Well, if you go through the registry, you're liable to find as many as 10,000 of them, most of which would have little or no meaning in the context you describe. Furthermore, probably there would be licensing issues with a bunch of them.

I suspect that what you're trying to do wouldn't be workable in that way. The way that VB allows you to load controls at runtime is to have an existing instance of the control on the form, and load against that using the Load statement.

As I see it, you need to know the list of controls ahead of time from which the user can select, or you can't get it done. Perhaps someone else can come up with something.

Bob
 
Um, you still need to know which controls you're going to use ahead of time, if you're going to use Controls.Add. You have to create a control array up front of the type of control you're going to add.
 
I'm pretty sure there is no need for control arrays, otherwise there's be no point. perhaps you are thinking of the Load() method? The VB6 documentation suggests otherwise as does How To Dynamically Add Controls to a Form with Visual Basic 6.0

You do still have the control licensing issue to deal with, and both the VB6 docs and that KB article address the topic.

There is no question you need to know what controls you want to add. But I believe there is an API for enumerating the available controls, and even "filtering" the enumeration to weed out those which can't be sited on a VB form. I'm not suggesting this part of the excercise would be trivial though, and I suppose it is possible one might have to scan the registry directly.
 
I stand corrected, my apologies. You don't have to have a control array for Controls.Add, just for the Load statement. (By the way, I don't mean to split hairs here, but the Load statement isn't a method, any more than, say, the Open statement is. There's a class of valid commands in VB that predate the use of dot notation, and the official term for them is statement. Any command that has the syntax "command arglist" rather than "object.method[(]arglist[)]" is of this class.)

I would add to dilettante's comments that if you're going to attempt to site the control, you have to know a good deal about the kind of positioning properties they have, or you'll start throwing errors when you try to position them. My feeling is that if you don't limit the list of controls in some way to a known list (possibly a very large known list), your program will hang on some of the controls selected.

 
Well if it makes anyone feel better I meant "method" as in "approach" myself.

I don't think about the fact that many VB6 "intrinsic functions" are really method calls on objects in the global namespace very often either.
 
No, it doesn't make me feel better. :snif: [sadeyes] Beer might....or maybe even a vacation.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top