Re: #include problem - C / C++ / MFC Discussion Boards

Anacreon29-Jul-05 10:44

29-Jul-05 10:44

OK -- I see now that my problem may be, that I don't have a CWinApp-derived class in my DLL -- just a DllMain. I am going to switch over to a CWinApp object and insert the AFX_MANAGE_STATE calls, hopefully that will clear it up.

#include problem

massad29-Jul-05 6:03

massad

29-Jul-05 6:03

This seems like a straightforward problem but I am totally stumped and just can't figure it out. It seems that whenever some changes are made in some of the classes in my project (Specifically a newly added function takes a parameter of a different type class from the Project), the "location" of the include line for that class must be changed inside the "stdafx.h". Otherwise the compiler complains that it does not know what the Object being passed in is.

Here's an example:

[stdafx.h]

#include "class1.h" //the order of files here seems to cause problems.
#include "class2.h"

[class1.h]

#include "stdafx.h"
..... //some code

void Test(Class2* pClass); << //C2061 error occurs on this line saying it does not know what Class2 is!!!!

However if I switched around class2.h to be followed by class1.h in the stdafx.h there would be no problem.

Maybe I am doing something wrong but if I put all the include files into the stdafx.h and them simply include it in every class header file, shouldnt the compiler be able to know what all the classes area?

Any help is greatly appreciated.

Sincerely,

Ilya

Re: #include problem

John R. Shaw29-Jul-05 6:36

John R. Shaw

29-Jul-05 6:36

massad wrote:
shouldnt the compiler be able to know what all the classes area?

No. The order of the header files can be important. If a prototype in class1.h needs to know about a type defined in class2.h then class2.h normaly needs to be included before class1.h.

Most developers, now days, put a guard define# in there headers so that they will not be included twice (prevents include recursion). This also give you the advantage of allowing you to include any header files (w/guards) in any header file that needs the types defined in that header. It is also why C++ allows you to declare a class type, before it is define.

// class1.h
#ifndef _CLASS1_H_ // guard
#define _CLASS1_H_
#include "class2.h"
class class1 {...}
#endif // _CLASS1_H_

// class1.h
#ifndef _CLASS1_H_ // guard
#define _CLASS1_H_
class class2; // forward declaration
class class1 {...}
#endif // _CLASS1_H_

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

Re: #include problem

massad29-Jul-05 6:50

massad

29-Jul-05 6:50

Thank you John,

I have fixed the problem. Before I posted here, I tried to use forward declaration and the guards but I still seemed to have the errors appear.

The problem seems to have stemmed from the fact that the code was all inline in the header file (this is the way it was given to me, I didnt write it) and no code was put into the .cpp file.

While trying to figure out what the problem was, I had become fed up with all the code being inline and split it up between a header and the source and the problems disappeared.

Out of curiousity, so that I know for future reference, is there a problem with forward declarations if all the code is inside a header file?

Re: #include problem

John R. Shaw29-Jul-05 7:07

John R. Shaw

29-Jul-05 7:07

massad wrote:
is there a problem with forward declarations if all the code is inside a header file?

I would not think so. At least I have had no problems, resonantly.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

Re: #include problem

Bob Stanneveld29-Jul-05 7:41

Bob Stanneveld

29-Jul-05 7:41

Hello,

It seams that a problem with including to many headers. You should not include stdafx.h in your header.

The problem that you face is that you include stdafx.h in class1.h. In stdafx.h, you include class1.h, which in turn includes stdafx.h again. This is an infinite cycle and the compiler knows this. It just stops including and you get some errors.

If you don't use class1 in class2, you can include class2.h instead of stdafx.h in class1.h and you problem should be gone!

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

Re: #include problem

Anacreon29-Jul-05 7:58

Anacreon

29-Jul-05 7:58

#include "stdafx.h" is a signal to the compiler to use the precompiled header -- your compiler will perform better if you don't include stdafx.h in header files, instead include it as the first include file in your source files.

Re: #include problem

David Crow29-Jul-05 8:26

David Crow

29-Jul-05 8:26

massad wrote:
[stdafx.h]

#include "class1.h" //the order of files here seems to cause problems.
#include "class2.h"

Why are you including class1.h and class2.h in stdafx.h? In 12 years of using MFC, I've never had the need to include anything in that file except for system (e.g., Win32, MFC, STL) header files.

"One must learn from the bite of the fire to leave it alone." - Native American Proverb

Re: #include problem

sunit529-Jul-05 20:48

sunit5

29-Jul-05 20:48

in stdafx.h keep only those header files which are required by every .cpp which will save your compilation time.in your case if u put the header file in stadfx.h the order of these included file is imp as u r using an instance of a class into the other.in ur case its better u dont put up any include file in stadfx.h .rather than u put those header file in the .h file of a .cpp file which u require in that .cpp file

VC++ 2003 NET apps without NET installed?

gunrunnerjohn29-Jul-05 5:16

gunrunnerjohn

29-Jul-05 5:16

Is there any way to compile a simple console application with Visual Studio NET 2003 to run on a machine without NET Framework installed? I'd like the target application to run on any machine, not just those with NET installed.

I'm sure this is a simple thing, but I sure can't find it! Smile | :)

Re: VC++ 2003 NET apps without NET installed?

S. Senthil Kumar29-Jul-05 5:22

S. Senthil Kumar

29-Jul-05 5:22

If you used Managed C++, then no, there is no way you can run those applications without the .NET framework.

Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro

Re: VC++ 2003 NET apps without NET installed?

gunrunnerjohn29-Jul-05 5:40

gunrunnerjohn

29-Jul-05 5:40

All I want to do is to create a simple console application, I can't believe it's impossible with VC++ NET.

