|
Tom Archer wrote:
You're probably not surprised to know that I have this book also
Nope, neither the smallest fraction of the atom ( a quark  )
Tom Archer wrote:
Visual C++ .NET Step by Step
The book's content totally overlaps with Essential Guide to blah blah ?
Don't worry posting the response fast, after all this kind of book is ranked bellow your's and Christopher Duncan's book .
Cheers,
Joao Vaz
Frustrated TCL programmer,good c++ programmer wannabe
|
|
|
|
|
According to this
mc++ gotchas
The Visual .Net debugger cannot inspect the values of unmanaged pointers !!
Tell my friends that John Lam from Wintellect is wrong and that we can debug properly unmanaged pointers on a MC++ project , please , pretty please ?
Cheers,
Joao Vaz
Frustrated TCL programmer,good c++ programmer wannabe
|
|
|
|
|
Joao Vaz wrote:
Tell my friends that John Lam from Wintellect is wrong and that we can debug properly unmanaged pointers on a MC++ project , please , pretty please ?
Well.. I have no idea if John Lam is right or wrong. I'm only startig our with MC++ and I hope he is wrong as well 
 (-_-)
|
|
|
|
|
Well,
In the watch window unmanaged pointers don't show, you need to open a memory windows to inspected. At least is how I do it!
Al
|
|
|
|
|
Thanks Albert 
I hope the MS guys fix this soon .
Cheers,
Joao Vaz
Frustrated TCL programmer,good c++ programmer wannabe
|
|
|
|
|
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
TIA,
James
Simplicity Rules!
|
|
|
|
|
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
|
|
|
|
|
Nope, just a single class; and returning the fully qualified name was the first thing I tried 
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!
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
|
No problem
I'm about to post my code so everyone can see whats going on.
James
Simplicity Rules!
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Here is the offending code
#pragma once
#pragma unmanaged
#include <windows.h>
#pragma managed
#using <System.dll>
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)
{
}
~OptimizedBitmap(void)
{
Dispose();
}
void Dispose()
{
}
__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*>(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!
|
|
|
|
|
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)
{
}
~OptimizedBitmap(void)
{
Dispose();
}
void Dispose() {
}
__property Graphics* get_Graphics()
{
return Graphics::FromImage(bitmap);
}
__property Bitmap* get_Bitmap()
{
#if 0
return dynamic_cast<System::Drawing::Bitmap*>(bitmap->Clone());
#else // or
return new System::Drawing::Bitmap(bitmap);
#endif
}
};
|
|
|
|
|
Thanks Neil, i'll put this through its run later, but now I have some anime to watch
James
Simplicity Rules!
|
|
|
|
|
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++.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
