Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > Visual Basic > VB 6 Visual Basic 6 > VB.NET
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
VB.NET General VB.NET discussions for issues that don't fall into other VB.NET forums.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the VB.NET section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old July 1st, 2008, 02:03 PM
Authorized User
 
Join Date: Jun 2008
Location: , , .
Posts: 21
Thanks: 0
Thanked 0 Times in 0 Posts
Default Getting the object name within a class

From within a class I'd like to get the name of the object wich is using this class. At first I thought there's a way to do this by the system.reflection namespace, but it seems like that namespace only provides information from the class itself, like classname and methodnames.

Anybody knows how I can get the name of an object from within the object (class) itself?

Example:
class cTest
  sub New
  end sub

  function GetMyName as string
     'code here for returning the name of the object wich uses this class
  end function
end class


dim oTest as new cTest

messagebox.show ("Hi, my name is " & oTest.GetMyName)



Hope I explained myself well here. Many thanks in advance,

koen

Reply With Quote
  #2 (permalink)  
Old July 1st, 2008, 04:34 PM
Friend of Wrox
 
Join Date: Jun 2008
Location: Snohomish, WA, USA
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Objects don't have names.

Oh, if the class they are an instance of have, say, a
     Public Name As String
field, then I guess you could say the that object contains a Name value.

I *THINK* what you mean is that you want the name of the *VARIABLE* that references the class????

So in your example
    dim oTest as new cTest
    messagebox.show ("Hi, my name is " & oTest.GetMyName)
you want to have it actually display
    Hi, my name is oTest????

First of all, what's to prevent your code from doing
    Dim zamboni As cTest
    ...
    zamboni = oTest

Now you have *TWO* variables referencing the *SAME OBJECT*.

Same thing if you had a method
    Sub foo( framitz As cTest )
         ... code ...
    End Sub
and then you did
    foo( oText )

framitz is yet *another* reference to the ONE AND ONLY cTest object that you have created!

There's no such thing as a single "owner" of an object. So of course there's no reason to be able to find the name of the "owner" when there might be 3 or 10 or 100 or 10,000 variables all referencing the SAME OBJECCT!

My guess is that you have assumed that when you do
    dim oTest as new cTest
    Dim zamboni As cTest
    zamboni = oTest
that you would have two separate objects. But nothing could be further from the truth.

If you don't use the NEW operator, you can't GET a new object. You can only get a REFERENCE to an existing object.

So...sorry...but your question is a non sequitir.
Reply With Quote
  #3 (permalink)  
Old July 1st, 2008, 04:46 PM
Friend of Wrox
 
Join Date: Jun 2008
Location: Snohomish, WA, USA
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Incidentally...

In general, variable names do *NOT* appear in compiled code!

So when you do
    Dim oTest As New cTest
almost surely when the code is running, the name "oTest" is nowhere to be found.

It makes sense: What's the point in knowing it??? It's just extra overhead to keep around.

[This doesn't apply to code compiled for debugging, where information such as variable names is needed for the debugger, so that it can display and use the variable name, instead of just "address 0x88771199" which is how the variable might appear in fully compiled code [except of course in non-human-readable form].
Reply With Quote
  #4 (permalink)  
Old July 1st, 2008, 04:49 PM
Friend of Wrox
 
Join Date: Nov 2004
Location: Port Orchard, WA, USA.
Posts: 1,621
Thanks: 1
Thanked 3 Times in 3 Posts
Default

You really will reduce your headache count by adding a property to the class that gets filled in when the class is instantiated, where you actually fill in the name of the object creating it. Though it would not be automatic (and making something automatic is a lot of fun), it would be flexible. You can put Me.Name if you are instantiating within a class (including a form), hard-code it, or maybe use reflection to get the name of the running object/code/function/module that is instantiating the class, and use that value in the constructor.
Reply With Quote
  #5 (permalink)  
Old July 1st, 2008, 05:29 PM
Friend of Wrox
 
Join Date: Jun 2008
Location: Snohomish, WA, USA
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Of course you can do that, but what's the value????

As I noted, if you pass that reference off to some subroutine, etc., why does where it was created matter?

In fact, I could easily see creating an instance in a method of some class, returning the reference from the method, and then the method (and maybe even the object that contained that method) go out of scope and are garbage collected and you still have this created object floating around with the name of something that no longer exists.

Can you think of a few cases (or even one case) where knowing WHAT created an object would be important?

The best I can come up with be something like this: You create a visual object [e.g., a button] within a nother visual object [e.g., a row in a datagrid] and you want to be able to get the container [the row] so you can perform operations on other items in the same container [same row].

Makes sense. But then the *NAME* of the object that created you is WORTHLESS! What you really need is a *REFERENCE* to the object that created you. You could care less what its name is (or even if it has a name).

So, yeah, I can see doing
Code:
     Class Row 
         Dim children(20) AS DisplayableObject
         Sub makeButton( )
             children(x) = New Button( "Push me", "red", Me )
         End Sub
         ...
         [horrible coding, but you get the idea] passing in ME so the button can find its parent. But why would you pass in ME.NAME, even if ROW had a NAME field???
Reply With Quote
  #6 (permalink)  
Old July 15th, 2008, 01:52 PM
Authorized User
 
Join Date: Jun 2008
Location: , , .
Posts: 21
Thanks: 0
Thanked 0 Times in 0 Posts
Default

both Brian and Old Pedant thanks a lot for your expert views on thisone. it helped a lot. What I want to do obviously doesn't make much sense. So I will try other ways.

Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
access class object Sheraz Khan ASP.NET 2.0 Professional 0 September 10th, 2007 06:19 PM
Object Class and Multiple inheritance deepthraj BOOK: Professional C#, 2nd and 3rd Editions 1 May 23rd, 2006 12:57 PM
HOW-TO Maintain a Class Object in Session laksa ASP.NET 1.x and 2.0 Application Design 1 April 28th, 2005 09:21 PM
Passing Class object to WS r_ganesh76 .NET Web Services 4 October 4th, 2004 11:12 PM
DataRow Or Class Object? RM82 BOOK: ASP.NET Website Programming Problem-Design-Solution 3 June 11th, 2004 09:12 PM



All times are GMT -4. The time now is 11:25 AM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.