From: Karl E. Peterson on
Ralph wrote:
> "Good artists copy. Great artist steal", Pablo Picasso

Hey, you stole that from my old website! <vbg>
--
..NET: It's About Trust!
http://vfred.mvps.org


From: Larry Serflaten on

"Webbiz" <nospam(a)forme.thanks.com> wrote

> What might be best way to deal with the add/deletion of different
> indicators where each needs to know the existence of others already
> displayed so as to share form space?

Step 1. Remove that thought from your head. There's no need to force
a tunnel vision of the issue. Keep an open mind to all possibilities, etc...
Who says each needs to know about the others? Does the command button
know you've added a textbox to the form?


> 1. Create a single class to accomodate all possible indicators -or-
>
> 2. Create a separate class for each new indicator?

I was never fond of the 'kitchen sink' approach. I prefer a more
modular design, so I favor #2.



> Q. If I do the data and indicator classes separately, then creating a
> single OCX appears out of the question. Or am I mistaken?

A UC project can contain other (public or private) classes. Your
UC project could contain the UC, a data class and some number of
chart and indicator classes.

When I need to design some functionality, I generally take a look at
what else out there looks similar to what I need to do. Taking note
of the good and the bad, I get an idea of what I want to support.

In your case, take a look a the Align property of a picturebox. Add
a few pictureboxes to a form, and set their Align properties. Do
the pictureboxes talk to eachother to accomplish what they do, or,
would you think the form actually handles their placement?

Also realize that there are no 'objects' on the screen, its _all_ just
so many pixels made to look like separate windows and controls
and whatnot. What makes a difference is how you handle them
in code.

What I suggested in my Bars example (in the previous discussion
from some time ago) was that you use an interface (class) to define
what a chart is and an event sync (class) to handle user input. With
an interface defined, your UC can communicate with every type of
chart/indicator class in the same way. You can keep creating new
charts and indicators, and as long as they support the interface, the
UC will be able to manage them.

In that scenareo, the UC module handles the creation and positioning
of the chart classes, and the class modules handle the drawing.
Once you get the positioning code done (in the UC module) you
shouldn't need to mess with it again. When you need a new indicator
you create a class that draws the image, and supports the common
interface. As I and others have suggested, you could draw right on
the User Control, so that all your charts and indicators could be
more simply controlled in any form code that has to position them.
(It only needs to position the UC)

About the only decision that might need more consideration is,
should the chart and indicator classes reside in the UC project,
or should they be kept separate? If you put them in the UC
project then adding classes to the UC project requires a re-compile
of the project, potentially breaking earlier code that uses the UC.
(You'd have to be careful to keep compatibility). If they are outside
the UC then the UC never changes (no compatibility issues) but
you need to keep a library of indicator classes that need to be
added to any of your other projects. A bit like adding controls
to the VB toolbox.

LFS






From: Karl E. Peterson on
Webbiz wrote:
> On Sat, 5 Sep 2009 18:21:01 -0700, Bee <Bee(a)discussions.microsoft.com>
> wrote:
>
>>2 cents from an old guy.
>>Only use a user control if you have to, i.e. need the same functionality in
>>multiple place in the same project. The learning curve is high and there are
>>got-yahs.
>
> Hello Bee.
>
> Don't know if you read my long-winded "wish list" for this control.

I haven't, but have just skimmed the thread.

> But I think that is what I need it for.
>
> Now I'm assuming we are not talking about plopping multiple controls
> on the form. I just want the functionality to be 'duplicated' by
> making new instances of the object or deleting them. They all will
> need the same data array to do their job, and they all will need the
> same routines to draw on their individual canvas area of the form.
>
> Does this quality in your opinion?

I'm not hearing that you need to include a user-interface with the encapsulated
functionality. If that's the case, the bar for using a UC rather than your
dirt-standard CLS is pretty darned high, IMO. Used to be, there was a real purpose
for invisible UCs. Users were too dumb to create a class instance in code, and this
was an easy way to provide them with functionality. And really, that remains pretty
much *almost* the only rationalization for writing a zero-UI UC to this day.

(I qualify that just a bit, because there are features - such as AsyncDownload -
that are only available within a UC.)
--
..NET: It's About Trust!
http://vfred.mvps.org


From: Eduardo on
Karl E. Peterson escribi�:

> I'm not hearing that you need to include a user-interface with the encapsulated
> functionality. If that's the case, the bar for using a UC rather than your
> dirt-standard CLS is pretty darned high, IMO. Used to be, there was a real purpose
> for invisible UCs. Users were too dumb to create a class instance in code, and this
> was an easy way to provide them with functionality. And really, that remains pretty
> much *almost* the only rationalization for writing a zero-UI UC to this day.
>
> (I qualify that just a bit, because there are features - such as AsyncDownload -
> that are only available within a UC.)

Another difference is that you have a reference to the form without
having to set it to a property.

Another one is that you have a design mode where you can set properties,
and also have property pages.

I think that invisible UCs are useful.

I believe that .Nxt don't support invisible UCs any more (correct me if
I'm wrong), so you lose that features. It's not good.
From: Eduardo on
Karl E. Peterson escribi�:
> Ralph wrote:
>> "Good artists copy. Great artist steal", Pablo Picasso
>
> Hey, you stole that from my old website! <vbg>

Because he's an artist