WHM

Hey Folks!
I have been using VB for quite sometime, but I have never messed with writing ActiveX controls. I have a fairly large Application that runs my retail store, and I have been using a form for common tasks like "Selecting a Customer" for various reasons. The Form uses an SQL statement to produce a recordset based on the text in a text box, and updates a list control with each keystroke. The unique thing about the arrangement is that the text search text is double wild-carded (ie WHERE Cust.CustText Like "*xxx*".... I know, no huge feat, but it is very handy for quickly narrowing a list of a couple of hundred customers.) Anyway, it would be very handy to create a control that had this functionality built into it. I need a bit of help deciding if creating an Active-X control to replace this form is practical. The control would need a label control, a list control, and a textbox control, and some properties that could be set at runtime, ie database path, and a value for Customer Number. Questions I have would include: If I have opened a Global DAO database object in the the container application, can I access its methods in the code in the ActiveX control? I would assume not, does this mean that I need to Open a Database object within the ActiveX control? If so am I creating a control that is too heavy? Currently there are over a dozen forms that call the Select Customer Form, by replacing these calls to a form with a heavy control, am I going forward or backward??

Any thoughts would be great,

Hunter

Thinker

I can't give you a firm yes or no, but maybe answer some of your
questions where you can decide.

When you say "Global DAO database object in the the container
application", I assume you mean module level variables in the form.
Variables at this scope are accessible within your control by using the
UserControl.Extender.Parent object (which is the same as saying Me in
the form.)

This is a mouthful of object, so I would suggest you have a property
(Property Set) in your control which can accept a DAO recordset.
Make sure you check it for = Nothing before letting other functions in
the control work. Once it has been set to a valid recordset, it won't be
= Nothing and the rest of the control is free to function. Make sure in
the Terminate event you set the internal Recordset variable = Nothing
again to release the object reference.

Doing this should allow the control to remain fairly light (as light as the
equivalent form with the same controls.) Placing it on 12 different
forms should only be a little more overhead than the same set of
controls and code placed on 12 different forms.

Some other considerations are: Are the forms hosting this control
resizeable, or do the background attributes of the form change (like
color, font, etc.?) Are there any properties you will need to persist from
design time (when you drop your control on a form?)

Hope this helps you decide, post back if you have other questions.


I think therefore I am... sometimes right. [img]images/icons/wink.gif[/img]

WHM

Thinker,
Thank you for your response. I have not used property pages at all, so I will have to do a bit of brushing up there. When I say a Global DAO Database object I mean that the first declarations in Sub MainMod are:

Public Ws As Workspace
Public Db As Database
Public DbS As Database

The first executable line of code in Sub Main calls a routine that opens the database (Set Db = Ws.OpenDatabase(DbDir)). The database is then accessed in every form for one thing or another. Having said all of that, your suggestion, "UserControl.Extender.Parent " sounds like it will do the trick. I assume that this property does exactly what it says, ie allows the control to access other objects and controls on the parent form. I will check into this, thank you for pointing it out to me. I have been writing code on and off for twenty five years, and working with VB since VB4, and I still find that there is more to know than I do know.
As far as re-sizing, fonts etc, these are not really critical to my app, my app is only used in-house, and I do not spend a lot of time writing code to allow users to change things at run-time. If I need to change font or the size of a control or form, it is simply easier to make the changes and re-compile the source code.
The control in question would eliminate a lot of code, and a similar control to find particular inventory items would also be handy in several different forms. Thank you again for your pointers; I will proceed this week with my first ActiveX project!

Thanks,

Hunter