[C++ | Excel] Probleem met argumenten doorgeven aan functie

[TeXiCiTy]

Probleem:
Ik wil een C++ functie gebruiken binnen excel middels een DLL. Ik krijg het echter niet voor elkaar om de argumenten goed door te geven. Het minimale voorbeeld waarbij het probleem ontstaat, heb ik gevangen in onderstaande code. Excel versie is 2010 64-bit en de DLL wordt ook als x64 gecompileerd.



De code in C++:

C++: main.cpp

extern "C" __declspec(dllexport) int getNumber();
extern "C" __declspec(dllexport) int doubleNumber(int inputNumber);
extern "C" __declspec(dllexport) int doubleNumberFake(int inputNumber);

int getNumber()
{
    return 1000;
}

int doubleNumber(int inputNumber)
{
    int outputNumber = inputNumber * 2;
    return outputNumber;
}

int doubleNumberFake(int inputNumber)
{
    return 2000;
}

C++: main.def

LIBRARY "ExcelAddin"
EXPORTS
getNumber=getNumber
doubleNumber=doubleNumber
doubleNumberFake=doubleNumberFake

Visual Basic: VBA module code

#If Win64 Then
    Public Declare PtrSafe Function getNumber Lib "D:\ExcelAddin.dll" () As Long
    Public Declare PtrSafe Function doubleNumber Lib "D:\ExcelAddin.dll" (ByVal arg As Long) As Long
    Public Declare PtrSafe Function doubleNumberFake Lib "D:\ExcelAddin.dll" (ByVal arg As Long) As Long
#End If

Ik heb allerlei combinaties geprobeerd (as integer, as long, as longPtr), (ByRef, ByVal) maar overal blijft de uitkomst gewoon op 0 staan. Waarschijnlijk is het weer iets heel knulligs maar ik kom er niet uit... Iemand die zo ziet waar het mis gaat?

[Soultaker]

Ik denk sowieso dat als je je argument als Long definieert in VBA, dat je dan long (in plaats van int) in C++ moet gebruiken.

Verder misschien iets met calling conventions? Wat gebeurt er als je de C++ functies met __stdcall declareert?

[TeXiCiTy]

https://msdn.microsoft.co...a164506(v=office.10).aspx
Excel doet schijnbaar alles met Long, in alle voorbeelden online met 64-bit excel zie ik ook dat ze in C++ integer gebruiken en vervolgens in Excel Long.

In C++ integer vervangen door long helpt in ieder geval niet.

C++:

extern "C" __declspec(dllexport) int doubleNumber(int inputNumber); //function prototype
int doubleNumber(int inputNumber) { code } //function

vervangen door

C++:

extern "C" __stdcall int doubleNumber(int inputNumber); //function prototype
int __stdcall doubleNumber(int inputNumber) { code } //function

helpt ook niet. Output blijft al alle drie de gevallen gelijk.

Ik controleer steeds met dumpbin.exe of de functienaam er goed in zit;

    ordinal hint RVA      name

          1    0 00001010 doubleNumber = doubleNumber
          2    1 00001020 doubleNumberFake = doubleNumberFake
          3    2 00001000 getNumber = getNumber

[Voor 69% gewijzigd door TeXiCiTy op 20-03-2017 14:55]

[Soultaker]

Volgens deze doc is __stdcall in ieder geval noodzakelijk (of WINAPI? Is er een verschil?) maar misschien dat er nog wat anders mis is.

Heb je de mogelijkheid om een breakpoint te zetten by de aanroep van getNumber()? Dan kun je kijken of de waarde die je meegeeft (1000) ergens te vinden is, ofwel in een register, ofwel op de stack. Als de calling convention niet overeenkomt met wat Excel verwacht, kan het zijn dat de gegenereerde code naar een register kijkt terwijl het argument op de stack staat of vice versa.

(Ik gok dat de return value in beide gevallen in een register teruggegeven wordt dus vandaar dat dat wel goed gaat.)

[farlane]

Hoogst waarschijnlijk calling convention, zoals Soultaker al aangaf : in lang vervlogen tijden moest ik om dll's met VB(A) te kunnen interfacen ook stdcall calling convention gebruiken.

C++:

BSTR _stdcall make_string( LPCTSTR value, int len );

code:

LIBRARY TestDll
DESCRIPTION Blah

EXPORTS
        make_string     @1

Visual Basic .NET:

