User Controls (Active X) - Da Process
in [Visual Basic]
|
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 it's interface... > (based in your explanation, but surely must be other differences) > Differences from what? From VB.CLASSIC UC? Yes, there are lots of differences. > 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.... -- Tom Shelton
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 > 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, does that sound right to you? Or, would you create and register a separate interface that they both reference? LFS
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. -- Tom Shelton
From: Schmidt on 9 Sep 2009 10:59
"Larry Serflaten" <serflaten(a)usinternet.com> schrieb im Newsbeitrag news:eYWe3QVMKHA.4064(a)TK2MSFTNGP06.phx.gbl... > > "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). Olaf |