Подключение lib-файлов

[Sands]

Доброго всем времени суток.
Столкнулся с проблемой подключения lib-файла в проекте который пишется под Visual Studio .Net 2003. Может кто знает где запрятана ета опция? Буду очень благодарен.
Заранее спасибо всем.

[Dimitry]

Насколько помню, подключаемые *.lib файлы нужно перечислить в списке "Additionel dependencies" на вкладке параметров Linker'а. Меня в своё время это очень удивило...

[Sands]

А меня то как удивило  Но сработало  Спасибо!!!

[Dimitry]

Всегда пожалуйста!

[Serg79]

Можно еще и так делать:

Код:

#pragma comment(lib,"*.lib")

[Hadron]

Можно еще и так делать:
Код:

#pragma comment(lib,"*.lib")
С этим все понятно но вопрос почему при подключении

#pragma comment(lib, "winmm.lib")
неработает функция

 mciSendCommand(0,MCI_OPEN,MCI_OPEN_TYPE,(DWORD_PTR) &OpenParm);

[Алексей++]

Hadron, не работает или не линкуется ?

[Hadron]

Код из книги Фленова , который должен открыть лоток для дисков                                       
MCI_OPEN_PARMS OpenParm;
               MCI_SET_PARMS SetParm;
               MCIDEVICEID dID;
                     

                     
                     OpenParm.lpstrDeviceType = "CDAudio";
          mciSendCommand(0,MCI_OPEN,MCI_OPEN_TYPE,(DWORD_PTR) &OpenParm);
         dID = OpenParm.wDeviceID;
                    mciSendCommand(dID, MCI_SET, MCI_SET_DOOR_OPEN, (DWORD_PTR) &SetParm);
         mciSendCommand(dID, MCI_SET, MCI_SET_DOOR_CLOSED, (DWORD_PTR) &SetParm);
          mciSendCommand(dID, MCI_CLOSE, MCI_NOTIFY, (DWORD_PTR) &SetParm);

но появляется ошибка при компиляции

:\Program Files\Microsoft Visual Studio\MyProjects\Flenov5P\Flenov5P.cpp(186) : error C2065: 'DWORD_PTR' : undeclared identifier
C:\Program Files\Microsoft Visual Studio\MyProjects\Flenov5P\Flenov5P.cpp(186) : error C2677: binary '&' : no global operator defined which takes type 'struct tagMCI_OPEN_PARMSA' (or there is no acceptable conversion)
C:\Program Files\Microsoft Visual Studio\MyProjects\Flenov5P\Flenov5P.cpp(188) : error C2677: binary '&' : no global operator defined which takes type 'struct tagMCI_SET_PARMS' (or there is no acceptable conversion)
C:\Program Files\Microsoft Visual Studio\MyProjects\Flenov5P\Flenov5P.cpp(189) : error C2677: binary '&' : no global operator defined which takes type 'struct tagMCI_SET_PARMS' (or there is no acceptable conversion)
C:\Program Files\Microsoft Visual Studio\MyProjects\Flenov5P\Flenov5P.cpp(190) : error C2677: binary '&' : no global operator defined which takes type 'struct tagMCI_SET_PARMS' (or there is no acceptable conversion)
Error executing cl.exe.

[resource]

Последние 4 ошибки исчезнут, если исправить первую. Что-то не так инклудишь. Можешь написать (DWORD) вместо (DWORD_PTR), на 32х-разрядной системе ничего не потеряешь.

[Hadron]

В этом случае появляется сообщение о фатальной ошибке.

Flenov5P.obj : error LNK2001: unresolved external symbol __imp__mciSendCommandA@16
Debug/Flenov5P.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

[resource]

Мда. Таким образом мы возвращаемся к твоему собственному вопросу-ответу №5. Действительно не линкуется Winmm.lib. Что конечно крайне странно, если ты, как было сказано, написал #pragma comment(lib, "winmm.lib")

[Hadron]

// Flenov5P.cpp : Defines the entry point for the application.
//

#pragma comment(lib, "winmm.lib")
#include "stdafx.h"
#include "resource.h"
#include <shellapi.h>
#include <mmsystem.h>
код был написан в самом начале .сисипишника

[resource]

.сисипишника 

Если серьезно, то просто нет вариантов почему не линкуется. Я бы попробовал собрать, но у меня студии нет. Если кто согласится этим заняться, то выкладывай и будем разбираться

