Re: User Controls (Active X) - Da Process


"Webbiz" <nospam@xxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:jcjea59l6vapq76ct8fk3dpnsrpem8u2dr@xxxxxxxxxx

I'm going to have to play with ActiveX project before I fully
understand what it means to 'share' using a module in the
ActiveX control itself.
It's about binary encapsulation - the different VB6-Project-
Types will create different, freestanding Binaries finally.
And a public Var in a *.bas is visible throughout the whole
binary (the whole Files... as e.g. *.ctl, *.cls, *.frm in
*that* specific project).

So, Binaries (*.exe, *.dll, *.ocx) are isolated - now, how do
they talk with each other...
Over COM-mechanisms --> Class-Interfaces of *Public*
Classes (and a Usercontrols *.ctl-File represents a
Class too).

Since I mentioned, that you can communicate "cross-
Binary" only over Public Classes, it becomes clear, that
VB6 Std-Exes are "passive" in their functionality, since they
may not contain Public Classes (represented in *.ctl and
*.cls-Files) - only Private Classes are allowed - so they
are only "consumers" of Public Classes (Class- or COM-
Interfaces), defined in other Binaries (ActiveX-Dlls or -OCXes).
That's usually not a problem, since Std-Exes are normally
the "End-Point", where everything is glued together, they
don't need to be "active parts", consumable by other Binaries
themselfes (if you need that, this is the usecase for ActiveX-
Exes, which may/must contain Public Classes/Interfaces).

Regarding your problem...
Your Usercontrol(-Class) (if you place it in a separate
OCX-Project) offers both - a Public Class-Interface
(defined in its *.ctl-File) and a visual (container-)representation
in the consuming Binary (the Form in your Exe).

Now the visual area, which your Control does consume
on your hosting Form needs to be dynamically resizable,
depending on the count of additional "indicator-stripes",
but that does not mean, that you need to include more
than one Control on your Form - you can handle the
additionally drawn "stripes" in the "mother-control"
yourself - and just resize that Parent-Control appropriately.
A stripe could be encapsulated (since it is a "visual Part"
too) in an additional *Private* *.ctl within your Main-
OCX-project.

VB6-ProjectGroup

Std-Exe-Project
Form, consuming ucChart-Ctl (OCX)

OCX-Project
ucChart (the public Mother-Control)
ucStripe (the private "Indicator-Sub-Ctls")
IIndicatorInterface
cIndicatorImplementation1
cIndicatorImplementation2
...

That's basically the rough layout in terms of
"File-Modules".
Try to isolate especially the interface between
Form and ucChart in a way, that it is as small
as possible - the Form should not need to know
that much about the internal workings within
the OCX-project - it should pass Data, tell
the needed Stripe-Type that needs to be shown in
addition and maybe receive some Events from
your OCX-hosted Control - not more.

Everything else (additional Child-Classes, to handle
different Stripe-Types - OCX-global *.bas modules)
should be hidden and placed within the Chart-OCX-
Project.

If you need more flexibility especially with your different
indicator-stripes, then you should reduce the private
Sub-Ctl ucStripe to a more or less dumb "drawing-box",
hosted as a Ctl-Array within ucChart - the concrete
drawing-code-implementation could go into another
separated Binary, an ActiveX-Dll, only responsable to
handle the different Indicator-Drawings as a kind of
plugin (talking with the OCX-project over a defined
Interface).

What helps in such cases is, if you concentrate on the
"component-design" first, not that much on the concrete
implementation.
Define a small TestProject-Group with fresh project-
types first, which only draws a Sin-Wave for example
inside ucChart - and very basic "indicator-stuff" in one
or two "stripe-types" - just try to put the interaction
together in the first step - then enhance the interfaces
to your real needs - and after these interfaces are
defined, try to fill-up the structure with your real
implementation in the last step.

You could post "Step-1" (your ProjectGroup-layout
with a very, very basic drawing-implementation) as a link
into the group, so that others can take a look at and
maybe "reorder" and restructure a bit.
Post real code - then there's a better understanding
for all others, where you want to end up finally.

Olaf






.

Relevant Pages

  • Re: Getting small vb app to load as directx "plugin"?
    ... DS at the filter level does NOT want to be written in VB. ... level of control is not there and some interfaces are not automation ... Plop the ActiveX on the Dialog of the Property page. ...
    (microsoft.public.win32.programmer.directx.audio)
  • Re: .NET and ActiveX
    ... > additional interfaces can be viewed as optional and, as such, a container ... > specifying additional interfaces that a control must support, ... control the same way you deploy an ActiveX control. ...
    (microsoft.public.dotnet.framework)
  • Re: Getting small vb app to load as directx "plugin"?
    ... DS at the filter level does NOT want to be written in VB. ... > The level of control is not there and some interfaces are not ... Plop the ActiveX on the Dialog of the Property page. ...
    (microsoft.public.win32.programmer.directx.audio)
  • Re: .NET and ActiveX
    ... Introduction to ActiveX: "An ActiveX control is essentially ... additional interfaces can be viewed as optional and, as such, a container ... specifying additional interfaces that a control must support, ...
    (microsoft.public.dotnet.framework)
  • Re: Visual C++ wont autcomplete?
    ... is not the control position on a dialog a "property"? ... But in VS6, the properties were organized by IMPORTANCE ... and two decades of UI design and books on good UI ... and over again that modality in user interfaces was completely wrong, ...
    (microsoft.public.vc.mfc)
Loading