From: Tom Shelton on 9 Sep 2009 09:30
On 2009-09-09, Eduardo <mm(a)mm.com> wrote:
> Tom Shelton escribi�:
>> On 2009-09-09, Eduardo <mm(a)mm.com> wrote:
>>> Tom Shelton escribi�:
> Then in VB6 we have usercontrols and "components" with the same object,
> the usercontrol. With the property InvisibleAtRuntime the UC can become
> a component.
Well, ultimately, a .NET UC is a component (UserControl descends from
Component - though, there are few base classes in between).
And it's not like a component can't show a user interface, in fact some of the
built in ones do (such as the various dialog controls). Or a UC can't hide
> (based in your explanation, but surely must be other differences)
Differences from what? From VB.CLASSIC UC? Yes, there are lots of
> Can you place one of these "components" instances on a form?
Yes. Just like any other control - you select them in the toolbox and drag
them to the form. The only real difference from the desinger stand point is
that a component will go to the tray area below the form and a uc will show up
directly on the form....
From: Larry Serflaten on 9 Sep 2009 09:51
"Schmidt" <sss(a)online.de> wrote
> 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
Assuming the UC is a compiled ActiveX control, and
several drawing classes are held in a separate DLL,
which project defines the common interface?
As I understand it, one will have to reference the other
to get a hold on the correct interface. I am thinking
it should be in the UC project, does that sound right to
you? Or, would you create and register a separate
interface that they both reference?
From: mayayana on 9 Sep 2009 10:00
You realize you're just giving him a table to
set up his .Net Tupperware party?* He's
talking about something in .Net that apparently
has the same name as something in VB, but isn't
the same thing.
I can volvo in my Volvo. Can you volvo in your volvo? :)
*Tupperware party: For those who don't know,
Tupperware was a brand of overpriced plastic
containers that were sold by agents who would
convince friends to host "parties", invite a number
of housewives, and thereby provide a captive
audience for the agent to sell Tupperware to. Just
as Tom keeps pushing his way into other peoples'
houses to sell his "cutting edge plastic solutions".
From: Tom Shelton on 9 Sep 2009 10:23
On Sep 9, 8:00 am, "mayayana" <mayaXXy...(a)rcXXn.com> wrote:
> You realize you're just giving him a table to
> set up his .Net Tupperware party?* He's
> talking about something in .Net that apparently
> has the same name as something in VB, but isn't
> the same thing.
They are essentially the same thing.
From: Schmidt on 9 Sep 2009 10:59
"Larry Serflaten" <serflaten(a)usinternet.com> schrieb im Newsbeitrag
> "Schmidt" <sss(a)online.de> wrote
> > 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).
> Assuming the UC is a compiled ActiveX control, and
> several drawing classes are held in a separate DLL,
> which project defines the common interface?
> As I understand it, one will have to reference the other
> to get a hold on the correct interface. I am thinking
> it should be in the UC project,
Yep, if the UC-project (the OCX) is the "consumer"
of "Indicator-Plugins", then itself should define the
COM-Interface in a Public Class (e.g. IIndicatorPlugin),
all the satellites (Public Classes) in one or more ActiveX-
Dlls would have to follow (per Implements) and put a
reference to the OCX-library into their Project-Settings.
In case one is hosting one Indicator-implementation per
Dll-File (with only one Class and always the same Class-
Name per Dll), all contained in a App.Path\Plugins\...-Folder,
then the App could list just the current FileNames in a
ComboBox, to let the user choose, which Indicator-Type
would have to be rendered inside the OCX-hosted Usercontrol...
The App is then able to call:
ucChart.AddIndicator cmbIndicatorTypes.Text & ".dll"
Inside ucChart one could instantiate the Public
Class of such a Dll regfree over the passed FileName,
directly against the ucChart-defined IIndicator-Plugin-
interface-Variable - reserve space within the drawing-area
of ucChart - and let the Plugin do its work (rendering
against a passed ucChart-hDC on an appropriate Offset,
or by handling the "Stripes" per ControlArray of
ucStripe-Controls - and passing these hDCs to the Plugins).
> Or, would you create and register a separate
> interface that they both reference?
That could also be done (then even more forcing
a "contract first" approach/thinking).
The Plugins could also talk with each other LateBound
(per "MethodName/Signature-conventions") - if both
sides use small private WrapperClasses, which encapsulate
these LateBound-Calls with nice fitting interfaces, so
that intellisense would be back, but no "external Reference"
would be needed in your Project-Settings.
Aside from that...
I personally don't write OCXes anymore, since they are more
difficult to Load regfree - ActiveX-Dlls work much nicer
in that regard (then with sidewards-docking of drawing-areas as
e.g. PicBoxes or dumb/generic private UserControls, provided by
the hosting-Application-Form at runtime) - but for WebBiz' current
scenario and experience-background it is probably a good
idea, if he gets a grip to UserControls first, which integrate
the visual aspect (a drawing-area with Mouse- and Key-Events) and
the Class/Interface-aspect nicely in "one Place" (a *.ctl-File).