Declare Function make_string Lib "TestDll" (ByVal Blah As String, ByVal Length As Long) As String

Zou moeten werken.

[TeXiCiTy]

farlane schreef op maandag 20 maart 2017 @ 15:06:

Visual Basic .NET:

Declare Function make_string Lib "TestDll" (ByVal Blah As String, ByVal Length As Long) As String

Zou moeten werken.

https://msdn.microsoft.co...e691831(v=office.14).aspx
Voor de 64-bit versie dient daar dus nog wat aan versleuteld te worden

[TeXiCiTy]

Overstappen van Long naar LongPtr doet excel crashen... doubleNumberFake geeft wel netjes 2000 als output.

C++:

long __stdcall doubleNumber(long * inputNumber)
{
    long outputNumber = (*inputNumber) * 2;
    return outputNumber;
}

long __stdcall doubleNumberFake(long inputNumber)
{
    long fakeInput = 1000;
    return doubleNumber(&fakeInput);
}

Visual Basic:

Public Declare PtrSafe Function doubleNumber Lib "D:\ExcelAddin.dll" (arg As LongPtr) As Long

Om de aangeroepen DLL in mijn debugger te krijgen is een uitdaging op zich, zo ver ben ik nog niet.

[.oisyn]

TeXiCiTy schreef op maandag 20 maart 2017 @ 16:46:
Om de aangeroepen DLL in mijn debugger te krijgen is een uitdaging op zich, zo ver ben ik nog niet.

Dat is niet moeilijk. Gewoon attachen aan het Excel proces, breakpoint zetten in je code, en dan de functie laten aanroepen vanuit excel.

[Xiphalon]

[quote]TeXiCiTy schreef op maandag 20 maart 2017 @ 16:46:
[code=vb,0,255,]
Public Declare PtrSafe Function doubleNumber Lib "D:\ExcelAddin.dll" (arg As LongPtr) As Long
[/code]
Om de aangeroepen DLL in mijn debugger te krijgen is een uitdaging op zich, zo ver ben ik nog niet.
[/quote]
Klopt die PtrSafe retourwaarde van de functie? (als in, het type)

Ow wacht, visual basic sorry Het retourtype staat erachter uiteraard.

[Voor 12% gewijzigd door Xiphalon op 20-03-2017 17:04]

[TeXiCiTy]

Xiphalon schreef op maandag 20 maart 2017 @ 17:03:
[quote]TeXiCiTy schreef op maandag 20 maart 2017 @ 16:46:
[code=vb,0,255,]
Public Declare PtrSafe Function doubleNumber Lib "D:\ExcelAddin.dll" (arg As LongPtr) As Long
[/code]
Om de aangeroepen DLL in mijn debugger te krijgen is een uitdaging op zich, zo ver ben ik nog niet.
[/quote]
Klopt die PtrSafe retourwaarde van de functie? (als in, het type)

Ow wacht, visual basic sorry Het retourtype staat erachter uiteraard.

Existing Declare statements will not compile in 64-bit VBA until they have been marked as safe for 64-bit by using the PtrSafe attribute.

[.oisyn]

Het probleem moet wel een calling convention iets zijn. Waarschijnlijk pusht Excel ze op de stack, en verwacht je functie ze in registers, of andersom. Maar ik zou verwachten dat __stdcall dat zou fixen.

.edit: hmmm

quote: https://msdn.microsoft.co...255&MSPPError=-2147217396

On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.

Dat zou op zich moeten betekenen dat Excel (VBA) zich hier ook aan houdt.

.edit2: Hier staat wel iets over name decoration. __stdcall decorate de namen met een @ gevolgd door de totale grootte van alle parameters in bytes. Het is me niet helemaal duidelijk of de extern "C" dit voorkomt, maar volgens het voorbeeld moet je in je .def file dus zeggen:

code:

EXPORTS
    doubleNumber=_doubleNumber@4

[Voor 75% gewijzigd door .oisyn op 20-03-2017 17:24]

[Soultaker]

Maar dat verklaart toch niet waarom doubleNumberFake() wél werkt? Dat suggereert namelijk dat Excel de functie wel kan vinden, en ook de return value correct interpreteert, maar dat alleen het argument niet goed doorgegeven wordt.

[farlane]

LongPtr : A variable data type which is a 4-bytes data type on 32-bit versions and an 8-byte data type on 64-bit versions of Office 2010

Dat wil dus niet zeggen dat er automatisch adressen worden gepassed (long*) door Office: dat regel je met ByVal/ByRef in je VBA declaratie

