User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Eduardo on 10 Sep 2009 06:41 Karl E. Peterson escribi�: > 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? You already have the reference, it's in the Parent property. > >> 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> No. I read about the idea the first time in the McKinney's book "Hardcore Visual Basic 5". I don't know who was the first to come with the idea, but it's not new to me. It's an opinion, but as I don't agree with it, now I'm taking the oportunity to discuss it with someone very qualified (you). So if I'm wrong, I want to see why. I remember that McKinney wrote that the Timer control shouldn't be a control, and that invisible controls shouldn't exists at all (or more or less that was the idea). Besides the advantages I already mentioned (parent reference, design time property settings), I can mention another one: Going to the default event's code with just a double click. You double click in a Timer and you already are in place to write your code in the Timer event. That's nice. > >> 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? a) Do you mean that every control that will need a list of images should have built in capability to store the images? Even so, there are situations where you could need a list of images for other reasons, and not for just one control. For example, there could be a picturebox where it's displayed an image according to what the user select on a list or a combobox. b) ...or that the resource management should be much better and easier? I agree with this one. OK, I mentioned at least three things why I think that the invisible at runtime controls are justified (in my opinion), but what are the real drawbacks of having invisible controls? > >> 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.
From: Ralph on 10 Sep 2009 11:15 "Eduardo" <mm(a)mm.com> wrote in message news:h8al57$jpq$1(a)aioe.org... > > I remember that McKinney wrote that the Timer control shouldn't be a > control, and that invisible controls shouldn't exists at all (or more or > less that was the idea). > > Besides the advantages I already mentioned (parent reference, design > time property settings), I can mention another one: > > Going to the default event's code with just a double click. > You double click in a Timer and you already are in place to write your > code in the Timer event. That's nice. > This latter feature while useful, can be achieve with much the same effect through the VBEditor's Object and Procedures dropdowns for any component that publishes events. Simply put: The advantages of an invisible ActiveX Control is that it is an ActiveX Control. The disadvantages of an invisible ActiveX Control is that it is an ActiveX Control. ActiveX Controls are 'widgets'. All good widgets have two useful features (as you mentioned) besides their run-time capbilities: They are self-aware of their container and they provide a design-time interface. The latter feature is the main reason they exist at all. The ability to provide a property page (within the designer or with a separate dialog), along with a help file or additional instructions was a good idea back in the time - consider the original target audience of the VB development package. As programmers advance, and as ActiveX (non-UI) components became more common, programmers tended to eschew design-time properties, became quite prepared to 'initiate' the components properly in code, and were willing to view an external help/reference. At that point the over-head of providing an ActiveX Control becomes far less useful, which is what McKinney was pointing out. To be boorish for a moment, at one time invisible controls and what I liked to called semi-visible controls (business wrapped common controls) were extremely useful. At that time all Windows programming was done in C. And wh ile there were some excellent 'Form/Dialog' editors available they still required a certain mastery of C and came with an expensive per seat price tag. We also used an awkward though typical design cycle - of Requirements->Programmer->Stake Holder->Business User->Stake Holder->New Requirements->Programmer - rinse and repeat. With the introduction of VB we discovered that we could put the design elements directly in the hands of the Business User, and occupy the C programmers with producing controls for their consumption. Providing them with a toolbox of widgets they could simply plop down where needed with instructions and simplified (and controlled) interface, worked very well, and shaved weeks if not months off delivery time. (Those times are long gone. The average programmer today would probably be insulted. <grin>) -ralph
From: Eduardo on 10 Sep 2009 12:32 Ralph escribi�: > "Eduardo" <mm(a)mm.com> wrote in message news:h8al57$jpq$1(a)aioe.org... >> I remember that McKinney wrote that the Timer control shouldn't be a >> control, and that invisible controls shouldn't exists at all (or more or >> less that was the idea). >> >> Besides the advantages I already mentioned (parent reference, design >> time property settings), I can mention another one: >> >> Going to the default event's code with just a double click. >> You double click in a Timer and you already are in place to write your >> code in the Timer event. That's nice. >> > > This latter feature while useful, can be achieve with much the same effect > through the VBEditor's Object and Procedures dropdowns for any component > that publishes events. I didn't mention that because everybody knows that. But of course you still can go there, but taking a path much longer. Compare how much time takes to drop a timer in a form, set the interval to 1000, double click on the timer's box, and write Msgbox "testing". Now also measure the time that it takes to achieve the same: a) Right click on the form, click "View Code". b) In the declaration section write Private WithEvents mTimer as New cTimer c) Go to the Objects dropdown and select the Form, then in the Form_Load write: mTimer.Interval = 1000 d) Go to the Objects dropdown and select mTimer, then write Msgbox "testing". It will take you about 10 times the time that it would take to do the same with the Timer placed on the form as invisible object. That's my point. I didn't say it was impossible. What I'm saying is that the way it's in VB, is handy. > > Simply put: The advantages of an invisible ActiveX Control is that it is an > ActiveX Control. The disadvantages of an invisible ActiveX Control is that > it is an ActiveX Control. May be I'm wrong, but I believe that the Timer is not an ActiveX control. I was taking about invisible at runtime controls in general. > > ActiveX Controls are 'widgets'. All good widgets have two useful features > (as you mentioned) besides their run-time capbilities: They are self-aware > of their container and they provide a design-time interface. The latter > feature is the main reason they exist at all. The ability to provide a > property page (within the designer or with a separate dialog), along with a > help file or additional instructions was a good idea back in the time - > consider the original target audience of the VB development package. > > As programmers advance, and as ActiveX (non-UI) components became more > common, programmers tended to eschew design-time properties, became quite > prepared to 'initiate' the components properly in code, and were willing to > view an external help/reference. At that point the over-head of providing an > ActiveX Control becomes far less useful, which is what McKinney was pointing > out. OK, then it depends on the programmer expertise and stringency, depending on how much advanced she/he is and how she/he wants to work. But's it's not the case of everybody. I think that the most of the programmers prefer to double click on the timer and start writing. .... including me. I don't consider myself a beginner in VB, but I'm quite pratical. Karl and you (and McKinney) are more experienced programmers, so I respect your opinions very much, but I still don't get the point why I should change my mind and think that invisible control shouldn't exist. > > To be boorish for a moment, at one time invisible controls and what I liked > to called semi-visible controls (business wrapped common controls) were > extremely useful. At that time all Windows programming was done in C. And wh > ile there were some excellent 'Form/Dialog' editors available they still > required a certain mastery of C and came with an expensive per seat price > tag. We also used an awkward though typical design cycle - of > Requirements->Programmer->Stake Holder->Business User->Stake Holder->New > Requirements->Programmer - rinse and repeat. > With the introduction of VB we discovered that we could put the design > elements directly in the hands of the Business User, and occupy the C > programmers with producing controls for their consumption. Providing them > with a toolbox of widgets they could simply plop down where needed with > instructions and simplified (and controlled) interface, worked very well, > and shaved weeks if not months off delivery time. (Those times are long > gone. The average programmer today would probably be insulted. <grin>) I don't get it... so you want to go back and have to write everything by code again?
From: Ralph on 10 Sep 2009 14:32 "Eduardo" <mm(a)mm.com> wrote in message news:h8b9mt$esa$1(a)aioe.org... > > > > May be I'm wrong, but I believe that the Timer is not an ActiveX control. > > I was taking about invisible at runtime controls in general. > It is an 'invisible' ActiveX Control. It, MAPI, WinSock, Common Dialog, and Resize, are all common examples of the breed. <snipped> > > I don't get it... so you want to go back and have to write everything by > code again? Sorry for the misunderstanding. I thought I summed it up with the following statement which I meant for you and Karl. > > Simply put: The advantages of an invisible ActiveX Control is that it is an > > ActiveX Control. The disadvantages of an invisible ActiveX Control is that > > it is an ActiveX Control. Perhaps I should have added: .... so if you want the advantages of an ActiveX Control use an invisible ActiveX Control. If you want to avoid the disadvantages of an invisible ActiveX Control then use an 'regular' ActiveX component instead. Or to put it another way. An invisible ActiveX Control is nothing more than a 'regular' ActiveX Component, with container-awareness and a design-time presence. If automatic container-awareness and a design-time presence is not worth the bother - then don't create one. However, if such features are useful - then here is a tool ready and able to do the job. I never meant to imply they are not necessary or should be avoided, only that they have fallen out of favor. (Though there is a revival of sorts with 'packaged design elements' in other platforms.) -ralph [If you really want to provide expanded 'design-time' features take a look at ActiveX UserDocuments. There is a interesting, highly useful, .related technology Albeit one that never found much favor, or in fact can be said, never quite got out of the starting gate. lol]
From: Ralph on 10 Sep 2009 14:43
"Ralph" <nt_consulting64(a)yahoo.com> wrote in message news:uo3ftXkMKHA.1312(a)TK2MSFTNGP05.phx.gbl... > > > [If you really want to provide expanded 'design-time' features take a look > at ActiveX UserDocuments. There is a interesting, highly useful, .related > technology Albeit one that never found much favor, or in fact can be said, > never quite got out of the starting gate. lol] > Make that "VB design-time features". |