0

I'm trying to import an XE5 project over to C++Builder 10.2. I used the first example in the XE5 project and it ran fine. I've built this project from scratch starting with New VCL Project, then just added all my cpp files and forms to the project and am now trying to compile it.

The original code is this:

extern "C++" __declspec(dllimport) HID_SMBUS_STATUS HidSmbus_GetNumDevices();
//load the library dynamically
HINSTANCE load = LoadLibrary("SLABHIDDevice.dll");

I get a compile error that says:

libloaderapi.h(648): candidate function not viable: no known conversion from 'const char [18]' to 'LPCWSTR' (aka 'const wchar_t *') for 1st argument

That worked in XE5 on the same computer so I don't understand why I'm getting that error in 10.2.

I then tried this to comply with the error:

extern "C++" __declspec(dllimport) HID_SMBUS_STATUS HidSmbus_GetNumDevices();
LPCWSTR a;
*a = "SLABHIDDevice.dll"; 
HINSTANCE load = LoadLibrary(a);

But there is something wrong with my syntax that I don't understand as I get this error now:

[bcc32c Error] worksurface.cpp(73): C++ requires a type specifier for all declarations

I thought I had declared 'a' in the line above it, so I don't understand that. In any case, I then tried to load the library statically instead of dynamically by doing this instead:

#pragma comment(lib, "SLABHIDDevice.dll")
extern "C++" __declspec(dllimport) HID_SMBUS_STATUS HidSmbus_GetNumDevices();

But then I get the following error:

[ilink32 Error] Error: Error processing module (path)\SLABHIDDEVICE.DLL

In all cases, SLABDIDDEVICE.DLL is in the project directory.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Buckethead
  • 1
  • 3
  • Your XE5 project is configured with [`_TCHAR maps to`](https://docwiki.embarcadero.com/RADStudio/en/TCHAR_Mapping) set to `char` but your new project (BTW, there is no XE10) is configured with it set to `wchar_t` instead. So, either change the setting back to `char` (not recommended) or else change `LoadLibrary("SLABHIDDevice.dll")` to either `LoadLibraryA("SLABHIDDevice.dll)` or `LoadLibraryW(L"SLABHIDDevice.dll")` or `LoadLibrary(TEXT("SLABHIDDevice.dll"))` – Remy Lebeau Nov 13 '22 at 18:47
  • Thank you very much for the quick response. That seemed to work with regard to that compiler error, and now I just get the Link error I described above "[ilink32 Error] Error: Error processing module (path)\SLABHIDDEVICE.DLL". This worked in XE5 and I'm using the same computer and OS, so I don't know why I would now get this error. Any idea? Thanks. – Buckethead Nov 13 '22 at 22:06
  • Your code is using `#pragma` to statically link directly to the DLL itself. That will never work, in any compiler, so get rid of that. You have to link to the DLL's import `.lib` instead. But that defeats the point of using `LoadLibrary()`. So, use one or the other, not both. – Remy Lebeau Nov 13 '22 at 23:19
  • OK Great. The program now compiles Upon running an error dialog shows "code execution cannot proceed because SLABHIDTOSMBUS.DLL was not found. reinstalling program may fix". Both SLABHIDDEVICE.DLL and SLABHIDTOSMBUS.DLL are in project directory. Mfg says that SLABHIDTOSMBUS is a library file but that that SLABHIDDEVICE.DLL is required during run time. I have the header SLABCP2112.h in there and I did "add to project" for a slabhid.lib file which is how I had everything in XE5. Am I missing a setting in the environment? – Buckethead Nov 14 '22 at 15:31
  • The project directory is likely different than the working directory at runtime. Modern Delphi versions output the compiled EXE in a subdirectory by default. The DLLs should be in the same directory as the compiled EXE, or at least in a directory on the [OS search path](https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order). – Remy Lebeau Nov 14 '22 at 15:53
  • OK great, that fixed all the DLL loading problems. It almost ran, but then the program halted with a message "access violation error, read of address...". Closing this takes me right to the CPU and the thread that was executing is Embarcadero\studio\20.0\bin\cc32c260mt.dll This problem looks eerily similar to the access error I was getting in XE5 on a slightly different thread but in the embarcadero directory for xe5. I need to experiment and try a few things on a new computer. So I'll see what happens and report. This program ran fine under XE5 until XE5 just broke one day & can't fix. – Buckethead Nov 15 '22 at 01:23
  • That error is due to a mistake in your code. Probably a mismatch in how you declared the DLL functions, or in the data you are passing to it. – Remy Lebeau Nov 15 '22 at 01:47
  • In XE10 (sorry, I mean Builder 10.2) I tried putting a breakpoint at the very first line of code ("Application->Initialize();"), but it shows access error even before getting to that line, so it seems (maybe?) its not in my code. I've been experimenting, put XE5 and 10.3 on a new laptop and copied the whole project to a directory there and (yea!!!) it runs and compiles on XE5 on the laptop, so I'm not completely dead in the water. I can't go back to xe5 on my preferred desktop as XE5 (even with a new project) gives me a write access error. (continued as won't let me type more).. – Buckethead Nov 18 '22 at 07:10
  • ...One very odd thing about XE5 though and the desktop is that the error call stack shows Embarcadero\Studio\21.0\bin\CC32C260MT.DLL. But how can that be when 21.0 is C++Builder 10.3 It should say 12.0. If I can solve that I might be able to get XE5 to work again on my desktop and get my project to work under XE5 and I'll be back in business. And now that I looked, the read access error I'm seeing in C++ 10.3 (the one we've been working on) shows Studio\20.0\.... That should say 21 no? These 3 compilers I have on my desktop (XE5, 10.2, 10.3) seem to be confusing folders. – Buckethead Nov 18 '22 at 07:19

0 Answers0