I can build samples such as devcon using "build", but whenever I try a
simple test using this one function in VC++ I get a linker error;
devcon2-cg error LNK2001: unresolved external symbol "void * __stdcall
SetupDiGetClassDevsExA(struct _GUID const *,char const *,struct HWND__
*,unsigned long,void *,char const *,void *)"
(?SetupDiGetClassDevsExA@@$$J228YGPAXPBU_GUID@@PBDPAUHWND__@@KPAX13@Z)
In Tools->Options I have the extra link library path set to
C:\WINDDK\3790\lib\wxp\i386
The includes path is set similarly and would appear to be correct because it
does compile.
I have the same in the Linker->Additional Library Diectories in the
properties of the project.
Switching the linker to verbose reveals that lib files are being loaded from
the directory in which setupapi.lib resides. I know it is there because I
can see it with the "dir" command. Why is the VC++ linker not finding it?
The string "setupapi.lib" does not appear in the verbose linker output. It
is as if it does not know to look in setupapi.lib. Is there a way of forcing
it to look at specific lib files as well as specific directories?
--
Dr. Craig Graham, Software Engineer
Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/
Well, MS telephone support got this bit sorted out- there was indeed a field
in which I had to explicitly specify the name of the .lib file- under
Project Properties->Linker->Input, named "Additional Dependencies" or
somesuch as I recall.
The project now builds and links, however on running it I have another
problem that hasn't gone away after a few hours of playing.
This snippet is the bulk of my litle test;
HDEVINFO devs = INVALID_HANDLE_VALUE;
devs = SetupDiGetClassDevs(NULL,
NULL,
NULL,
DIGCF_ALLCLASSES);
I've shifted from the Ex version to simplify things. SetupDiGetClassDevs is
returning nothing. It's not leaving devs set to INVALID_HANDLE_VALUE- VC++
shows it as simply "{void}". A subsequent call to GetLastError returns 127,
which is apparently "Procedure call not found". I've tried several different
functions and got the same result.
Does anyone know what is going on?
>
> I've shifted from the Ex version to simplify things. SetupDiGetClassDevs
is
> returning nothing. It's not leaving devs set to INVALID_HANDLE_VALUE- VC++
> shows it as simply "{void}". A subsequent call to GetLastError returns
127,
> which is apparently "Procedure call not found". I've tried several
different
> functions and got the same result.
>
> Does anyone know what is going on?
>
Not sure exactly what's going on, but ERROR_PROC_NOT_FOUND indicates that
there may be some dependency problem. I suggest running depends.exe on
your application to further investigate.
--
Arjun Bijanki, Microsoft Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
> > returning nothing. It's not leaving devs set to INVALID_HANDLE_VALUE-
VC++
> > shows it as simply "{void}". A subsequent call to GetLastError returns
> 127,
> > which is apparently "Procedure call not found". I've tried several
> different
> > functions and got the same result.
> >
> > Does anyone know what is going on?
> >
>
> Not sure exactly what's going on, but ERROR_PROC_NOT_FOUND indicates that
> there may be some dependency problem. I suggest running depends.exe on
> your application to further investigate.
It seems that all was actually fine. A very helpful MS tech support guy
solved a multitude of problems along the way to getting this working, and in
the end sent me the "devcon" source as a Visual Studio project, ready to
build and play with. It turns out the function was working as expected but
there are problems seeing the result in the Visual Studio debugger; in the
devcon project I get an "unable to evaluate" error, and in my test I just
get void. The fact it doesn't leave it set at INVALID_HANDLE_VALUE means it
has worked, and subsequent functions further down the line work. I just
wasn't trying anything further down the line because I thought I was failing
right at the start.
And because it has worked, the results from GetLastError are meaningless.
It's quite a nasty red herring that it gets set to 127 by the function.