What is the resources cost of embedding -constituent- controls in an OCX.?

[OLD JOHN]

I have written an OCX (in VB5-SP3 and using Win-API calls) that provides for
a type-ahead feature the assists the user in making selections from the
combobox with the keyboard. (VB5 and Win95 are the platforms -- I cannot
change that).

The control contains a standard combobox as the constituent control and
subclasses the keystroke and got/lost-focus messages using Win-API calls
and
windows messaging. All is right with the behavior, speed (user cannot
foul-up the key-stroke events).

However, some criticism is coming that the control is "thick" on resources.
This leads me to a defensive position and I seek assistance in resolving
that the control is doing a "pro"-job and that the resources are just part
of what comes with the enhanced functionality and behavior.

My statistics show that using the custom OCX uses 2% more system resources
than the standard combobox when deploying 30-such controls on a form.
15-controls is 1% more usage than 15-comboboxes.
No difference whether the 30-such controls are from a control array or
30-single controls.

My questions are:
1) Does this seem like a detrimental amount of resource cost for
30-controls? (no form in the application contains more than 15 controls).
2) Is using a constituent control inside an OCX cost extra resources?
3) If we sub-classed the behavior in a 'subclassing' class and route the
events to the class, would that be more resource-friendly?
4) If doing item (3) in a DLL, would that consume more/less resources than
using OCX?
5) If doing item (3) in an in-project class-module, would that consume
more/less resources than using OCX?
6) What steps can I use to reduce resources? (one idea was to "paint" the
user-control object so it would look just like a combobox (no constituent
control) and manage the keystrokes and mouse-behavior. Is this a good
idea?)

Your constructive and knowledgeable comments will be greatly appreciated.
--

Best regards,
Old John

[Mark Alexander Bertenshaw]

John -

"OLD JOHN" <jdid01@netzero.net> wrote in message
news:38f25d5b$1@news.devx.com...
>
> My questions are:
> 1) Does this seem like a detrimental amount of resource cost for
> 30-controls? (no form in the application contains more than 15 controls).

No way!! I have seen <much> worse situations that this (100%+ more
resources). This is a drop in the ocean.

> 2) Is using a constituent control inside an OCX cost extra resources?

Yes. For a start, you are using an extra hWnd, and you can't do anything
about that unless you make the combo windowless (in VB6), and the
UserControl windowless.

> 3) If we sub-classed the behavior in a 'subclassing' class and route the
> events to the class, would that be more resource-friendly?

Are you talking about Windows subclassing, or just a wrapper class?

> 4) If doing item (3) in a DLL, would that consume more/less resources than
> using OCX?

DLLs have less of an overhead.

> 5) If doing item (3) in an in-project class-module, would that consume
> more/less resources than using OCX?

Marginally less, at a guess.

> 6) What steps can I use to reduce resources? (one idea was to "paint" the
> user-control object so it would look just like a combobox (no constituent
> control) and manage the keystrokes and mouse-behavior. Is this a good
> idea?)

As I said above, try making them windowless.

>
> Your constructive and knowledgeable comments will be greatly appreciated.
> --
>
> Best regards,
> Old John
>
>
>

--

---------------------------------------
Mark Alexander Bertenshaw
Programmer/Analyst
Prime Response
Brentford
UK

[Mike]

>> 6) What steps can I use to reduce resources? (one idea was to "paint"
the
>> user-control object so it would look just like a combobox (no constituent
>> control) and manage the keystrokes and mouse-behavior. Is this a good
>> idea?)

John,

I have done this myself. It was a HUGE task - I had no idea of the size of
it when I started. I had to write a ComboBox,ScrollBar,ListBox and SubClass
control. I would not recommend it just to save resources.

As mark said, you could make it windowless. Just to explain this further,
there are windowless versions of the standard controls on the VB6 CD. Use
these instead and set your controls WindowLess property to true. You will
not be able to subclass, but you may not need to.

Mike



