__property oddity

James T Johnson

Looking at MSDN it appears that all I need to do to create a property is prefix the Property name with get_ or set_ and put the __property keyword before the method (f.e. __property int get_Size() { return m_size; }) But when I do the same with my code, I get this error C2327: 'ScreenSaverUtils::OptimizedBitmap::Graphics' : member from enclosing class is not a type name, static, or enumerator Here is my code:

__property Graphics* get_Graphics()
{
if( graphics == NULL )
graphics = Graphics::FromHdc(hdc);

return graphics;

}

Now if I just take out the __property keyword it compiles fine :confused: TIA, James Simplicity Rules!

Neil Van Note

James T. Johnson wrote: member from enclosing class is not a type name, static, or enumerator I will venture to guess from my efforts to reproduce the error that you have an outter class and an inner class, both with the property name Graphics. If you fully qualify the property return type as System::Drawing::Graphics, it should resolve the issue. Regards

Albert Pascual

Did you tried to change the name after get_ ? You cannot use a name that resolves to the same name as another member of the class That's the only thing I can think of! Al

James T Johnson

Nope, just a single class; and returning the fully qualified name was the first thing I tried :-D I did rename the property from get_Graphics to get_Graphicsrrafsd and it works, even though I don't have a member named Graphics, so apparantly it doesn't like me having a property name the same as a class. What I don't understand is why not? I don't see any mention of this, and the closest thing was that you had to be explicit with types in the case of name clashes. James Simplicity Rules!

James T Johnson

Thanks, it just doesn't like me naming the Property after another class; because I don't have another member named Graphics, just my private member graphics. I've converted it from a property to a method because I want it to be clear that the returned graphics should be disposed; but I'm still curious why it didn't work. James Simplicity Rules!

Neil Van Note

Well, I don't know what your exact situation is then. Except in the situation I mentioned, I was not able to reproduce your error. I had no problem having property named Graphics while the System::Drawing namespace was included. Regards

Tom Archer

Did you solve this yet? I've got properties all over my code without a problem. Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Nish Nishant

James T. Johnson wrote: so apparantly it doesn't like me having a property name the same as a class. Isn't that the reason? I think even in C# you can't have a property named same as the class. Nish

Check out last week's Code Project posting stats presentation from :- http://www.busterboy.org/codeproject/ Feel free to make your comments.

Nish Nishant

Tom Archer wrote: Did you solve this yet? I've got properties all over my code without a problem. Tom, I think we cannot have properties named after the class. Nish

Check out last week's Code Project posting stats presentation from :- http://www.busterboy.org/codeproject/ Feel free to make your comments.

James T Johnson

You can have a property named after a class, just not the name of the class that contains it. This isn't my case, my class is named OptimizedBitmap. Refer to PaintEventArgs, it has a property named Graphics of type Graphics :) James Simplicity Rules!

Nish Nishant

Oops! Sorry James :( Nish

Check out last week's Code Project posting stats presentation from :- http://www.busterboy.org/codeproject/ Feel free to make your comments.

Tom Archer

Actually, I copied the property into my code and it compiles fine sans the content. It's the content of the property that's the problem. I don't know if James has solved it or not. Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

James T Johnson

No problem :) I'm about to post my code so everyone can see whats going on. James Simplicity Rules!

James T Johnson

Here is the offending code

// ScreenSaverUtils.h

#pragma once

#pragma unmanaged
#include

#pragma managed

#using // For System.Diagnostics.Debug class

using namespace System;
using namespace System::Drawing;

namespace ScreenSaverUtils
{
public __gc class OptimizedBitmap : public IDisposable
{
private:
OptimizedBitmap(void)
{
}

public:

	OptimizedBitmap(Graphics \*g, Bitmap \*bmpToCopy ) : \_disposed(false)
	{
		// Copy bitmap
	}

	~OptimizedBitmap(void)
	{
		Dispose();
	}

	void Dispose()
	{
		// Free resources
	}

	\_\_property Graphics\* get\_Graphics()
	{
		System::Diagnostics::Debug::Assert(!\_disposed);

		return Graphics::FromImage(bitmap);
	}

	\_\_property Bitmap\* get\_Bitmap()
	{
		System::Diagnostics::Debug::Assert(!\_disposed);

		return dynamic\_cast(bitmap->Clone());
	}

private:
	bool \_disposed;
	HDC hdc;
	HBITMAP hbitmap;
	Graphics \*graphics;
	Bitmap \*bitmap;
};

}

Thanks for everyone's help :) [Edit: I'm no longer interested in using those two as properties because the original intent has changed; but I still want to know why its failing to compile :)] James Simplicity Rules!

Nish Nishant

Tom Archer wrote: I don't know if James has solved it or not. He hasnt. Not yet. I think he's going to post the code snippets now. Nish

Check out last week's Code Project posting stats presentation from :- http://www.busterboy.org/codeproject/ Feel free to make your comments.

Tom Archer

Thanks, Nish. I saw that he had posted responses to other posts after I answered you. Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Neil Van Note

Actually, depending on how you arrange this code, it comes back with varying results. If you move the variable declarations to the top of the class, most of the problems disappear. This doesn’t give me a whole lot of faith in MC++. There seems to be a conflict here though, but nothing is jumping out at me as anything being wrong with the class structure. Note: Variable names should not start with an underscore in C/C++; those are reserved for compiler vendors. The following compiles.

public __gc class OptimizedBitmap : public IDisposable
{
private:
bool disposed;
HDC hdc;
HBITMAP hbitmap;
Graphics *graphics;
Bitmap *bitmap;

OptimizedBitmap()
{
}

public:
OptimizedBitmap(Graphics *g, Bitmap *bmpToCopy ) :
disposed(false)
{
// Copy bitmap
}
~OptimizedBitmap(void)
{
Dispose();
}
void Dispose() {
// Free resources
}
__property Graphics* get_Graphics()
{
return Graphics::FromImage(bitmap);
}
__property Bitmap* get_Bitmap()
{
#if 0
return dynamic_castSystem::Drawing::Bitmap\*(bitmap->Clone());
#else // or
return new System::Drawing::Bitmap(bitmap);
#endif
}
};

James T Johnson

Thanks Neil, i'll put this through its run later, but now I have some anime to watch :) James Simplicity Rules!

Neil Van Note

This is interesting, I just created a new project and found this... This compiles...

namespace VNK {

using namespace System;
using namespace System::Drawing;

public __gc class Foo
{
private:
Graphics *m_pGraphics;
Bitmap *m_pBitmap;

public:
Foo();
~Foo();

\_\_property Graphics\* get\_Graphics()
{
	return m\_pGraphics;
}
\_\_property Bitmap\* get\_Bitmap()
{
	return m\_pBitmap;
}

};

This does not...

namespace VNK {

using namespace System;
using namespace System::Drawing;

public __gc class Foo
{
public:
Foo();
~Foo();

\_\_property Graphics\* get\_Graphics()
{
	return m\_pGraphics;
}
\_\_property Bitmap\* get\_Bitmap()
{
	return m\_pBitmap;
}

private:
Graphics *m_pGraphics;
Bitmap *m_pBitmap;
};

I would bet there is a bug report on this, or I am missing something very fundamental that came in on the heals of MC++.

Tom Archer

That would explain why it worked on my machine then. Very strange... Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.