[Алексей++]

самое первое -
#include "stdafx.h"

поместить в самое начало файла cpp

[resource]

Алексей1153++, я всегда либы в самом начале прописывал, и всегда работало.

[Hadron]

#include "stdafx.h"
#include "resource.h"
#include <shellapi.h>
#include <mmsystem.h>
#pragma comment(lib, "winmm.lib")

теперь пашет, спасибо!!

[Алексей++]

resource, это хитрая штука - предкомпиленные заголовки ) Если пз включены - то даже глобальные дефайны проекта видны только после #include "stdafx"
Вот я и предположил

[resource]

Не понимаю почему так происходит

[Алексей++]

не поверишь, я тоже ))) Давно забил и смирился

[resource]

в общем пока что это останется для меня случаем из серии"просто так надо". Ну чтож, бывают такие. Придется тоже смириться.

[Антон (LogRus)]

могу вам предложить в качестве ответа такую цепочку:
1. stdafx.h уже скоппилирован
2. любая директива препроцессора перед #include "stdafx.h" потенциально может изменить результат включения #include "stdafx.h", т.е. результат компиляции stdafx.h может отличается от результат включения #include "stdafx.h" при отсутствии PCH
3. как следствие пункта 2, все директивы препроцессора перед #include "stdafx.h" вредны и опасны при использовании PCH
4. как следствие пункта 3, игнорируем всё, что перед #include "stdafx.h"

[Алексей++]

 - что и было доказано на практике )

[resource]

LogRus, ну это всё конечно хорошо, но понимания если честно не добавило, т.к. довольно поверхностно. Пункт 2 весьма самобытный и всё объясняет  , но это опять же "прими как есть и успокойся", объяснений не жди. Я вот тут еще понял, что я используя PCH, оказывается мало что (или вообще ничего) про них знал.

[Алексей++]

resource, это магия от MS (c (c (c))) )))

[resource]

Алексей1153++, пожалуй это самое реальное объяснение 

[Вад]

Это не магия, а самая обычная плата за скорость компиляции.

В MS могли бы пойти ещё дальше - автоматически (неявно) включать stdafx.h в начало каждого модуля, у которого выставлен PCH. Но этор это недостаточно наглядно, может приводить к ошибкам и не избавляет от проблемы двусмысленного положения директив препроцессора, заданных для модуля в виде опций компиляции (и соответствующей опции в свойствах модуля в дереве проекта или в глобальных директивах для всего проекта).

То есть, с одной стороны, есть прекомпилируемые заголовки - то есть такие, которые компилируются до всех остальных модулей. А с другой стороны, включение этих заголовков конфликтует с тем, что у каждого модуля могут быть свои директивы препроцессора, заданные как в коде, так и напрямую в виде опций компиляции.

И программист, по идее, ожидает, что эти самые директивы будут проникать во все инклуды, как это и полагается. Но stdafx - это, разумеется, не "все инклуды", раз уж оно включает уже скомпилированный код. И, разумеется, stdafx игнорирует все дефайны.

Решение MS - лишь наименьшее зло в попытке нанести минимальный ущерб нормальной логике трансляции и наглядности происходящего при использовании прекомпилируемых заголовков. То есть, это попытка сделать удобно в ситуации, которую язык C++ изначально не предусмотрел (и в этом изъян конструкций языка).

Если есть более удачные решения, как реализовать PCH - хотелось бы услышать Думаю, MS тоже только спасибо скажет.

[Алексей++]

Да где уж нам уж перещеголять MS
Прочувствовали, учли.

[resource]

И, разумеется, stdafx игнорирует все дефайны

Дык я вот это и не понимаю. Ну и пускай он их игнорирует. Вот вопрос почему директивы игнорируются в пределах модуля c/cpp. Зачем так надо было делать. Или же они впринципе глобально игнорируемы после включения stdafx (насколько я понял, так и получается). Не понимаю о каких  попытках нанести минимальный ущерб тут можно говорить. Надо было игнорировать только в пределах stdafx и всего что в нем, а дальше опять включить все указанные программистом директивы.

[Вад]

То, что stdafx их игнорирует - уже ненормально. В этой ситуации самым естественным мне видится правило "пиши stdafx в самом начале всегда" - уже хотя бы по соображениям, что нечего что-то делать с препроцессором, прежде чем прекомпилированная часть будет включена.