"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote:
>John -
>
>"OLD JOHN" <jdid01@netzero.net> wrote in message
>news:38f25d5b$1@news.devx.com...
>>
>> My questions are:
>> 1) Does this seem like a detrimental amount of resource cost for
>> 30-controls? (no form in the application contains more than 15 controls).
>
>No way!! I have seen <much> worse situations that this (100%+ more
>resources). This is a drop in the ocean.
>
>> 2) Is using a constituent control inside an OCX cost extra resources?
>
>Yes. For a start, you are using an extra hWnd, and you can't do anything
>about that unless you make the combo windowless (in VB6), and the
>UserControl windowless.
>
>> 3) If we sub-classed the behavior in a 'subclassing' class and route the
>> events to the class, would that be more resource-friendly?
>
>Are you talking about Windows subclassing, or just a wrapper class?
>
>> 4) If doing item (3) in a DLL, would that consume more/less resources
than
>> using OCX?
>
>DLLs have less of an overhead.
>
>> 5) If doing item (3) in an in-project class-module, would that consume
>> more/less resources than using OCX?
>
>Marginally less, at a guess.
>
>> 6) What steps can I use to reduce resources? (one idea was to "paint"
the
>> user-control object so it would look just like a combobox (no constituent
>> control) and manage the keystrokes and mouse-behavior. Is this a good
>> idea?)
>
>As I said above, try making them windowless.
>
>>
>> Your constructive and knowledgeable comments will be greatly appreciated.
>> --
>>
>> Best regards,
>> Old John
>>
>>
>>
>
>--
>
>---------------------------------------
>Mark Alexander Bertenshaw
>Programmer/Analyst
>Prime Response
>Brentford
>UK
>
>

[Old John]

Thank you for your reply.
Please help me with this exchange...

"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote:
>John -
>
>> 3) If we sub-classed the behavior in a 'subclassing' class and route the
>> events to the class, would that be more resource-friendly?
>
>Are you talking about Windows subclassing, or just a wrapper class?

In a wrapper-class that includes windows api-subclassing on the Edit-hWnd
and also on the Combo-hWnd. The windows api-subclassing is to trap the WM_CHAR,
GOT/LOST-focus and a few things like that to enable the combobox in VB5 to
act as a type-ahead/autoselect box (as I understand is in VB6 --our shop
cannot change to VB6 until the 'correct' time).

Along the lines of resources -- If we have a control passed through a wrapper-class
instance and then we have dozens on a form and dozens of forms (this can
come to many dozens of instances of a class) -- are there many dozens of
copies of the code for each of the instances? Doesn't that take up resources?
It appears that placing constituent controls in a 'enhanced' active-X control
also creates many dozens of instances in memory. So what is the big difference
in resources -- simply because there is a <combobox>-constituent and then
another one that is shown on the form (i.e: one combobox window and then
one usercontrol window)? Maybe that is not a lot.

Your responses will be greatly appreciated, and thanks...

Regards...Old John

[Mike]

Old John,

Duplicating classed does not duplicate the code, only the data. It is the
same with an active X control. But with an activeX control, you have the
added overhead of the extra window, plus other overheads also I'm sure. But,
the overheads would probably be acceptable either way. There are plenty of
apps around that wrap the standard controls using either method.

Is VB5 missing the withevents keyword? If so, instead of subclassing the
control, you could write code to pass the events into your class. This is
not quite as encapsulated, but ALOT easier and safer. Also, subclassing every
control on every form would use resources.

In my opinion, I think that it is not that much of an issue. Just use the
Custom Controls, it will be plenty quick enough.

Mike





"Old John" <jdid02@netzero.net> wrote:
>
>
>Thank you for your reply.
>Please help me with this exchange...
>
>"Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote:
>>John -
>>
>>> 3) If we sub-classed the behavior in a 'subclassing' class and route
the
>>> events to the class, would that be more resource-friendly?
>>
>>Are you talking about Windows subclassing, or just a wrapper class?
>
>In a wrapper-class that includes windows api-subclassing on the Edit-hWnd
>and also on the Combo-hWnd. The windows api-subclassing is to trap the
WM_CHAR,
>GOT/LOST-focus and a few things like that to enable the combobox in VB5
to
>act as a type-ahead/autoselect box (as I understand is in VB6 --our shop
>cannot change to VB6 until the 'correct' time).
>
>Along the lines of resources -- If we have a control passed through a wrapper-class
>instance and then we have dozens on a form and dozens of forms (this can
>come to many dozens of instances of a class) -- are there many dozens of
>copies of the code for each of the instances? Doesn't that take up resources?
>It appears that placing constituent controls in a 'enhanced' active-X control
>also creates many dozens of instances in memory. So what is the big difference
>in resources -- simply because there is a <combobox>-constituent and then
>another one that is shown on the form (i.e: one combobox window and then
>one usercontrol window)? Maybe that is not a lot.
>
>Your responses will be greatly appreciated, and thanks...
>
>Regards...Old John
>
>