[.oisyn]

Soultaker schreef op maandag 20 maart 2017 @ 17:51:
Maar dat verklaart toch niet waarom doubleNumberFake() wél werkt? Dat suggereert namelijk dat Excel de functie wel kan vinden, en ook de return value correct interpreteert, maar dat alleen het argument niet goed doorgegeven wordt.

Misschien zoekt hij wel naar beide, en deduceert hij de calling convention aan de hand van welke hij vindt? Het is een long shot hoor, daar ben ik het mee eens. Maar het lijkt me duidelijk een calling convention probleem.

Dat hij de return value goed interpreteert is overigens niet zo gek, die is niet afhankelijk van de calling convention. Resultaat staat gewoon in rax.

[.oisyn]

Oh, hier staat trouwens dat Long een 64 bits integer is. Dat is long long in C++. Voor 32 bits ints moet je Integer gebruiken in VBA en int of long in C++. Onder Windows althans .

[Voor 5% gewijzigd door .oisyn op 20-03-2017 20:35]

[farlane]

.oisyn schreef op maandag 20 maart 2017 @ 20:33:
Oh, hier staat trouwens dat Long een 64 bits integer is. Dat is long long in C++. Voor 32 bits ints moet je Integer gebruiken in VBA en int of long in C++. Onder Windows althans .

Da's raar, want hier staat een tabelletje die zegt dat er een LongLong data type is die 64bits is.

Iets erboven staat, bij de introductie van het LongPtr type:

And because the Long data type is always 32-bits ...

Misschien is er een verschil tussen VBA en Visual Basic op dat punt?

[.oisyn]

@farlane ik denk dat je gelijk hebt. Zo'n beetje alle sources hanteren Long als 32 bits in VBA.

[Voor 3% gewijzigd door .oisyn op 20-03-2017 21:52]

[farlane]

.oisyn schreef op maandag 20 maart 2017 @ 21:52:
@farlane ik denk dat je gelijk hebt. Zo'n beetje alle sources hanteren Long als 32 bits in VBA.

Ik vermoed dat het iets met VB(A)6 compatibility te maken heeft ...

[TeXiCiTy]

https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.

Dat schiet ook lekker op... Ik blijf aan het vechten met mijn exports.
https://msdn.microsoft.co...ry/aa235591(v=vs.60).aspx

[farlane]

TeXiCiTy schreef op dinsdag 21 maart 2017 @ 22:34:
Dat schiet ook lekker op... Ik blijf aan het vechten met mijn exports.
https://msdn.microsoft.co...ry/aa235591(v=vs.60).aspx

Dat is een stukje over VB6, waarschijnlijk niet meer helemaal van toepassing op jouw situatie want x64.

Even een zijsprong : heb je de mogelijkheid om er een COM dll van te maken? Waarschijnlijk gaat dat handiger interfacen met Office.

[.oisyn]

@TeXiCiTy Ja dat zei ik hier al: .oisyn in "\[C++ | Excel] Probleem met argumenten doorgeven aan functie"

Waar ik wel benieuwd naar ben is wat je debugger zegt wat er op de stack en in de registers staat direct na de aanroep van je functie.

[Voor 6% gewijzigd door .oisyn op 21-03-2017 22:48]

[TeXiCiTy]

COM DLL heb ik nul ervaring mee en lijkt me een behoorlijke kluif om aan te beginnen als ik wat rond zoek. De debugger en Attach to Process krijg ik ook niet echt aan de gang. "The breakpoint will not currently be hit. No symbols have been loaded for this document.”

Ik zit nu best wel op een punt dat ik eigenlijk geen idee meer heb waar ik mee bezig ben. Met alle 32-bit voorbeelden kan je in nog geen 10 regels code je C++ DLL laten babbelen met Excel VBA en visa versa, ik zou toch denken dat het voor 64-bit niet zo gruwelijk veel moeilijker moet zijn .

[.oisyn]

TeXiCiTy schreef op dinsdag 21 maart 2017 @ 23:25:
COM DLL heb ik nul ervaring mee en lijkt me een behoorlijke kluif om aan te beginnen als ik wat rond zoek. De debugger en Attach to Process krijg ik ook niet echt aan de gang. "The breakpoint will not currently be hit. No symbols have been loaded for this document.”

