Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Managed C++/CLI
  4. __property oddity

__property oddity

Scheduled Pinned Locked Moved Managed C++/CLI
graphicshelp
24 Posts 6 Posters 125 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N 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++.

    R Offline
    R Offline
    Rama Krishna Vavilala
    wrote on last edited by
    #21

    I don't think it's a bug. To me it is looks quite obvious that the scope resolution should fail in the second case as it tries to resolve the token Graphics in the local scope and it turns out to be a property name where property name is not expected. Solve this using

    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:	
    	System::Drawing::Graphics \*m\_pGraphics;	
    	System::Drawing::Bitmap   \*m\_pBitmap;
    };
    

    And for all the C# haters, C# compiler is much smarter in this regard.

    J N 2 Replies Last reply
    0
    • T 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.

      J Offline
      J Offline
      James T Johnson
      wrote on last edited by
      #22

      Tom Archer wrote: Very strange... It is indeed, before Christian tore me away from my research, I didn't see anything that would indicate variable declarations need to go at the top of the file. Unfortunately all the __property examples I've seen use the same one slightly modified: __property int get_Size() { return 0; } __property void set_Size() { } X| Once I get my mind back in shape I'll take a further look :) James Simplicity Rules!

      1 Reply Last reply
      0
      • R Rama Krishna Vavilala

        I don't think it's a bug. To me it is looks quite obvious that the scope resolution should fail in the second case as it tries to resolve the token Graphics in the local scope and it turns out to be a property name where property name is not expected. Solve this using

        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:	
        	System::Drawing::Graphics \*m\_pGraphics;	
        	System::Drawing::Bitmap   \*m\_pBitmap;
        };
        

        And for all the C# haters, C# compiler is much smarter in this regard.

        J Offline
        J Offline
        James T Johnson
        wrote on last edited by
        #23

        Rama Krishna wrote: private: System::Drawing::Graphics *m_pGraphics; System::Drawing::Bitmap *m_pBitmap; :omg: :omg: Thats it, I quit! ;P James Simplicity Rules!

        1 Reply Last reply
        0
        • R Rama Krishna Vavilala

          I don't think it's a bug. To me it is looks quite obvious that the scope resolution should fail in the second case as it tries to resolve the token Graphics in the local scope and it turns out to be a property name where property name is not expected. Solve this using

          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:	
          	System::Drawing::Graphics \*m\_pGraphics;	
          	System::Drawing::Bitmap   \*m\_pBitmap;
          };
          

          And for all the C# haters, C# compiler is much smarter in this regard.

          N Offline
          N Offline
          Neil Van Note
          wrote on last edited by
          #24

          Actually, I think you may be correct, that’s what I get for looking at these things at 3:30 in the morning...

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups