Макросы Windows.h не определены - PullRequest
0 голосов
/ 02 сентября 2011

Я делаю простую библиотеку с графическим интерфейсом, и я добрался до первого теста.Странно то, что ни один из макросов Windows, похоже, не определен.Я получаю сообщения об ошибках типа «NULL не был объявлен в области» и «HANDLE не был объявлен в области».Я думаю, что это может быть способ, которым я организовал код, потому что материал в файле ввода easywin.hpp также не определен, но кажется, что он должен работать.Вот (большинство) из easywin.hpp:

#ifndef EASYWIN_BASE_HPP
#define EASYWIN_BASE_HPP

#include <string>
#include <map>

//Strings are used everywhere, so might as well use them globally
using std::string;

/**
 * A namespace to encapsulate WinAPI and prevent name clashing.
**/

namespace WinAPI{
    #include <windows.h>
    #include <commctrl.h>
}

//header includes (ordered according to inheritance)
#include "Application.hpp"
#include "Object.hpp"
    #include "Widget.hpp"
        #include "Container.hpp"
            #include "Window.hpp"
                #include "Dialog.hpp"
                    //not implemented yet, so don't include
                    //#include "Light.hpp"
                    #include "Heavy.hpp"
            // there are more container types
        #include "Control.hpp"
            #include "Textbox.hpp"
        #include "Tooltip.hpp"

//source includes
//needed to simplify class dependencies
#include "Application.cpp"
#include "Object.cpp"
    #include "Widget.cpp"
        #include "Container.cpp"
            #include "Window.cpp"
                #include "Dialog.cpp"
                    //not implemented yet, so don't include
                    //#include "Light.cpp"
                    #include "Heavy.cpp"
            // there are more container types
        #include "Control.cpp"
            #include "Textbox.cpp"
        #include "Tooltip.cpp"

#endif

Я просто не понимаю.Если я включу все в этот файл, эти файлы ДОЛЖНЫ получить то, что определено в этом файле.Что я сделал не так?

РЕДАКТИРОВАТЬ: Чтобы поощрить лучшие ответы, я опубликую git-репозиторий:

https://github.com/PiMaster/Easywin

Ответы [ 3 ]

3 голосов
/ 02 сентября 2011

Вам нужно избавиться от пространства имен WinAPI.Даже если вам удастся собрать все для компиляции, выполнив поиск нужных вещей с помощью WinAPI ::, компоновщик не сможет ничего найти и все равно не будет строить.

Чтобы избежать конфликтов имен, выследует поместить весь ваш код в отдельное пространство имен и оставить Windows.h в покое.

0 голосов
/ 03 сентября 2011

Это должен быть комментарий к ответу IronMensan, потому что он полностью правильный, но я не могу туда вписаться ...

В API окон есть функции, которые принимают параметры типа "HANDLE" в глобальном пространстве имен,другими словами ":: РУЧКА".Библиотеки Windows уже скомпилированы для этого, и скомпилированный код существует в таких библиотеках, как user32.lib / dll.

Цель windows.h - определить типы и функции, которые уже существует в библиотеке, поэтому вы можете вызывать их.Что вы сделали, так это определили некоторые несвязанные типы, например WinAPI :: HANDLE, что хорошо, но никоим образом не изменяет тот факт, что библиотека содержит функции, для которых в качестве параметра требуется :: HANDLE.

Я понимаю, что вы пытаетесь сделать, и это хорошая цель.Однако это никак не может сработать.

0 голосов
/ 02 сентября 2011

В большинстве случаев подобные вещи происходят со мной из-за двойного определения макроса защиты. Обычно это происходит, когда вы копируете и вставляете заголовочный файл и забываете изменить макрос защиты. Попробуйте поискать EASYWIN_BASE_HPP в других файлах. В новых компиляторах вы также можете использовать #pragma once, чтобы упростить его.

Кроме того, обычно не рекомендуется использовать using в заголовочном файле. Пользователи заголовочного файла могут использовать более одного заголовочного файла из разных библиотек. У одного из них может быть конфликт с идентификатором string.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...