Conversion from 2003 to 2005 just too hard

[Peter Oliphant]

I've been trying all morning to convert my 2003 project (managed) to 2005
(/clr since I have both managed and unmanaged code). I'm guessing I have
tens of thousands of lines of code to change. Did a lot of converting '__gc'
to 'ref', converting '*' to '^', converting 'new' to 'gcnew'. Of course this
can't be done with a blanket replace, as my code has both managed and
unmanaged segments. Thus I have to do them one-by-one. Also, things are
missing. Like Form no longer has a Bounds property anymore (or at least if I
try to use it I get an 'it doesn't exist' error, which is a line that
compiled just fine in 2003). I can't have private virtual function even
though they were fine in 2003 (ok, i can see why they have to be protected).
In short, it's kind of exasperating to have to deal with an upgrade that
isn't even remotely backwards compatible (not even with old syntax switched
on)...

But, even after willing to do all of these changes, I now think I should
stop, having run into the Graphics class.

Graphics methods such as DrawPolygon() apparently no longer compile. The
only versions given are the ones using old syntax format for the required
__gc Points[] array. No /clr compatible overload of this function is given
(at least not in the look-ahead pop-up that comes up for DrawPolygon). So
how does one now draw a Polygon with the Graphics class now?

It's looking more and more that if you started in 2003 one should
(unfortunately) stay in 2003. Starting a project in 2005 might be good, but
converting is extremely difficult and prone to lots of erros. And even the
conversion I did into an old syntax 2005 version now returns with an
exception error it didn't have in 2003.... : (

Why didn't MS write a conversion tool? Sure it probably couldn't do
everything, but it could do the most obvious stuff. Like:

(1) identify '__gc' stuff and 'ref' it (note this doesn't work as a blanket
edit replace since '__gc' is also used to define other stuff, like arrays)
(2) replace appropriate '*' with '^', replace appropriate 'new' with
'gcnew', replace the '__' words with the new syntax versions (e.g.,
'__delegate' with 'delegate')
(3) make appropriate private virtual methods protected
(4) change abstract classes to the new syntax
(5) redefine arrays with the new 'array' syntax
(6) identify old methods that no longer works and put in the new syntax
(e.g., replace MakePolygon() code lines with the new syntax, and do this
will all such methods which have changed format)
(7) etc.

I've seen compiler errors that say stuff like "you did X, use Y instead".
Why doesn't the compiler give an option to make those changes FOR YOU?

I think 2005 is way too different from 2003 to call it an 'upgrade'. It's
basically incompatible with 2003 if one decided to use Managed C++...

[==P==]

 

[Nishant Sivakumar]

I understand your pain, Peter - but for about an year and a half, it was
pretty obvious that investing time in MC++ code would not be such a smart
thing to do, ever since Herb Sutter talked about C++/CLI a few PDCs ago.
Every time someone had asked if it was worthwhile to try Managed C++ (old
syntax), I had explicitly told them that my advice would be to wait for
2005. I did this in spite of the fact that this would probably affect the
sales of my book (which targetted the old syntax).

On a related note, this might help some of us understand why a lot of VB6ers
were pissed when VB.NET came out, it wasn't an upgrade, it was a whole new
language/syntax etc.

On another related note, I vaguely remember Stan Lippman saying that he was
working on an old syntax to new syntax converter - but I am not sure that he
ever got around to finishing that.

--
Regards,
Nish [VC++ MVP]

I've been trying all morning to convert my 2003 project (managed) to 2005
(/clr since I have both managed and unmanaged code). I'm guessing I have
tens of thousands of lines of code to change. Did a lot of converting
'__gc' to 'ref', converting '*' to '^', converting 'new' to 'gcnew'. Of
course this can't be done with a blanket replace, as my code has both
managed and unmanaged segments. Thus I have to do them one-by-one. Also,
things are missing. Like Form no longer has a Bounds property anymore (or
at least if I try to use it I get an 'it doesn't exist' error, which is a
line that compiled just fine in 2003). I can't have private virtual
function even though they were fine in 2003 (ok, i can see why they have
to be protected). In short, it's kind of exasperating to have to deal with
an upgrade that isn't even remotely backwards compatible (not even with
old syntax switched on)...

But, even after willing to do all of these changes, I now think I should
stop, having run into the Graphics class.

Graphics methods such as DrawPolygon() apparently no longer compile. The
only versions given are the ones using old syntax format for the required
__gc Points[] array. No /clr compatible overload of this function is given
(at least not in the look-ahead pop-up that comes up for DrawPolygon). So
how does one now draw a Polygon with the Graphics class now?