Re: VC++ 2003 NET apps without NET installed?

Trollslayer29-Jul-05 12:33

Trollslayer

29-Jul-05 12:33

You will find VC7.1 is there and probably the best solution.

Elaine Rose | [Rose]

The tigress is here Big Grin | :-D

Re: VC++ 2003 NET apps without NET installed?

GuoChunLiang29-Jul-05 17:14

GuoChunLiang

29-Jul-05 17:14

All I want to do is to create a simple console application, I can't believe it's impossible with VC++ NET.

If a "win32" console application,you can do it.
If a ".NET" console application, you can't do it

Tiny dog is me.

Solved: VC++ 2003 NET apps without NET installed?

gunrunnerjohn30-Jul-05 7:58

gunrunnerjohn

30-Jul-05 7:58

Problem solved, I don't know how the /clr switch got set in the project, but there it is! Smile | :)

Re: VC++ 2003 NET apps without NET installed?

McClamm29-Jul-05 5:49

McClamm

29-Jul-05 5:49

I have an option to make a Win32 Console Application in the New Project Wizard, that's close to what you're looking for. You could try making an empty project, too! Just include the basic dependencies you need.

Re: VC++ 2003 NET apps without NET installed?

gunrunnerjohn29-Jul-05 7:33

gunrunnerjohn

29-Jul-05 7:33

Thanks, I figured it out. I started over with a basic W32 console application. I have no idea why my original attempt refused to function without NET installed, I started it the same way. Confused | :confused:

Re: VC++ 2003 NET apps without NET installed?

Judah Gabriel Himango29-Jul-05 8:14

Judah Gabriel Himango

29-Jul-05 8:14

You must've either specified a .NET console project, or turned on managed extensions (/clr switch) in your project settings.

Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Homosexuality in Christianity
Judah Himango

Re: VC++ 2003 NET apps without NET installed?

gunrunnerjohn29-Jul-05 8:30

gunrunnerjohn

29-Jul-05 8:30

As it turns out, the /clr switch was on. I'm not sure how it hapened, since I've been using VC++ 6.0 for a long time, just got started with this version.

line printing charset

Anonymous (scp)29-Jul-05 4:56

Anonymous (scp)

29-Jul-05 4:56

I'm trying to print on a dot-matrix printer.
I want to send "raw" ascii characters to the printer (not graphics), in order to avoid the "NLQ" mode (sending raw text is the only way to print without the "NLQ").

I use OpenPrinter, StartDocPrinter, StartPagePrinter, WritePrinter, EndPagePrinter, EndDocPrinter and ClosePrinter.

But spanish characters like "eñe" (ñ Ñ), "cedilla" (ç Ç), spanish accents (á é í ó ú) and the "dieresis u" (ü) are not printed well.

I need to set the spanish charset.

I've also tried the GDI functions (creating a DC with CreateDC("WINSPOOL", printerName, NULL, NULL)), and using the stock font DEVICE_DEFAULT_FONT, but NLQ gets activated.

What else can I do?

Re: line printing charset

Blake Miller29-Jul-05 5:29

Blake Miller

29-Jul-05 5:29

You can send raw bytes of th eproper escape sequence to the printer to set it into the Spanish character set and then send those 'character' bytes out to the printer. Should print out fine then.

CDialog derived Child

23_44429-Jul-05 3:19

23_444

29-Jul-05 3:19

I have an SDI application with a FormView. The FormView has two buttons. One opens a CDialog derived class that is Modal and a Child.
The other opens a CDialog derived class that is Modeless and a Child.

Everything works fine when the Child style is removed and WS_POPUP is applied.
When it is applied the dialogs open up but are

(Modal and Child)
behind Mainframe with no way to get at it except minimize Mainframe. After the minimization of Mainframe the dialog does not allow one to click on it (Frame titlebar is grayed. I believe the whole dialog box is disabled.

(Modeless and Child
appears but does not allow one to click on it as the Frame titlebar is grayed. I believe the whole dialog box is disabled.

Now understand everything works as it should with the WS_POPUP style. Switch that and I get problems. The ONLY difference is the style. What is wrong?

Thanks.

//Modal Child
void CParentExamplesView::OnButton3()
{
CModalChild cmd;
cmd.DoModal();

}

//Modeless Child
void CParentExamplesView::OnButton4()
{
if (!m_pModelessChildDialog)
m_pModelessChildDialog= new CModelessChild;

if (!::IsWindow(m_pModelessChildDialog->GetSafeHwnd()))
m_pModelessChildDialog->Create(IDD_DIALOG6, this);

m_pModelessChildDialog->ShowWindow(SW_SHOW);

}

Re: CDialog derived Child

Blake Miller29-Jul-05 4:56

Blake Miller

29-Jul-05 4:56

Dialogs SHOULD have parents!

CModalChild cmd;
cmd.DoModal(this);

m_pModelessChildDialog= new CModelessChild(this);

So give THAT a try.

Re: CDialog derived Child

23_44429-Jul-05 5:49

23_444

29-Jul-05 5:49

Thanks,

DoModal() doesn't take any parameters

The modeless example IS passing in the parent.

Regardless if you don't pass in any parents the mainframe is the owner.

Still no answers.

Re: CDialog derived Child

David Crow29-Jul-05 8:33

David Crow

29-Jul-05 8:33

mx483 wrote:
Now understand everything works as it should with the WS_POPUP style. Switch that and I get problems.

So why are you not wanting to use WS_POPUP? You've not indicated that you would rather use WS_CHILD. All I can gather is that you've found something that works and want to know why.

"One must learn from the bite of the fire to leave it alone." - Native American Proverb

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.