• 0

[C++][MSVC] Cannot resolve this Linker error LNK2019, DirectX related


Question

Okay guys and gals, I am absolutely 100% stumped on this one. I genuinely cannot seem to resolve this one. I've been trying for 5 days, experimenting, googling, all to no avail. I usually like to solve my own coding problems and try for as long as I can to resolve it, but this time I need some outside advice!

Basically, I'm using DirectX for my input. I have a CInput class using dinput.h to grab keyboard inputs. My compiler is MSVC++ 2010.

CInput.h


// input.h: interface for the Cinput class.
//
//////////////////////////////////////////////////////////////////////
#if !defined(AFX_INPUT_H__9F947E83_2A3B_4B63_8675_83B41506943E__INCLUDED_)
#define AFX_INPUT_H__9F947E83_2A3B_4B63_8675_83B41506943E__INCLUDED_
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
#include <windows.h>
#define DIRECTINPUT_VERSION 0x0700
#include <dinput.h>

class CInput
{
private:
static CInput * _instance;
protected:
CInput(void);
public:
static CInput * Instance();
virtual ~CInput();
void GetInput();
bool GetIfKeyDown(int whichkey); //true as long as key still down
bool GetIfKeyDownEvent(int whichkey); //occurs only when key first pressed
};
#endif // !defined(AFX_INPUT_H__9F947E83_2A3B_4B63_8675_83B41506943E__INCLUDED_)
[/CODE]

CInput.cpp

[CODE]
// input.cpp: implementation of the Cinput class.
//
//////////////////////////////////////////////////////////////////////

#include "stdafx.h"
#include "Input.h"
#include <windows.h>
#include <OBJBASE.H>

extern HWND g_hWnd;
extern HINSTANCE hInst;
LPDIRECTINPUT lpdi; //pointer to direct input object
LPDIRECTINPUTDEVICE lpdikey; //the keyboard device
//storage for keyboard state
UCHAR keystate[256];
UCHAR oldkeystate[256];
bool keydown[256];
//////////////////////////////////////////////////////////////////////
// Construction/Destruction
//////////////////////////////////////////////////////////////////////
CInput::CInput()
{

if (DirectInputCreateA(hInst, DIRECTINPUT_VERSION, &lpdi, NULL)!=DI_OK)
{
// DirectInput not available; take appropriate action
}

//create keyboard device
if(lpdi->CreateDevice(GUID_SysKeyboard, &lpdikey, NULL)!=DI_OK)
{
//error
}
//set cooperation level
if(lpdikey->SetCooperativeLevel(g_hWnd, DISCL_BACKGROUND | DISCL_NONEXCLUSIVE)!=DI_OK)
{
//error
}
//set data format
if(lpdikey->SetDataFormat(&c_dfDIKeyboard)!=DI_OK)
{
//error
}
//acquire the keyboard device
if(lpdikey->Acquire()!=DI_OK)
{
//error
}

}
CInput::~CInput()
{
//unaquire keyboard
lpdikey->Unacquire();
lpdi->Release();
}
//this method refreshes the CInput class's data on which keys are currently down
//this data is stored in an array called keystate[ ]
void
CInput::GetInput()
{
//copy old keystate array
int i;
for (i=0;i<256;i++)
{
oldkeystate[i]=keystate[i];
}

if (lpdikey->GetDeviceState(256,keystate)!=DI_OK)
{
//error
}
//now check which keys are now down that weren't down last time
for (i=0;i<256;i++)
{
if ((keystate[i]>0)&&(oldkeystate[i]==0))
{
//key is now down and it wasn't before
keydown[i]=1;
}
else
{
keydown[i]=0;
}
}
}

//use this method with DirectX character constants
//which are defined in dinput.h such as DIK_SPACE
//relies on the GetInput( ) method being called first to
//update the data on which keys are currently down
//if this method doesn't seem to work then make sure you
//are calling GetInput( ) first!!!
bool
CInput::GetIfKeyDown(int whichkey)
{
if ((whichkey>256)|(whichkey<0)) return 0;
return (bool)(keystate[whichkey] & 0x80);
}
//method returns 1 or 0 depending on whether
//specified key has just been pressed
bool
CInput::GetIfKeyDownEvent(int whichkey)
{
if ((whichkey>256)|(whichkey<0)) return 0;
return (bool)(keydown[whichkey]);
}
CInput * CInput::Instance()
{
if (0==_instance)
{_instance=new CInput();
}
return _instance;
}
CInput * CInput::_instance=0;

[/CODE]

When I go to make a build, however, it compiles the code but throws up the linker error which I told you about. Here's my output from building:

