VS 2008
in [MFC]
|
From: Giovanni Dicanio on 28 Feb 2010 13:48 "DanB" <abc(a)some.net> ha scritto nel messaggio news:luwin.279$wr5.183(a)newsfe22.iad... > I'm sorry, this one should be right. > <http://lakeweb.net/MFC/xml.h> I did some simple modifications to your source code to build in VC9 (VS2008 SP1): 1. In 'xml.cpp' file I moved the 'it' pointer out of for loop scope (this is a breaking change from VC6): // FIX: moved 'it' out of for loop TiXmlNode* it = NULL; for( it= node->FirstChild( ); it; it= it->NextSibling( ) ) 2. There are several warnings due to use of strcpy and other "unsafe" CRT functions in your source code. I got rid of these warnings defining _CRT_SECURE_NO_WARNINGS in "StdAfx.h": #define _CRT_SECURE_NO_WARNINGS (A better solution might be to use safe CRT funtions like strcpy_s, etc.) Now the code builds fine and works fine for me in debug builds. Note that on this machine I don't have VC7.1 installed, so I have no idea if there could be conflicts with STL headers of VC9 with STL headers of VC7.1... but it seems quite strange to me. I would suggest you a rebuild all of your solution with VC9. You could also setup a virtual machine and install only VS2008 with SP1 on it, and see what happens when building your source code. > And maybe this library will be useful for you. I've been using it for many > years. Thanks. Giovanni
From: DanB on 28 Feb 2010 14:38 Giovanni Dicanio wrote: > "DanB" <abc(a)some.net> ha scritto nel messaggio > news:luwin.279$wr5.183(a)newsfe22.iad... > >> I'm sorry, this one should be right. >> <http://lakeweb.net/MFC/xml.h> > > I did some simple modifications to your source code to build in VC9 > (VS2008 SP1): > > 1. In 'xml.cpp' file I moved the 'it' pointer out of for loop scope > (this is a breaking change from VC6): > > // FIX: moved 'it' out of for loop > TiXmlNode* it = NULL; > for( it= node->FirstChild( ); it; it= it->NextSibling( ) ) > > 2. There are several warnings due to use of strcpy and other "unsafe" > CRT functions in your source code. > I got rid of these warnings defining _CRT_SECURE_NO_WARNINGS in "StdAfx.h": > > #define _CRT_SECURE_NO_WARNINGS > > (A better solution might be to use safe CRT funtions like strcpy_s, etc.) ***(I think a light just came on, see at the end of this post)*** Yes, I did all these fixes for the VC9 build. And for now I also cheated with _CRT_SECURE_NO_WARNINGS. But I will remove that. I see to it that all my code compiles without warnings and cheats in the end. strcpy is used in tinyxml and I never worried about making tiny unicode compliant. Some day I'll swap out the tiny engine with msxml and for now I'll fix the strcpy in tiny as this is a security issue and not just about unicode. > Now the code builds fine and works fine for me in debug builds. That figures. :) > Note that on this machine I don't have VC7.1 installed, so I have no > idea if there could be conflicts with STL headers of VC9 with STL > headers of VC7.1... but it seems quite strange to me. > I would suggest you a rebuild all of your solution with VC9. This solution is built from the ground up with VC9, I've hit 'rebuild solution' a few times. This looks to be a conflict because I have 7.1 installed. But I really can't remove 7.1 until I'm done with my move and feel comfortable with 9.0. > You could also setup a virtual machine and install only VS2008 with SP1 > on it, and see what happens when building your source code. When 2008 was beta, I installed it on my laptop and completely compiled and ran my product which included the xml lib. But the laptop didn't have 7.1 installed. I don't have enough hd space now to test on this machine, but from your experience and mine, I'm guessing my xml solution would compile and run fine if 9.0 is orphaned from 7.1. What is really confusing for me is that the debug database accurately points at both headers as if they were both used to compile the code, which from all I know, should be impossible. I have a feeling this will be a simple fix, possibly in the build settings or as likely, in the registery. Now, the light! After paying atention and trying to set #define HAS_ITERATOR_DEBUGGING 0, (That doesn't work), here is what I see. The implicit assignment operator uses the vs9.0 header while my code uses the 7.1 header. So the compiler is doing its own thing when compiling its own code. I don't have my environment set so 9.0 can find the 7.1 headers, it is finding them some other way. This is starting to look fixable now. I'm still beating google up over it. :) Thanks, Dan.
From: DanB on 28 Feb 2010 18:29 Well, big dumb head slap for me. I have a c:/.../lib where I build all my dlls into. I didn't occur to me the LIB environment variable would have an effect, I just made sure my INCLUDE was clear. But that was the only place the test app would find hexmld.dll! So I was actually running the test app with the 7.1 build instead of the new one. And that is why the debug info worked out, it was really there. I guess I'll have to use version numbers in my names, like hexmld_9 to keep things straight. Thanks for your considerations Giovanni and all. Best, Dan. I'll still be reporting on how my deployment for vista/7 goes when I get there!
From: Giovanni Dicanio on 1 Mar 2010 03:47 > DanB" <abc(a)some.net> ha scritto nel messaggio > news:B%Cin.65621$Ye4.17455(a)newsfe11.iad... > So I was actually running the test app with the 7.1 build instead of the > new one. And that is why the debug info worked out, it was really there. Good, glad you solved it. > I'll still be reporting on how my deployment for vista/7 goes when I get > there! OK! Giovanni
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: Excel automation to an already open XLS Next: Clear CWnd Child with png |