How to find Me in a library procedure

  • Thread starter Thread starter Academia
  • Start date Start date
Bill McCarthy said:
I suggest you look at my original response and the posters original
question. (the OP asked about the stack state)

Yes, and I say once more he shouldn't care about the stack (apart from
the arguments). Neither in instance methods nor in shared methods.
Again, as I have pointed out, inheritance only works if you are the
author of the common base class . With controls that is rarely the
case.

Maybe you should look at the OP's first post:

- call: "Library.DoSub(Me, ...)"
- first arg declared as: "( ByVal c as Control, ...)"

Again, he is the author of a class derived from Control, otherwise he
couldn't pass "Me" to a procedure that expects the type Control.

But maybe I am wrong.


Armin
 
Academia said:
Thanks Cor.
I've given up on finding the caller in a library sub.

Yes, good, because you shouldn't care about the caller.
I'll simply change everywhere to passing Me.

Why not put these methods into the class that calls them? I guess it's
because they are called from different classes, right? As you are able
to pass "Me" in all these classes, they must all have been derived from
Control. Therefore I still suggest to put them all in one common base
class. In the long run, it will pay.

Of course, it's up to you.


Armin
 
Hi Armin,

Armin Zingler said:
Maybe you should look at the OP's first post:

- call: "Library.DoSub(Me, ...)"
- first arg declared as: "( ByVal c as Control, ...)"

Again, he is the author of a class derived from Control, otherwise he
couldn't pass "Me" to a procedure that expects the type Control.


And doesn't my response indicate that I had already observed that ?

I don't see the point in discussing this further. I believe I have made it
abundantly clear that inheritance usually doesn't work in custom controls
because you rarely actually have a common base class you author. And as
such I have suggested he look at extension methods. The rest of this
conversation is reading like chest beating to me.

EOC.
 
Thanks for helping.
I now have two ways I can go.
As far as I can see they're both OK.
It's just a little work that I should do soon but don't have to do it right
now.
I this solution I did use inheritance so that a group of forms all contained
certain properties and subs. Worked great there.


Thanks again
 
Extension Functions can't be put into a library for use by multiple
projects. Right?

Thanks
 
Hi,
Academia said:
Extension Functions can't be put into a library for use by multiple
projects. Right?

Extension functions definitely can be put in a library, that's how they are
used for LINQ. An extension method must reside in a Module (static class).
In VB, the first parameter is the type you want to extend. You also add the
Extension() attribute to the method, e.g:

<Extension() > _
Sub LogData(Byval cntl as Control)
....
End sub

The nice thing about them is they allow you to have utility methods that are
not a OO property. For example, let's say you had a "human" class , and
humans can paint and so you decide to use inheritance. All seems good, until
someone says but elephants can paint too <g> In the case of Forms you might
find it works okay putting an intermediary base class between Form and your
custom Forms. That may work okay until comes the day you say it might be
nice to make then UserControls rather than Forms, allowing you to use them
in docked panels as well as stand alone forms. This is where extension
methods give you the flexibility to modify your design.
 
Back
Top