From: Eduardo on 9 Sep 2009 12:12 Tom Shelton escribi�: >> 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.... So you still have invisible objects in the form, the thing that is criticized.
From: Eduardo on 9 Sep 2009 12:21 Schmidt escribi�: > "Larry Serflaten" <serflaten(a)usinternet.com> schrieb im Newsbeitrag Guys, do you really think it should get so complex, using another dll or dlls? I would put everything in the OCX.
From: Tom Shelton on 9 Sep 2009 12:30 On 2009-09-09, Eduardo <mm(a)mm.com> wrote: > Tom Shelton escribi�: > >>> 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.... > > So you still have invisible objects in the form, the thing that is > criticized. I think you misunderstood me. I was not nor have I ever critized invisible objects on a form. You implied that there was no such thing as invisible uc's in .net and to correct you if wrong. I was simply correcting you - they exist, they are just implemented in a different way. When I was talking about best practice, I was talking about .net. Since in ..NET there is a clear distinction between a graphical control and a non-graphical control, it is generally wise to use the base class most appropriate to your situation. Not saying there are never cross over cases :) -- Tom Shelton
From: Webbiz on 9 Sep 2009 13:28 On Wed, 09 Sep 2009 04:52:14 -0300, Eduardo <mm(a)mm.com> wrote: >And about the array of UDTs, if the data is really fixed, and if you >only need that data for the indicators (inside the usercontrol project), >store all those values as constants. >In that case you don't need to pass that data from the form. I'm sorry. What I meant is that once you load the price data into the program, you don't need to make any changes to it. When you're done with it, you can load a new set of data into the program. Only one set of data is 'loaded' or used by the program as a whole at a time and is never manipulated. That is what I meant by 'fixed'. We read it, use it, but never change it other than wipe it out and load in a whole new set. The program in question is a Stock Charting application. I've tinkered with it for years. It's a hodge-podge, although it works great and does the job. The other day, however, I was thinking about adding a new indicator. But I stopped at the thought of all those modules that interact with these added indicators that would have to be edited to know a new indicator existed and how to do their thing to it. That's when I decided I needed to learn how to contain all the necessary behaviors and methods/properties into some logical centralized way for easy updating. And so that is where this saga began... Thanks! Webbiz
From: mayayana on 9 Sep 2009 13:34
>> 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. Oh? > > Differences from what? From VB.CLASSIC UC? >Yes, there are lots of differences. Ah, you must mean .Net and Tupperware are essentially the same thing. But can .Net do a burp-tight seal? :) |