Ik zie in je VBA declarations dat je D:\ExcelAddin.dll laadt. Weet je zeker dat dit de laatstgecompileerde versie is? En zet ExcelAddin.pdb ook eens in D:\. Verder moet je even zorgen dat debug mode wel op "native" staat (kan volgens mij vanuit het attach to process scherm)

[farlane]

TeXiCiTy schreef op dinsdag 21 maart 2017 @ 23:25:
De debugger en Attach to Process krijg ik ook niet echt aan de gang. "The breakpoint will not currently be hit. No symbols have been loaded for this document.”

Denk dat het goed is om eerst dat aan de gang te krijgen.

Het handigst lijkt mij om je Excel sheet in dezelfde directory te zetten als je debug build van je dll, en je project zo in te stellen dattie bij het debuggen Excel opstart met als argument de bewuste Excel sheet. Op die manier weet je zo goed als zeker dat Excel in ieder geval probeert om de dll te laden die je probeert te debuggen.

Als dat werkt kun je eenvoudigweg een breakpoint zetten in je dll en vanuit VBA de functie aanroepen en kijken wat de argumenten zijn.

[.oisyn]

Ik wilde het zelf even proberen maar blijkbaar heb ik een 32 bit install van Office. En ze kunnen helaas niet side by side.

[farlane]

.oisyn schreef op woensdag 22 maart 2017 @ 10:02:
Ik wilde het zelf even proberen maar blijkbaar heb ik een 32 bit install van Office. En ze kunnen helaas niet side by side.

Heb hetzelfde probleem.

Ik heb wel even een snelle test gedaan met een .NET applicatie en dat werk eigenlijk prima (als je zorgt dat beide platformen op x64 staan ) maar zoals gezegd wijken de datatypes in VBA af van het .NET platform blijkbaar.

dll:

C++:

extern "C"
{
    int __stdcall Test()
    {
        return 1000;
    }

    long long __stdcall DoubleNumber( long long value )
    {
        return value * 2;
    }
}

.def:

code:

LIBRARY

EXPORTS
Test
DoubleNumber

Visual Basic:

Module Module1

    Public Declare Function Test Lib "DllDotNet.dll" () As Integer
    Public Declare Function DoubleNumber Lib "DllDotNet.dll" (ByVal arg As Long) As Long

    Sub Main()

        Dim a As Integer = Test()

        Dim b As Long = DoubleNumber(a)


    End Sub

End Module

[TeXiCiTy]

Ik zal eens kijken of een van onderstaande alternatieven mij het leven makkelijker kunnen maken.
https://sourceforge.net/projects/xlw/
http://xll.codeplex.com/

Rejoice, xlw vanuit de bron gebouwd en een .xll gemaakt die als add-in geladen kan worden en werkt . Het is niet zo lean_and_mean als wat ik in de openingpost ambieerde, maar ik kan ermee vooruit.

[Voor 35% gewijzigd door TeXiCiTy op 23-03-2017 20:38. Reden: Doel bereikt]

[farlane]

TeXiCiTy schreef op donderdag 23 maart 2017 @ 17:46:
Ik zal eens kijken of een van onderstaande alternatieven mij het leven makkelijker kunnen maken.
https://sourceforge.net/projects/xlw/
http://xll.codeplex.com/
Rejoice, xlw vanuit de bron gebouwd en een .xll gemaakt die als add-in geladen kan worden en werkt . Het is niet zo lean_and_mean als wat ik in de openingpost ambieerde, maar ik kan ermee vooruit.

Mooi voor je.

Jammer dat ik Office wel kan wurgen, anders had ik het zelf geprobeerd. Ben namelijk wel heel nieuwsgierig waar het nou fout ging bij je.

[schoene]

TeXiCiTy schreef op maandag 20 maart 2017 @ 14:38:
https://msdn.microsoft.co...a164506(v=office.10).aspx

C++:

extern "C" __stdcall int doubleNumber(int inputNumber); //function prototype
int __stdcall doubleNumber(int inputNumber) { code } //function

helpt ook niet. Output blijft al alle drie de gevallen gelijk.

Ik zie dat je hier "__declspec(dllexport)" vergeten bent. Dan is je functie extern niet toegankelijk?

[.oisyn]

@schoene Als ie dat vergeten was dan had hij ook geen output gehad

[schoene]

.oisyn schreef op vrijdag 24 maart 2017 @ 10:58:
@schoene Als ie dat vergeten was dan had hij ook geen output gehad

hmmm, iets te diagonaal gelezen vrees ik