cannot open afx.h

Posted on 1998-02-21
Last Modified: 2013-11-20
I have used OWL and am now tryng to learn the MFC. This problem has me very frustrated. Just trying a "hello world" program from Windows MFC book by Jeff Prosise targeted at Visual C++. I use Borland 5.02. I use the include <mfc\afxwin.h> and get a compiler message "cannot open afx.h". afx.h is opened from afxwin.h which is obviously opened. any ideas???
Question by:dutch
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
LVL 32

Expert Comment

ID: 1316466
I think the problem is in  your include path for the compiler.  You shouldn't have to use:

#include <mfc/afxwin.h>

but rather you should be using:

#include <afxwin.h>

Since the line in afxwin.h that includes afx.h says:

#include <afx.h>

you get an error because the compiler can't find afx.h.

Go to your compiler setup and add the directory where the mfc include files live to the path.  I don't have BC++ 5 so I can't tell you exactly where.

Author Comment

ID: 1316467
Sorry but the paths to the library is correct. Borland supplies two class libraries, OWL and MFC. The libraries are in BC5\Include\Owl(or Mfc).To get to the OWL includes the entry would be;
#include <owl\combobox.h>

So, the Afxwin.h gets opened OK using <Mfc\Afxwin.h>. There is no message saying that the compiler can not open it, only the Afx.h file is the problem. If I try it your way, #include <afxwin.h>, then the message is "...cannot open Axfwin.h" The first thing the Afxwin.h include does is #include <Afx.h>. That is the problem. I checked and the Project is pointing to the correct include and library directories...
LVL 15

Accepted Solution

Tommy Hui earned 100 total points
ID: 1316468
Does the file exist? Where is the file? If the file does exist, make sure that you have that directory in your include path.
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 32

Expert Comment

ID: 1316469

You didn't read what I said.  Please read it again!

Author Comment

ID: 1316470
First, it is perfectly legal to point to a directory for an include file. Borland does this with both the OWL include files. The default directory for the project (I erroneously said "library" in my previous note) is f:\bc5\include. Beyond that, the OWL includes are in f:\bc5\include\owl and all the MFC (afx*.h) includes exist in f:\bc5\include\mfc. I have written several apps using OWL and the following syntax to access the OWL class include files (for example);

#include <owl\combobox.h>     //this always works

My assumption is that the same syntax should work for the mfc, for example;

#include <mfc\afxwin.h>         //fails opening include inside                                   afxwin.h

I went into the project and made the entry for the includes look as follows;

f:\bc5\include ; f:\bc5\include\mfc

The include line in my app is now;

#include <afxwin.h>

Now, the situation has improved. It compiles (and runs) but I get 11 warnings about virtual functions. The message from the help file is as follows;

'function1' hides virtual function 'function2'      
In this case, a declaration with the same name but different argument types makes the virtual functions inaccessible to further derived classes.

So, it looks like there is still something basically wrong???

LVL 32

Expert Comment

ID: 1316471
You're right, it is perfectly legal to do:

#include <mfc/afxwin.h>

BUT IF "mfc/afxwin.h" has ANOTHER #include IN IT THAT DOES:

#include <afx.h>

(and it DOES!!)  Guess what?  It can't be found because Microsoft expects you to put mfc in the include path.

The virtual function warning is just that, a warning.  You haven't provided enough information about what is causing the problem.  If you were to post the function definition that is causing the problem, it would probably help.

Author Comment

ID: 1316472
Boy this sure makes sense now!! Thanks

The warning messages are all the same. It looks like the warnings are coming from Create(NULL, "The Hello Application") in the CMainWindow constructor. The messages look like this;

AFXWIN.H 'CDialog::Create(const char*, CWnd)' hides function 'CWnd::Create(const char*, unsigned long, const tagRect&, CWnd*, unsigned int, CCreateContext*)'

The remaining 10 warnings are exactly the same except the class identified is CButton, CStatic, CDialog, CButton, etc.

Featured Post

On Demand Webinar: Networking for the Cloud Era

Ready to improve network connectivity? Watch this webinar to learn how SD-WANs and a one-click instant connect tool can boost provisions, deployment, and management of your cloud connection.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Exception Handling is in the core of any application that is able to dignify its name. In this article, I'll guide you through the process of writing a DRY (Don't Repeat Yourself) Exception Handling mechanism, using Aspect Oriented Programming.
Have you tried to learn about Unicode, UTF-8, and multibyte text encoding and all the articles are just too "academic" or too technical? This article aims to make the whole topic easy for just about anyone to understand.
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…

726 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question