Currently I am working on an old VB6 app to be compatible with UNICODE.
This app has SSTab and within this tab, there are user control q1, q2, q3 and so on.
For q1, it has the following code:
Private WithEvents q1 As VBControlExtender
Private progID As String
procId = “ALCTX10.CTX10.1”
Set q1 = Controls.Add(procId, “q1”)
myTab.tab = 1
q1.Move borderSize, topMargin, myTab.Width - borderSize * 2, _
myTab.Height - borderSize - topMargin
q1.Visible = True
The procId is referring to VC++ 6 DLL. All user controls are using this DLL.
For VC++ 6 DLL, I added ",_UNICODE, UNICODE" into the preprocessor definitions under the project setting of VC++ 6.
And compiled the DLL again and then brought it back to VB6.
The problem is I am still getting the same UNICODE issue from VB6 app.
I am using a foreign version of Windows XP so it is not the font problem.
I can’t just replace this DLL with UNICODE supported TextBox or RichTextBox since there are too many things going underneath the DLL.
I would appreciate very much if anyone sheds a light on this problem. Thanks.
Related
I've been working with c++ for little over 10 years now, and I have situation where I have to develop vb.net dll for Excel vba, so I have been teaching myself vb.net - it's bit, I must say, curious language.
Now here is problem that I have. I have compiled a small vb.net code, and I was able to reference through Excel vba. However, when I wrote vba and tried to test it, I get "#value" error from Excel.
Here is the codes.
[vb.net]
Public Class myDll
Public Sub WriteSomething()
MsgBox("Hello, World")
End Sub
End Class
And this is the vba side.
Public Function TestingDll() As Integer
Dim x As New DLLTest.myDll
x.WriteSomething()
TestingDll 0
End Function
Now I checked with "Object Browser", and it seems like Excel does not see any member of class. Now I have looked through to see if I can find any solution. And mostly what I found are related to GUID. Does anyone has better idea than using GUID? I don't want to use GUID because I have never used it before.
The setting on VS2019 was set as "Any CPU" for target machines. After changing it to "64 bit" - since the target Excel was 64 bit - it works like charm.
I have a VB6 DLL that's been working fine for many years and many versions. It is used from an Excel add-in.
To make it compatible with 64-bit Excel, I want to convert it to a VB6 ActiveX EXE. I did so, but now when I try to instantiate it from the client (same version of Excel; 2016), I get an error. This is the error the client returns:
Automation error
The specified module could not be found.
My understanding is that the ActiveX EXE should have been automatically registered when it was compiled, but I also tried registering it by double-clicking it to run it, and also by manually registering it with regserver. But I still get the same error.
In the client, here's the line I run to instantiate the VB6 ActiveX EXE; this is exactly the same as how it successfully instantiated it when it was a VB6 DLL:
Dim abc As Object
Set abc = CreateObject("ABC.cls_abc")
The class module's Instancing is set to MultiUse, and Persistable is set to NotPersistable.
I searched regedit for ABC.exe, and it was there.
Any suggestions?
UPDATE:
I tried changing the ActiveX EXE's project name and class name, and it worked.
I changed the project name from ABC to ABC64, and I changed the class name from cls_abc to cls_abc64.
Then from Excel I instantiated it like this:
Set abc = CreateObject("ABC64.cls_abc64")
I tried changing it back to ABC and cls_abc, and changing it back to an ActiveX DLL. I had deleted the DLL, so I compiled it again. Then I tried instantiating that from Excel with Set abc = CreateObject("ABC.cls_abc"), and that worked fine.
So the project works as an ActiveX EXE if I change the project name and class name, and it works as an ActiveX DLL with the old project name and class name, but doesn't work as an ActiveX EXE with the old project name and class name (I haven't tested changing only one or the other). Does this suggest I have a problem in the registry?
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 ask for a simple vba code to import a C string (null terminated) into Excel 2013 64
I have a C dll (compiled with Visual Studio 2015 for x64, strings set to Multi-byte) which exports several methods like this
__declspec(dllexport) char *MyMsg()
{
return(mymsg);
}
(function body is much more complex)
when working with C, C#, VB net codes etc. I have no problems to call these methods,
some, as C# , may require some additional conversion but methods work and don't crash (most important),
[DllImport(#"D:\my.dll", EntryPoint = "mymsg", ExactSpelling = false, CallingConvention = CallingConvention.Cdecl)]
[return:MarshalAs(UnmanagedType.LPStr)]
internal static extern string ErrMsg()
with old versions of Excel I was able to import as string (stable solution, no problems at all)
however it seems that with Office 2013 developers have modified some things and the old methods now, in Excel 2013 64 (and 2016), can generate exceptions stopping working,
I have tested different vba code (for example the code suggested to import from system dll) with very limited success,
std. debugging tools as Windbg etc. may report memory corruption or equivalent critical exceptions.
I have also considered to modify the C code in order to export a different object but I noticed that Variants in Excel 2013 64 may become very unstable possibly due to different deallocation policy, so I stopped this way,
honestly, as very personal opinion I am reluctant to adopt OLE objects and I would prefer to maintain the actual code in C dll,
your help will be very appreciated,
thanks.
a quick update about this question,
discussing the topic with other developers
I decided to test the way suggested by Microsoft,
calling from VBA and passing a pointer to a String,
herebelow the C code for the two alternatives which I have tested,
I regret to say that in both cases when stressed Excel 2013 64 stops generating an allocation error in VBE7 module (detected by Windbg and Visual Studio 2015)
by the way, the same works fine with Excel 2010 64 and there is little to add...
now, if some microsoft expert can help suggesting a C++ code tested with Excel 2013 64 that will be very appreciated,
differently I would suppose there is something not working as expected (at least in my copy of) Excel 2013 64
__declspec(dllexport) int WINAPI mymsg(BSTR *vbstr)
const char *lpszA = "test Excel 2013 64";
// Alternative 1
// SysFreeString(*vbstr);
// int nLen = MultiByteToWideChar(CP_ACP,0,lpszA,strlen(lpszA),0,0);
// *vbstr = SysAllocStringLen(0,nLen);
// MultiByteToWideChar(CP_ACP,0,lpszA,strlen(lpszA),*vbstr,nLen);
// alternative 2
SysFreeString(*vbstr);
int nLen = strlen(lpszA);
wchar_t *lpszW = new wchar_t[nLen+1];
mbstowcs( lpszW, lpszA, nLen+1);
*vbstr = SysAllocString(lpszW);
delete[] lpszW;
}
I have a sample solution that has a different "test" icon on one of the test projects, but not on the other two.
I thought that maybe the project type guid was different on this project, but in the solution file they all have the same project type (C#)
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "DomainModel.Tests", "DomainModel.Tests\DomainModel.Tests.csproj", "{61A4733D-4C5B-4705-98CB-8048751BBEFA}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Extensions.Tests", "Extensions.Tests\Extensions.Tests.csproj", "{1D6AA1C5-1FEC-44E4-9258-ACF84A20353C}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Repository.Tests", "Repository.Tests\Repository.Tests.csproj", "{248434B7-3690-4705-85F0-66B765AEB431}"
EndProject
And in each project file they have idential project types (Test and C#)
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Why does DomainModel.Tests have the correct test icon, but Extensions.Tests and Repository.Tests have a plain C# library icon?
This can also happen in VS2013 when starting with a class library project and then adding test classes from there.
Adding the following child node to the main PropertyGroup node in the project file fixes the icon in this case:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
This is fixed in the Visual Studio 2013 preview.
This problem isn't fixed in VS2012 Update 2 (VS2012.2).
I would expect that it will be fixed in the next version of Visual Studio if it isn't fixed in a quarterly update before then. With all of Microsoft moving to shorter release cycles (approximately 12 monthly) then we shouldn't have that long to wait; at least not compared to how long we've had to wait in the past! :-)