It's looking more and more that if you started in 2003 one should
(unfortunately) stay in 2003. Starting a project in 2005 might be good,
but converting is extremely difficult and prone to lots of erros. And even
the conversion I did into an old syntax 2005 version now returns with an
exception error it didn't have in 2003.... : (

Why didn't MS write a conversion tool? Sure it probably couldn't do
everything, but it could do the most obvious stuff. Like:

(1) identify '__gc' stuff and 'ref' it (note this doesn't work as a
blanket edit replace since '__gc' is also used to define other stuff, like
arrays)
(2) replace appropriate '*' with '^', replace appropriate 'new' with
'gcnew', replace the '__' words with the new syntax versions (e.g.,
'__delegate' with 'delegate')
(3) make appropriate private virtual methods protected
(4) change abstract classes to the new syntax
(5) redefine arrays with the new 'array' syntax
(6) identify old methods that no longer works and put in the new syntax
(e.g., replace MakePolygon() code lines with the new syntax, and do this
will all such methods which have changed format)
(7) etc.

I've seen compiler errors that say stuff like "you did X, use Y instead".
Why doesn't the compiler give an option to make those changes FOR YOU?

I think 2005 is way too different from 2003 to call it an 'upgrade'. It's
basically incompatible with 2003 if one decided to use Managed C++...

[==P==]

 

[Tarek Madkour [MSFT]]

Graphics methods such as DrawPolygon() apparently no longer compile.
The only versions given are the ones using old syntax format for the
required __gc Points[] array. No /clr compatible overload of this
function is given (at least not in the look-ahead pop-up that comes up
for DrawPolygon). So how does one now draw a Polygon with the Graphics
class now?

IntelliSense (the look-ahead popup) can only work in one C++ managed
code syntax: either the old managed C++ syntax or the new C++/CLI
syntax. When you have projects in the solution that have a mix of both,
IntelliSense gets confused. (In reality, in some situations it may also
get confused if you started with old syntax and set it to new syntax).

If you would like to get IntelliSense on the prototypes of some
functions in the new syntax when you have some of those "mixed-syntax"
solutions, you can just create a new solution that has only one project
that's compiled with the new syntax. IntelliSense in that project will
show exactly what you want to see: prototypes in the new syntax only.
You can use that as help when writing code in the "mixed-syntax"
solutions.

I hope this helps.

Thanks,

 

[Arnaud Debaene]

Graphics methods such as DrawPolygon() apparently no longer compile.
The only versions given are the ones using old syntax format for the
required __gc Points[] array. No /clr compatible overload of this
function is given (at least not in the look-ahead pop-up that comes
up for DrawPolygon). So how does one now draw a Polygon with the
Graphics class now?

IntelliSense is not and has never been the reference to say what is valid
and what is not, you shouldn't rely on it. The reference is :
1) MSDN.
2) The compiler error messages.

If IntelliSense doesn't give what you think is the correct sytnax, just
write it by hand and try to compile it.

This does compile with /clr (it's a copy-paste from MSDN documentation) and
it works correctly in the Paint handler of a WinForm :

Pen^ blackPen = gcnew Pen( Color::Black,3.0f );
Point point1 = Point(50,50);
Point point2 = Point(100,25);
Point point3 = Point(200,5);
Point point4 = Point(250,50);
Point point5 = Point(300,100);
Point point6 = Point(350,200);
Point point7 = Point(250,250);
array<Point>^ curvePoints =
{point1,point2,point3,point4,point5,point6,point7};

e->Graphics->DrawPolygon( blackPen, curvePoints );
//e is a valid PaintEventArgs

Arnaud
MVP - VC

 

[Peter Oliphant]

I wish there was a way to change *part* of my source to /clr while leaving
the rest as old syntax. I know this is an unreasonable desire, since it
would have problems in one section if it refered to something in another
section (e.g., it would be weird if GC_Class^ were used in one place and
GC_Class* in another).

My problem is that for me to change it to /clr syntax I have to change *all*
of my source code to be compliant for it to compile successful. In my case
that looks like it would take changing literally thousands if not tens of
thousands of lines of code (and I only started writing this code 6 weeks
ago, I tend to be verbose...lol). Thus, its a daunting task that must work
in its entirety or not at all.

And I ran into a 'road block' ala a problem with methods like the Graphics
class method DrawPolygon(). According to MSDN on-line, this Graphics class
method ONLY takes Point __gc[] as a parameter for the vertex points list of
the polygon to be formed, which is old syntax format. No /clr compliant
version appears to exist. I can't find any new version in MSDN on-line
documentation, so it looks like DrawPolygon is no longer available.

I doubt that this is the case, some new version of DrawPolygon probably does
exist, or some way to still use the old version under /clr (I know it
doesn't work without some change, the compiler complains about anything of
the form Point _gc[]'), but how do I find out the details to it? Will a
method that has a parameter of the form "Point __gc[] point" work if I give
it something defined like this:

array<Point^>^ point

[==P==]

Graphics methods such as DrawPolygon() apparently no longer compile.
The only versions given are the ones using old syntax format for the
required __gc Points[] array. No /clr compatible overload of this
function is given (at least not in the look-ahead pop-up that comes
up for DrawPolygon). So how does one now draw a Polygon with the
Graphics class now?

IntelliSense is not and has never been the reference to say what is valid
and what is not, you shouldn't rely on it. The reference is :
1) MSDN.
2) The compiler error messages.

