Re: Should this be an object?

"Larry Serflaten" <serflaten@xxxxxxxxxxxxxx> wrote in message
news:eDZub4MtHHA.4600@xxxxxxxxxxxxxxxxxxxxxxx

"MP" <NoSpam@xxxxxxxxxx> wrote

does this seem like the right direction to head?

No.

Turn 180 degrees and start thinking about how you can
de-couple your objects from everything else.


I thought that having the "transitional object" *was* helping to decouple
cUnit from fGui
so fGui could change without affecting cUnit. and cUnit could change without
affecting fGui....
cDisplayObject would be set-up by fGui to hold the implemented object
(regardless of what it was... textbox, label, etc )

You don't
really want them to know about the outside world, any more
than you want to require the outside world to know how your
object works.

Again, I realize I'm not quite "getting" all this because I thought that's
what I *was* doing.
using the generic DisplayObject kept fGui from having to know the internals
about even what cUnit had to display,
just that it was asking it to display something and setting the target for
where to put it,

and likewise cUnit didn't need to know where its' display was going, just
that it was presenting it's internal info to a generic DisplayObject
trusting in that object to know what to do with the information...



The less code they are 'required' to include in 'handling' eachother
the better....



As others have said, if its text that needs to be displayed,
then offer a function to return the text.

It seems that that is making fGui know more about cUnit... it would have to
know about it's .Text property, rather than just knowing it had a .Display
method which would know about what to display.

....but on second thought, either of the above seem to be really the same
thing.
fGui has to know "something" about cUnit... so what does it matter if it
knows it has a .Display method or a .DisplayText property or a .Text
property or .Whatever....????

If it is something
to be drawn, then you might pass in the hDC or other canvas
on which to draw itself. It could care less if that 'canvas' is a
form, picturebox, or printer, etc...

so form, picturebox and printers all have an hDc?

isn't that still dependent on the "DisplayTarget" being a specific type of
"something" ... in this case it's "coupled" to an hdC???

I was thinking that if cDisplayObject could be "anything" that that was
"decoupling" the class cUnit from the "target" in which to display it's
stuff, yet still keeping the responsibility for Displaying inside the class
itself...

as you can see I'm still quite confused on all this...but really, I am
trying to understand.. <g> .... maybe just not successful :-)

And the code that calls on
the object to draw itself, doesn't care how it does it, as long as
it draws itself to the place indicated by the passed in hDC or
other canvas. (form, picturebox...)

LFS



.

Relevant Pages

  • Re: Should this be an object?
    ... so fGui could change without affecting cUnit. ... your GUI to use it and supply it with GUI objects. ... and the display object has to ...
    (microsoft.public.vb.general.discussion)
  • Should this be an object?
    ... In project A I have an object, lets call it cUnit. ... At some point cUnit will be asked to display some information about itself ... Public Sub Display() ... If TypeOf (moDispObj) Is TextBox Then ...
    (microsoft.public.vb.general.discussion)
Loading