I am begging for help on this. I had a VC6 project that I converted to .NET 2003 and when I went to add a class using the add class wizard, it gave me the following error: "MFC classes can only be added to MFC projects." Thinking that it might of been a conversion problem, I rebuilt the project file using .NET 2003. It worked and I can add classes to the project. Now, the weird thing is if I move the directory that contains the project it goes back to giving me the previous error. I am really stumped on this one. Here is a link to a zip file that contains the "working" project. (It's full path on my drive is c:\Test\TinyCad). If someone could please take a look and tell me if your getting the same thing, or if you happen to know whats going on that would be of much help. Thank you for your time and attention. http://www.angelfire.com/electronic2/testme/TinyCad.zip The zip file is 15MB in size. Some side notes: I do not have a copy of VC6 otherwise I would have tried to see if the original dsw/dsp files are suffering from the same problem. TinyCad is a schematic capture program written by Matt Pyne.

:mad:Has anyone come across this problem? I have a VC6 MFC app that I want to continue developing in VC.NET2003 I can build the project and Intellisense works and all that, but when I want to add a new MFC class using the Class Wizard, It complains that I can only add an MFC class to an MFC project. Any ideas/solutions? thanks

:wtf: Okay here's a problem I am having: I create a pointer to a char like so: char *test = new char; then I pass that pointer to a class member function which fills it with data from a file. Heres the code for that: bool FileManager::ReadString(LPSTR StringData) { char SingleChar; bool done = false; while (done != true) { if(ReadData(&SingleChar, 1)==2) { return true; } switch (SingleChar) { case 10: case 13: { done=true; }break; default: { *StringData = SingleChar; StringData++; }break; } } *StringData = 0; StringData++; return true; } Then afterwards in the function that called the member function I do a: delete test; When it runs this piece of code I get: Debug Error! Program: c:\JD's Projects\FileManager\Debug\FileManager.exe DAMAGE: after Normal block (#38) at 0x00851FC0. Any Ideas? thanks, JD

Okay, that worked. However when the code runs inside of OnInitalUpdate GetDeviceCaps returns garbage. (Well, the variable contains garbage when I look at it, anyways). When I run the same code inside the OnDraw it returns the expected value. (96) Any ideas on that one? Thanks, JD

Hello all, Got a small problem that I was hoping I could get some help on. Using the CView class I need to get the current screen DPI. I know that I can use the GetDeviceCaps method in the CDC class to get the current DPI. The problem is that I want to retreive the values and store them somewhere in a variable BEFORE CView's OnDraw method. For example I tried this in CView's constuctor: CTestView::CTestView() { CDC *Test; Test = GetDC(); PixPerInchX=Test->GetDeviceCaps(LOGPIXELSX); PixPerInchY=Test->GetDeviceCaps(LOGPIXELSY); ReleaseDC(Test); } PixPerInchX, and PixPerInchY are defined elsewhere as an INT. When I run this, it ASSERT fails. I think that my Test pointer is coming up NULL. Any ideas? (P.S. I'm not a very good programmer yet, so if this is stupidly obvious I apologize.) Thanks, JD

Okay, I just want some idea's if anyone fancy's to give their input. Wnat I would like to do is create a digital circuit simulator. But I would like to keep everything modular. For example the app's doc structure (I am using MFC) would act as like a "backplane", and all the components would load in as DLL's. Now my question is what is the most efficent way to model this architecture using c++/MFC? I was thinking something like the doc class would keep a linked list "map" of integers that would represent pins on the device and the DLL's would somehow have to let the app know how many pins it has and if the pins is an input/output, etc... Any idea's if this would even work, or any other ideas that would be more effecient? Any help would be appreciated. Thanks, JD