If IntelliSense doesn't give what you think is the correct sytnax, just
write it by hand and try to compile it.

This does compile with /clr (it's a copy-paste from MSDN documentation)
and it works correctly in the Paint handler of a WinForm :

Pen^ blackPen = gcnew Pen( Color::Black,3.0f );
Point point1 = Point(50,50);
Point point2 = Point(100,25);
Point point3 = Point(200,5);
Point point4 = Point(250,50);
Point point5 = Point(300,100);
Point point6 = Point(350,200);
Point point7 = Point(250,250);
array<Point>^ curvePoints =
{point1,point2,point3,point4,point5,point6,point7};

e->Graphics->DrawPolygon( blackPen, curvePoints );
//e is a valid PaintEventArgs

Arnaud
MVP - VC

 

[Carl Daniel [VC++ MVP]]

I wish there was a way to change *part* of my source to /clr while leaving
the rest as old syntax. I know this is an unreasonable desire, since it
would have problems in one section if it refered to something in another
section (e.g., it would be weird if GC_Class^ were used in one place and
GC_Class* in another).

My problem is that for me to change it to /clr syntax I have to change
*all* of my source code to be compliant for it to compile successful. In
my case that looks like it would take changing literally thousands if not
tens of thousands of lines of code (and I only started writing this code 6
weeks ago, I tend to be verbose...lol). Thus, its a daunting task that
must work in its entirety or not at all.

And I ran into a 'road block' ala a problem with methods like the
Graphics class method DrawPolygon(). According to MSDN on-line, this
Graphics class method ONLY takes Point __gc[] as a parameter for the
vertex points list of the polygon to be formed, which is old syntax
format. No /clr compliant version appears to exist. I can't find any new
version in MSDN on-line documentation, so it looks like DrawPolygon is no
longer available.

I doubt that this is the case, some new version of DrawPolygon probably
does exist, or some way to still use the old version under /clr (I know it
doesn't work without some change, the compiler complains about anything of
the form Point _gc[]'), but how do I find out the details to it? Will a
method that has a parameter of the form "Point __gc[] point" work if I
give it something defined like this:

array<Point^>^ point

Yes, they're exactly the same type, one spelled in the old syntax, the other
in the new syntax.

-cd

 

[Arnaud Debaene]

And I ran into a 'road block' ala a problem with methods like the
Graphics class method DrawPolygon(). According to MSDN on-line, this
Graphics class method ONLY takes Point __gc[] as a parameter for the
vertex points list of the polygon to be formed, which is old syntax
format. No /clr compliant version appears to exist. I can't find any
new version in MSDN on-line documentation, so it looks like
DrawPolygon is no longer available.

Have you read and try the example I gave you?

And of course, the new syntax is documented on MSDN :
http://msdn2.microsoft.com/en-us/library/dd0c4s09(en-US,VS.80).aspx

The C++ syntax has changed, the BCL contents hasn't changed that much...

Arnaud
MVP - VC

 

[Holger Grund]

the form Point _gc[]'), but how do I find out the details to it? Will a
method that has a parameter of the form "Point __gc[] point" work if I
give it something defined like this:

array<Point^>^ point

Yes, they're exactly the same type, one spelled in the old syntax, the
other in the new syntax.

Umh, unless I'm missing something these don't match because you
have another level of indirection here.

I guess it should be array<Point>^ point (I'm too lazy to look it up, but
I would design Point as a value type).

Otherwise it should have been
Point* [] point
in the first place.

-hg

 

[Sebastian Dau]

I understand your pain, Peter - but for about an year and a half, it was
pretty obvious that investing time in MC++ code would not be such a smart
thing to do, ever since Herb Sutter talked about C++/CLI a few PDCs ago.
Every time someone had asked if it was worthwhile to try Managed C++ (old
syntax), I had explicitly told them that my advice would be to wait for
2005. I did this in spite of the fact that this would probably affect the
sales of my book (which targetted the old syntax).

Are you telling us as an MVP, that you suggest not to use a whole product of
microsoft just because
you are familiar with the MS's inconvenient way of improving unlovely
products?

Isn't it pain in the ass situation to suffer a monololists stategies?
downward compatibility should be
a development goal not an unloved duty.

..NET rocks and MS did a good job but they should continue their work and
improve update stragegies.

Greets, Sebastian Dau

 

[Peter Oliphant]

You're correct, that DrawPolygon is defined and up-to-date on the link you
provided (thanks!):

http://msdn2.microsoft.com/en-us/library/dd0c4s09(en-US,VS.80).aspx

But, I kind of ran into a 'decoy' page, ala this other page in on-line MSDN:

http://msdn.microsoft.com/library/d...ystemdrawinggraphicsclassdrawpolygontopic.asp

Any hints as how to find the most recent and up-to-date pages on MSDN? You
can see how I was a bit confused having only found the link I gave above,
and IntelliSense 'said' the same thing... : )

[==P==]

And I ran into a 'road block' ala a problem with methods like the
Graphics class method DrawPolygon(). According to MSDN on-line, this
Graphics class method ONLY takes Point __gc[] as a parameter for the
vertex points list of the polygon to be formed, which is old syntax
format. No /clr compliant version appears to exist. I can't find any
new version in MSDN on-line documentation, so it looks like
DrawPolygon is no longer available.

Have you read and try the example I gave you?

And of course, the new syntax is documented on MSDN :
http://msdn2.microsoft.com/en-us/library/dd0c4s09(en-US,VS.80).aspx

The C++ syntax has changed, the BCL contents hasn't changed that much...

Arnaud
MVP - VC

 

[Nishant Sivakumar]

The offline MSDN collection that's installed with VS.NET 2005 is quite
up-to-date too!

--
Regards,
Nish [VC++ MVP]

You're correct, that DrawPolygon is defined and up-to-date on the link you
provided (thanks!):

http://msdn2.microsoft.com/en-us/library/dd0c4s09(en-US,VS.80).aspx

But, I kind of ran into a 'decoy' page, ala this other page in on-line
MSDN:

http://msdn.microsoft.com/library/d...ystemdrawinggraphicsclassdrawpolygontopic.asp

Any hints as how to find the most recent and up-to-date pages on MSDN? You
can see how I was a bit confused having only found the link I gave above,
and IntelliSense 'said' the same thing... : )

