Damn frustrating problem :-(

[Simon]

Hi everyone,

I'm having a really weird problem. I'm sure its my fault and that I'm just
being stupid but here goes. I hope someone can help:

I have a collection class called RolesCollection. Which as you might expect
holds Role objects.

Instantiating the RolesCollection class calls some db code and the
RolesCollection becomes pupulated with roles according to the userid you
pass into the constructor.

The Role objects contain an id, name and description that are all set in the
constructor when the Role class is instantiated.

This is all good so far. The problem that is baffling me is:

The Role class also has a PermissionsCollection that ISNT set in the
constructor. However, immediately after setting up a role, the
PermissionsCollection is instantiated based on what the Debugger tells me.

Does anyone know how or why this variable is getting instantiated? At the
top of the class I'm declaring it to be null and I havent got any
initialising code for the PermissionsCollection class yet.

It's weird.

Thanks all

 

[Sylvain Lafontaine]

Some examples of your code may help.

Also, it's quite possible that when running under the debugger, some classes
will/may get instantiated in different ways; you should try running it
without the debugger.

S. L.

 

[thechaosengine]

Hi there,

I don't have the code with me right at this very second but its very
standard stuff.

****************************************************
it's quite possible that when running under the debugger, some classes
will/may get instantiated in different ways; you should try running it
without the debugger.
****************************************************

I've noticed this on one other occasion, about a month ago. It drove me
absolutely bonkers.

Can anyone tell me more about this. Surely it totally buggers your program
if the *debugger* goes and instantiates variables for you!

Thanks for any advice

Simon

 

[Willy Denoyette [MVP]]

Hi there,

I don't have the code with me right at this very second but its very
standard stuff.

Can't you post at least the part that declares the PermissionsCollection?

Willy.

 

[Guest]

Hi,

Indeed, the code is necessary to solve your problem.

It could be a nasty 'property vs debugger' problem, a problem I'm
occasionally facing. The debugger could evaluate the code behind the property
and induce all sorts of problems. A nasty one I had was Debug.Assert's firing
from within the context of the debugger and not from the context of my
executable when hovering over the property in the .NET evironment; result ->
infinite loop of Debug.Assert messages.... I can imagine a lot of other
possible problems, just by seeing the problem I suggest mentioned.

Tom

 

[thechaosengine]

OK Guys,

I've got the code now. The first piece of code I'm going to past is the loop
that I use in a RolesCollection that creates a load of Role objects.

A Role has a PermissionsCollection - which is the class that is magically
instantiating.

I've put the constructor of the Role class belwo as well.
PermissionsCollection is below as well.

I'm not sure how much help the PermissionsCollection class will be - NOTE:
I've put a break point on both constructors of PermissionsCollection -
it ISN'T called during this process. The class is magically instantiated
straight after a Role is created though

GRRRRRR

Thanks everyone

S


// Making Role objects:

if((rolesDataSet.Tables[0].Rows.Count) > 0){
short roleID = -1;
string roleName = null;
string roleDescription = null;
foreach(DataRow currentRow in rolesDataSet.Tables[0].Rows){
if(!Convert.IsDBNull(currentRow["roleID"])){
roleID = (short)currentRow["roleID"];
}
if(!Convert.IsDBNull(currentRow["roleName"])){
roleName = (string)currentRow["roleName"];
}
if(!Convert.IsDBNull(currentRow["roleDescription"])){
roleDescription = (string)currentRow["roleDescription"];
}
else{
roleDescription = "";
}

// TODO: Revisit the problem of the permissions variable getting
initialised "magically" after the
// Role constructor is called.
currentRole = new Role(roleID, roleName, roleDescription);
rolesArray.Add(currentRole);
}
}

*****************************************************************8
Now the Role class:

private Int16 roleID = -1;
private string roleName;
private string roleDescription;
private PermissionsCollection permissions;

public Role(Int16 i, string n, string d){
roleID = i;
roleName = n;
roleDescription = d;
}


// And the constructors of the PermissionsColelction (these are never called
during the magical process)

public PermissionsCollection(int userID) : base(){
innerArrayList = PermissionsCollectionDB.LoadPermissions(userID);
}
public PermissionsCollection(short roleID) : base(){
innerArrayList = PermissionsCollectionDB.LoadPermissions(roleID);
}

 

[Peter N Roth]

check section 10.4.4 and ff of C# language spec:


Field initialization
The initial value of a field, whether it be a static field or an instance
field, is the default value (§5.2) of the field's type. It is not possible
to observe the value of a field before this default initialization has
occurred, and a field is thus never "uninitialized".

--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
Home of Matrix.NET

 

[thechaosengine]

Field initialization
The initial value of a field, whether it be a static field or an instance
field, is the default value (§5.2) of the field's type. It is not possible
to observe the value of a field before this default initialization has
occurred, and a field is thus never "uninitialized".

Ok,

I'm not really sure what to make of that. How come, if I dont initialise, by
means of a constructor a string for example - its null until I give it
something?

Can you help

Thanks

 

[Peter N Roth]

I'm not really sure what to make of that. How come, if I dont initialise,
by means of a constructor a string for example - its null until I give it
something?

Let me chop your code down a little so I can see what's happening.



#region Using directives



using System;



#endregion



namespace TestInitialization {

class Program {

static void Main( string[] args )

{ // Role = null

Role currentRole = new Role( 1, "RoleName",
"RoleDescription" );

// Role = TestInitialization.Role

}

}



class Role{

private Int16 roleID = -1;

private string roleName;

private string roleDescription;

private PermissionsCollection permissions;



public Role( Int16 i, string n, string d ) // roleID
= -1, all others = null

{

roleID = i;

roleName = n;

roleDescription = d;

} // roleID = 1, rolename = n, roledescription = d,
permissions = null

}



class PermissionsCollection {} // to allow compilation

}



The comments indicate values at the points of execution.



Because you haven't initialized permissions, it remains null. C# knows it's
an object; the default value of an object is null, hence, permissions IS
null.



This is not the best way to construct an object; after construction, the
object is supposed to be 'complete'. So if permissions = null is not
complete, then you need to redesign that.


--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
Home of Matrix.NET