Sorry your browser is not supported!

Hi guys... Is it me or are all the dll tutorials missing something?
I've tried the tutorial in the help file, the tutorials in the forums and I still cant get my dll to work in DBP.
The test dll bellow.


I've attached a string resource containing TEST?Test@@YAXXZ and compiled it using VC++ 6.0 - F7. This compiles fine with no errors and I can use this dll from another program written in C++ so I know it works.

I've copied the func.dll into the compiler\plugins-user directory snd writen a small program (bellow), to test it.

all I get at compile time is 'Could not understand command at line 1'
what am I doing wrong ?

when you are using DBPDLL put DBPDLL extern "C" __declspec(dllexport) . That may help.

@Benny53
I Tried that Benny, it didn't work either.
I've modified the DBP code,

this now throws an error Command in "Func.dll" command-table unrecognised (TEST?test@@YAXXZ)
if I click OK the program compiles and the Messagebox appears as expected.

Odd thing, If I remove the extern "C" the above mod stops working with a runtime error 9704 - Could not call DLL function at line 2 and just doing Test() returns could not understand command

You only use brackets if you are returning a value, which is why DBP says could not understand command.

DBP expect at least 3 sections in it.
name%parameters%export_name
When your function has no parameters (as is the case) use:
name%0%export_name

This is not a valid function name:

TEST?Test@@YAXXZ

This is:

?Test@@YAXXZ

Your resource string for this should be:

TEST%0%?Test@@YAXXZ

@Benjamin - I tried it with and without brackets, still didn't work
@TKF15H - Thanks for the info. Shame it's not documented.

Any idea why I can't create my ovn commands to be stored in the plugins-user directory.
I can Load my Dll in and Call the Functions it has but I'd like them to be available to all my projects and not to have copies everywhere.