[==P==]

And I ran into a 'road block' ala a problem with methods like the
Graphics class method DrawPolygon(). According to MSDN on-line, this
Graphics class method ONLY takes Point __gc[] as a parameter for the
vertex points list of the polygon to be formed, which is old syntax
format. No /clr compliant version appears to exist. I can't find any
new version in MSDN on-line documentation, so it looks like
DrawPolygon is no longer available.

Have you read and try the example I gave you?

And of course, the new syntax is documented on MSDN :
http://msdn2.microsoft.com/en-us/library/dd0c4s09(en-US,VS.80).aspx

The C++ syntax has changed, the BCL contents hasn't changed that much...

Arnaud
MVP - VC

 

[Peter Oliphant]

If you would like to get IntelliSense on the prototypes of some

functions in the new syntax when you have some of those "mixed-syntax"
solutions, you can just create a new solution that has only one project
that's compiled with the new syntax.

Considering my application has ten's of thousands of lines of old syntax
code, this statement reminded me of the Larson cartoon where a careful study
of a scientist blackboard reveals the words with a pointer that says 'and a
*miracle* happens here"...LOL

Seriously, I really think the new syntax is great, just conversion to it
from the old syntax is tough. I started a new project from scratch
(different application), and I'm loving the new syntax! But I'm also trying
to convert an existing six-week old project from old syntax to new syntax,
and I'm NOT loving that...

[==P==]

Graphics methods such as DrawPolygon() apparently no longer compile.
The only versions given are the ones using old syntax format for the
required __gc Points[] array. No /clr compatible overload of this
function is given (at least not in the look-ahead pop-up that comes up
for DrawPolygon). So how does one now draw a Polygon with the Graphics
class now?

IntelliSense (the look-ahead popup) can only work in one C++ managed
code syntax: either the old managed C++ syntax or the new C++/CLI
syntax. When you have projects in the solution that have a mix of both,
IntelliSense gets confused. (In reality, in some situations it may also
get confused if you started with old syntax and set it to new syntax).

If you would like to get IntelliSense on the prototypes of some
functions in the new syntax when you have some of those "mixed-syntax"
solutions, you can just create a new solution that has only one project
that's compiled with the new syntax. IntelliSense in that project will
show exactly what you want to see: prototypes in the new syntax only.
You can use that as help when writing code in the "mixed-syntax"
solutions.

I hope this helps.

Thanks,