[CODE]
1> Generating Code...
1>Input.obj : error LNK2019: unresolved external symbol _DirectInputCreateA@16 referenced in function "protected: __thiscall CInput::CInput(void)" (??0CInput@@IAE@XZ)
1>D:\Developer\ttSideScrollerWin32 - 2011 version\Debug\ttSideScrollerWin32.exe : fatal error LNK1120: 1 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
[/CODE]

From what I've read, LNK2019 usually gets thrown when something isn't being included in your project or hasn't been defined. However, the CInput Constructor has definitely been defined in my header, with both CInput.h and CInput.cpp included in my project. DirectX SDK is definitely installed, my Linker Input in my Project Properties includes dxguid.lib, dinput.lib and dinput8.lib. My VC++ Directories for Input and Libraries explicitly include DirectX SDK's folders for Input and Libraries. I've gone through everything I can think of, but everything seems to be in place. I presume it's some sort of compiler issue of some kind, and one that's probably beyond my expertise. However, I'm open to any suggestions. I'm returning to programming after a fair few months of inactivity and so I'm a little rusty, which probably hasn't helped me solve this issue.

So, please Neowin, help me!!!

2 answers to this question

Recommended Posts

  • 0

So.... yeah. I'm the world's biggest school-boy-erroring jackass.

Turns out, one small little thing I did right at the very beginning, which was re-naming dinput8.lib to dinput.lib in the very ignorant assumption would fix things, I forgot I did after I explored other avenues. Turns out, my code is pretty old now and was relying on an old version of DirectX SDK which used dinput.lib - which any DX programmer knows is pretty different to dinput8.lib (and both of which are pretty deprecated now anyway). A silly error made because I was rusty at coding. Installed a legacy version of DX which had dinput.lib, linked to that and it all compiles - thankfully. Of course, what I need to do now is re-write my Input class using a newer input library - anybody got any suggestions for input libraries in games? Just KB/M suppport is necessary but game controller support would be nice too!

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • I think you forgot there's a ugly huge bar carved in the top of the screen.
    • There won't be any major changes from beta to release.
    • Having been using Windows for 30 years and 3 Surface Pros in the meantime (4,6,9) and recently bought a 15" macbook air m4. The OS is indeed a big deal. Hardware wise the surface pro feels as nice as macbook air, but Windows...man it's it's own enemy now
    • 2013 to 2017...wtf, is Steve on the wacky tabacky? Never heard of this or this Nathan guy in Australia.
    • Dell says it can't be blamed for Windows Night Light breaking on its Arm PCs by Usama Jawad Night Light is a very handy feature that is available by default in Windows 10 and Windows 11. Essentially, when you toggle it on, Windows reduces the emission of blue light from the display which in turn decreases the stress on eyes and can potentially aid in better sleep too. While this feature generally works quite well, this hasn't been the case so far on some Dell PCs. Now, Dell has acknowledged the issue in a recently published support document. As the situation currently stands, Night Light does not work on the secondary display on certain Windows Arm PCs when an external monitor is connected to them. This happens on the following PC models: Inspiron 14 5441 Inspiron 14 Plus 7441 Latitude 5455 Latitude 7455 XPS 13 9345 Now, Dell has confirmed that this is not due to any hardware or software issue on its side, it's just a limitation of the Qualcomm Oryon chipset. In essence, this is a problem that is outside the control of Dell. What this means is that while customers can utilize built-in and third-party tools to adjust the color profiles of their displays, Dell can't really get Windows Night Light to work as-is on external displays connected to any of the Arm PCs listed above. The company has emphasized that there are no plans to support Windows Night Light on its existing Arm PCs, and that customers will just have to make do with what they have. However, this feature will likely work as designed with the "next generation" of Arm computers, which will presumably leverage a chipset that is not held back by this limitation. Windows on Arm has enjoyed decent support from software developers in recent times; Microsoft will be hoping that it can keep the momentum going with its next Snapdragon PCs.
  • Recent Achievements

    • Week One Done
      moojay67 earned a badge
      Week One Done
    • Dedicated
      lethalman earned a badge
      Dedicated
    • Week One Done
      B4dM1k3 earned a badge
      Week One Done
    • One Month Later
      adnan.hebibovic earned a badge
      One Month Later
    • Week One Done
      adnan.hebibovic earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      595
    2. 2
      ATLien_0
      219
    3. 3
      Michael Scrip
      198
    4. 4
      +FloatingFatMan
      144
    5. 5
      Xenon
      135
  • Tell a friend

    Love Neowin? Tell a friend!