Ok.. I've finaly figured it out
The tutorial is correct up to the IDS_STRINGS part.
DBP likes the strings like this
MyFunc1() - MyFunc1%0%?MyFunc1@@@@YAXXZ%0
int = MyFunc2() - MyFunc2[%L%?MyFunc2@@@@YAXXZ%0
int = MyFunc3(Int) - MyFunc3[%LL%?MyFunc3@@@@YAXXZ%Integer

I'm now off to write my missing function library dll (see ya'll next year)

Yes it is, at least to this level. Go to the main help in DBPro, click 'Technical documents' and then 'Third party commands'.

Oh, and all of your functions in that last post are wrong. As you add more arguments, the function names change. That's why Benny53 suggested using the extern "C" modifier on your functions.

@ IanM
It's those tutorials that don't work..

Adding the extern "C" helped but when you use this the dll has to be in the same directory as the application using it.

I'm also struggeling with the datatypes, why is it that DBP uses different datatypes to every other programming application?
e.g.
integers range -2147483648 to 2147483647 are long everywhere else.
integers range should be -32768 to 32767
real (as in the documentation) don't exist in DBP, it's a float.
The passing of these to and from dll functions is hillarious.

I like DBP (lot's) I just the little inconsistencies in it that are a pain in the A$$.

Anyway, Thanks to all the people who helped, I've managed to get my dll to work (after a fasion), I can move onto my next stage (World Domination) hehehaaa.

They do work, with all versions of VC++ - they're what I used to start with.

The extern "C" bit doesn't work like that. The *only* thing it does is to stop the compiler 'decorating' the filename.

On a 32 bit machine, ints are 32 bits in size. Only in 16 bit windows and dos were they 16 bits.

Real = float - it's not DBPro specific, other languages refer to reals (delphi) while others refer to floats. It's just one of the things you need to know when coding with multiple languages.

In fact, the only odd thing about DBPro's plug-in interfacing is the need to return floats as dwords.

No offence meant, but with the number of incorrect statements you've just made it's clear that you really need to learn to use the tools and information properly.

@IanM
The real/float part is definatly there in the datatypes documentation, they are refered to as 'real' and if you try typing in 'variable as real' it won't work, it has to be float.

I don't recal saying I was an expert in any language, If I was, I wouldn't be asking for help, would I? and using the DBP documentation can be missleading. It has defunct commands and no reference to some of the other commands, others don't fully describe the functionality of the command.

As for the string value, the documentation isn't near intuitive as you imply, there isn't any description on how to handle 'void' or how to use the modifier for 'float' so that internal dll functions work with dll functions calling them also.

Most of my comments, are what I'm personaly experiencing, finding solutions to these problems in the DBP help or the TGC forums isn't easy.

Saying that there are inconsistencies between all languages, sounds like a cheap cop-out to me. (no offence intended)

TinTin...I use the string resources as they are in the tutorial. Most are not NULL terminated in the docs...they are terminated with "@Z", like this one:
JZMAKETCPSOCKET[%LSLL%?jzMakeTCPSocket@@YAKPADHH@Z

jzDBCMD DWORD jzMakeTCPSocket(LPSTR hostaddr, int hostport, int bindHow)

You could probably terminate them in a variety of ways, but...this works for me, everytime. The way I do it is to compile the dll, and then open the .exp file, look for the mangled function name, and copy the relevant portion of that to the string table. btw, you cannot have other strings in that table, to my knowledge. It broke when I tried that, but...you can add resources in another rc file...rc2.

extern C is a linkage specifier, and as was already stated above, it prevents the usual C++ name-mangling...but, that is how you are
(sort of) exporting your functions to DBPro, so...
extern C does not apply to using DLLs with DBPro. DBPro uses the string table only, except for the DllMain, which is exported normally and the ReceiveCoreDataPtr thing that it already looks for on its own. It is not needed in order to "export" functions to DBPro...it is irrelevant to the issue you are having. Neither is it strictly necessary to export classes, like MSVC++ does in the DLL boilerplate code. The string table is the only way I know of....

I think it is an unfortunate choice of words to say real when you mean float. There are languages where real is an actual type, but DBPro is not one of them. Saying real implies that there is more than one type of real number in DBPro...I only see float...no double, etc. I also disagree with the notion that that somehow makes you less intelligent...maybe inexperienced compared to others, but...its all good.

No, the help file thing is not really that good. It starts out okay, then...it sort of nosedives. If I had to rely on that alone, I would be in worse shape than TinTin. Yes, it is better than nothing, and no...I don't expect my hand to be held, but...it would not take much to make it much better.

It is the compiler that determines the size of integer, not the processor. Integers have no size. Like real, integer only tells the type of variable, not its size. The word long is used to mean "long integer". The word short is used to mean "short integer". (Still, there is no size until the compiler determines it.) Yes, a short integer is 16 bits, and a long integer is 32 bits.

DBPro is not unique in this respect. Windows defines and redefines variable types all the time...look at windows.h, for example. Here are a few 32-bit Windows types: HWND, HINSTANCE, HFILE, HANDLE, etc. But, DBPro types are very standard for BASICs. They lack the short integer that you want, but you can fix that. It is possible to return 16 bit signed integers to DBPro, and make 32 integers with them while preserving the sign, here:


No, the help file thing is not really that good. It starts out okay, then...it sort of nosedives. If I had to rely on that alone, I would be in worse shape than TinTin. Yes, it is better than nothing, and no...I don't expect my hand to be held, but...it would not take much to make it much better.

It is unfortunate that you are frustrated with this forum, but...I completely understand your position. I can provide my string table to you, and you could extrapolate from there, but...name-mangling is consistent.

Finally...a bit of advice. Try to use DWORDS as much as possible. They are a register wide, and they are DBPro's and 32bit Windows' favorite type...trust me. For example, you can pass a memblock pointer to the DLL using the DWORD type, and cast it in the DLL. (Neat, now my memblock is a structure!)

Thanx Jinzai, shame you were not around last month.

I finaly managed to get my 'Procedural.dll' working and I'm now trying to get the max performance from them.

I agree dWords are great, but the functions use and give floats for the parameters, some of the functions can also internaly call the other functions (see the problem yet?).

I've managed to get around this by duplicating the required functions internaly at the moment (it's a cop out, but it works)