I need read data SQLite into Excel. And I found a few solution at (#1, #2). I choose SQLite for Excel of #Govert. My excel is 64bit version, so i've downloaded and replaced sqlite3.dll(32bit) by sqlite3.dll(64bit) then update the VBA declares:
...Declare Function... change to ...Declare PtrSafe Function...
But I'm still cannot run demo Module1.MyTestSQlite in SQLiteForExcel.xls . And error output in VBE Immediate Window:
SQLite3Initialize Error Loading
C:\Users\davuz\Downloads\SQLiteForExcel-0.7\Distribution\SQLite3_StdCall.dll:
193 Error Initializing SQLite. Error: 193
How to fix sqliteforexcel to run with Excel 64bit?
Thank for help?
I (the SQLite for Excel guy) haven't actually tried to figure out the 64-bit VBA declarations yet - I just noted that there is now a pre-compiled SQLite library for 64-bits, which helps us a lot.
First thing to note is that for the 64-bit case you don't need the SQLite3_StdCall.dll intermediate at all. It is just required for 32-bit case where the calling conventions need remapping. So for 64-bit all the .dll references in the VBA file must directly refer to SQLite3.dll.
Next, I think you are on the right track with the PtrSafe changes. But I am not sure exactly how the VBA 64-bit pointers declarations work. One would also have to figure out which of the 'Long' arguments are actually pointers.
So there's still a bit to do...
Edit:
Done. The updated version 0.8 of SQLite for Excel now includes the VBA declarations for 64-bit Excel, updated tests and a copy of the 64-bit SQLite3.dll.
Related
I want to read the code, more like variable and function names since I can catch values with CheatEngine, of an exe file. I got information about the file from Exeinfo PE which told me
"Microsoft Visual C++ ver. 8.0 / Visual Studio 2005 [ Debug:02 ]"
a screencap from Exeinfo PE
I have identified the code in assembly in some ways using IDA, radare2 and CheatEngine's Memory Table.
I don't know what else I can list so ask me if you need further details. thank you very much.
I believe your question is:
How to view the function and variable names of a compiled program?
When compiled in debug mode, some information will be present in the binary. If there is a .pdb it will contain additional debug information as well.
But when compiled in release mode, C++ itself does not compile in a way in which it retains any variable names or function names or other identifying information such as this.
The only exception to this is RTTI or Run Time Type Information. RTTI you can think of like symbol names for virtual functions. Microsoft Visual C++ predominantly does this but other compilers can as well. RTTI can be parsed and it will give you the class names in relation to the their virtual function tables. If the class does not have virtual functions, you will not find RTTI for it.
The best tool I know of for parsing RTTI is Class Informer which is a plugin for IDA Pro.
Recently upgraded to a new PC with Win 10 pro, Excel 2016 coming with Office365, vs2015 community. Built a very simple vc++ dll with just one function exported in def file. The code is very simple but would still post here to give a content and make sure there's no problem there.
//also tried __declspec(dllexport) double sumCPP(double a, double b) without .def file
double __stdcall sumCPP(double a, double b)
{
return a + b;
}
'VBA
Public Declare PtrSafe Function sumCpp Lib "C:\MyTestProject\x64\Debug\DllTest.dll" (ByVal a As Double, ByVal b As Double) As Double
But a call from VBA results Run-time error '48': File not found: C:\MyTestProject\x64\Debug\DllTest.dll.
The source code of a more complicated dll project can be built to exe that runs fine, but whose dll prompted this original failure calling dll problem. Any suggestion where to look at? I've tried depends.exe with many supposedly false alarms and dumpbin /dependents but not clear how to use the result. I wonder if this is related to some vs2015 redistributable not in system PATH. I don't see any there but haven't tried to add them yet, as there seem to be too many.
Is there any other option to delegate heavy computation and TCP/IP socket besides using vc++ dll? I don't know but can consider C#, while python would be preferred. Since those dll functions are intended to be called many times in VBA, a system call to vc++ exe doesn't seem to be efficient.
Great thanks in advance!
Since the machine is new so I reset it removing all data. Then I installed Office 2016 64bit and VS Community 2015 from scratch and built the 64bit dll again. This time the error is Run-time error '453' Can't find DLL entry point. Can't find any obvious missing dependent dll by either dumpbin.exe /dependents or depends.exe.
Try change build configuration from "Debug" to "Release"
I've generated a win32com wrapper for a DLL and I'm trying to access it. It works except for one function called ReadPipeBytes. It works on two of my other machines but I'm using a different python version. This is the error:'' object has no attribute 'ReadPipeBytes'. I copied over the same dll to the other machine (its a driver, I have the same hardware I'm trying to access.) I did a compare on the wrapper files and they are almost identical except for the python versions they were generated with and the 3.3.5 generated version doesn't put u'FunctionName' where the 2.7 version does. If I copy over the wrapper file to the machine that doesn't work I get the same error (and/or the dict file).
1) Why would the version of python make a difference in reading this one particular function when the other function work fine (its not the wrapper?
2) How can python fail to use the function called readpipebytes when the other functions work and when I'm using the same files that I do on my other machines?
When you use com the language you are accessing it from needs the same "bittedness" as the com .dll or control. So If you have a 32-bit control or com dll you have to have a 32 bit win32com.
I have a C++ ATL COM adding that implements some utility functions that refer to the Excel API:
void DoSomething(CComPtr<Excel::Range> &masterCell)
{
// ...
CComPtr<Excel::Range> cell = masterCell->Offset[vertical][horizontal];
// ...
}
When compiling an excel addin for x64 I'm getting lots of spurious errors such as:
cannot convert from 'Excel::Range' to 'ATL::CComPtr<T>'
However, when I compile for Win32 there is no problem. The helper utility functions are not exposed as excel UDF's so I don't think this question is applicable since the function does not have a STDMETHODIMP part.
Any ideas?
Thanks in advance.
CComPtr accepts an interface as a template argument, while Range is dispinterface. You need CComPtr<Excel::IRange> instead.
Doh! Turns out that I was trying to reference a 32-bit excel installation in a 64-bit build:
https://social.msdn.microsoft.com/Forums/en-US/f069ea06-b888-47c0-9ec8-c6cf8a59d9b1/atl-errors-compiling-64bit-com-excel-addin?forum=exceldev
Installing 64-bit excel fixed the issue.
I saved my VB-Express code as .dll and registered it with regasm and made a .tlb file.
But when I try to run a function from it in an Excel-modul I get: Run-time error ‘453’: Can’t find DLL entry point RegisterServiceProcess in kernel32
What step did I miss?
See http://richnewman.wordpress.com/2007/04/15/a-beginner’s-guide-to-calling-a-net-library-from-excel/
or better still try out ExcelDNA ( http://groups.google.com/group/ExcelDna )
I think you're creating a .Net dll and trying to call it from a COM-oriented environment (VBA), which isn't going to work without help. If I'm guessing right, then you need to investigate the COM Interop elements of .Net: Google throws up lots of promising-looking links, one of which is this article.
It looks a bit unpleasant, but I expect the nastiness can be tucked away somewhere...
Try this Microsoft Knowledge Base article: Can't Run Macro That Calls 16-bit DLL in 32-bit MS Excel.
Do you have the proper rights to access the DLL?
Thanks for the input to everybody, you helped me a big step further.
After following the guides you provided I got: Run-time error: '-2147024894' (80070002)': File or assembly name AssemblyName, or one of its dependencies, was not found.
But I could fix that with this Workaround.