From: Eduardo on
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
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
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
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
>> 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? :)