User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Karl E. Peterson on 9 Sep 2009 15:03 Tom Shelton wrote: >> Is only good practice to set properties at design time if the object is >> visible on the screen? Why? > > No. Not at all. I was refering to the use of UC's for non-graphical > components. In .NET that's not really good practice. I'd have to suggest that's just an unnecessary and incendiary qualifier there. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Larry Serflaten on 9 Sep 2009 18:39 "Webbiz" <nospam(a)forme.thanks.com> wrote > That's the current 'vision' I have on this. What'cha think? Its possible. But you'd have all the code to manage the space and draw the inages in one control, possibly making it a bit 'expensive' to keep adding several to a form. Here's another idea for the pool: What if you separate out the Chart type from the Indicator type? You'd make a Chart control that draws the main chart and can contain other controls. You'd then create a second Indicator control that sits on a Chart control. The Chart control would hold the data, and manage placement of any contained Indicator controls, while the Indicator control would have all the drawing code for the different indicators. In that method they could be used seperately (in case you just want to show the chart, or just an indicator) or in tandem to fulfill the original design. Just another thought for the idea pool.... LFS
From: Eduardo on 9 Sep 2009 18:56 Karl E. Peterson escribi�: >> Another difference is that you have a reference to the form without >> having to set it to a property. > > Sort of, yeah. You can't sink events from the parent without setting up a > circlejerk, right? I don't know what you mean here. It's quite easy to have the form's events with a couple of lines of code. Anyway sometimes you don't need the events, but just the Controls collection or the hWnd. >> Another one is that you have a design mode where you can set properties, >> and also have property pages. > > I tend to not view that in a very positive light anymore. I like explicitness > everywhere now. I don't generally set very many visible control (or form) > properties at design-time, either. It just reduces my ability to reuse/recycle the > effort. > >> I think that invisible UCs are useful. > > But not for much. <g> But it is about *you*, that you are a programmer extremely experienced and exacting. VB is also for people that want to make programs easily. Anyways there are controls, like the ImageList for instance, that you *need* to set up at design time if you want to avoid loading lot of files at runtime. You could store the files as resources and avoid using the ImageList at all, but the ImageList is easier.
From: Karl E. Peterson on 9 Sep 2009 22:45 Eduardo wrote: > Karl E. Peterson escribi�: > >>> Another difference is that you have a reference to the form without >>> having to set it to a property. >> >> Sort of, yeah. You can't sink events from the parent without setting up a >> circlejerk, right? > > I don't know what you mean here. It's quite easy to have the form's > events with a couple of lines of code. By passing a reference, right? > Anyway sometimes you don't need the events, but just the Controls > collection or the hWnd. Right. I thought the OP was the same one who wanted to provide "notifications" to the UC, so that's why I brought it up. >>> Another one is that you have a design mode where you can set properties, >>> and also have property pages. >> >> I tend to not view that in a very positive light anymore. I like explicitness >> everywhere now. I don't generally set very many visible control (or form) >> properties at design-time, either. It just reduces my ability to reuse/recycle >> the effort. >> >>> I think that invisible UCs are useful. >> >> But not for much. <g> > > But it is about *you*, that you are a programmer extremely experienced > and exacting. VB is also for people that want to make programs easily. Heh, do I sound totally like an Olde Fart if I say that sometimes the "easy path" isn't? <g> > Anyways there are controls, like the ImageList for instance, that you > *need* to set up at design time if you want to avoid loading lot of > files at runtime. But that one's just accomodating other control/language shortcomings, eh? > You could store the files as resources and avoid using the ImageList at > all, but the ImageList is easier. Yeah, I guess I've gone both ways, though rarely. I tend to shy away from tree and listviews. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Webbiz on 9 Sep 2009 22:52
On Wed, 9 Sep 2009 17:39:15 -0500, "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > >"Webbiz" <nospam(a)forme.thanks.com> wrote > >> That's the current 'vision' I have on this. What'cha think? > >Its possible. But you'd have all the code to manage the space >and draw the inages in one control, possibly making it a bit >'expensive' to keep adding several to a form. > >Here's another idea for the pool: > >What if you separate out the Chart type from the Indicator type? >You'd make a Chart control that draws the main chart and can >contain other controls. You'd then create a second Indicator >control that sits on a Chart control. > >The Chart control would hold the data, and manage placement >of any contained Indicator controls, while the Indicator control >would have all the drawing code for the different indicators. > >In that method they could be used seperately (in case you just want >to show the chart, or just an indicator) or in tandem to fulfill the >original design. > >Just another thought for the idea pool.... > >LFS > > That sounds like a good idea. I'm wondering though if this will cause me the same amount of discomfort that I'm currently getting with my chart. Currently my project uses a picturebox that fills the whole form. That's the chart. The indicators are drawn on this picbox also, but dividing up the space and trying to keep track of the top/bottom of each. I've not even attempted to make those indicators resizable by click-n-drag yet. Perhaps plopping controls onto the chart control will be easier. I might give it a try. Thanks. Webbiz |