Passing an array of float to a dll?

[backspace]

Hi again, another question I need help with.

I've written a simple dll in GLBasic, and it works great. I can pass it a float, and get a changed float back

Code (glbasic) Select Expand

FUNCTION func1#: param1#
   LOCAL x#
   x# = param1# + 5
   return x#
ENDFUNCTION

EXPORT func1

But my question has to do with using an array of float as a parameter.

How would I pass the array of float as a parameter, and be able to change the array contents inside the dll, and then get the changed values back into the calling GLB program?

A "do it yourself" answer is really of no use to anyone, and is actually very insulting.
http://www.glbasic.com/forum/index.php?topic=8831.msg75123#msg75123

Since I don't know how this is done, that is why I am asking.

[backspace]

Aha, I found references to "BY REFERENCE" key words from other BASIC languages, after doing a google search. I am assuming that this is what you mean?
Keep in mind that I am pretty new to GLBasic, and the BASIC language in general. My c++ is OK. So you have to bear with me, if I ask what may be very stupid questions.

[Hemlos]

You can use arrays 2 ways with functions.
You can directly reference the array in your function.

Or you can pass the array name AS a reference to a type.

TYPE someType
  arrayname#[]
ENDTYPE

GLOBAL myRef AS someType

DIM myRef.arrayname#[1]

doSomething(myRef)
#Now myRef.arrayname[0] == 1234.5678
END

FUNCTION doSomething: passThis AS someType
  passThis.arrayname[0]=1234.5678
ENDFUNCTION

And as Ocean said...the function will assume that the bounds of the array is correct.
However, you can also pass the bounds of the array as a separate parameter to the function.
ie. FUNCTION doSomething: passThis AS someType, arrayBounds%

[backspace]

There are a few items that I need to digest, such as being able to DIM the size of an array inside a TYPE. I did not even know this was possible. The AS keyword certainly has many uses. I discovered that I did not need BYREF for arrays, since they were aut0matically passed by reference anyway. A small reference in the help file, and then a look at the generated c++ project code.
I'm used to pointers, so am in the habit of 'enforcing' bounds, but the extra parameter is a safe way to do it. thanks.
This forum rocks. Thanks again for all the help, I'd still be scratching my head without it.   

[Schranz0r]

You can work with inline... but for dll's i work with codeblocks (smaller filesize)

[backspace]

Yes, I've found that INLINE does actually work very well. My objective however is to get a dll that is written in GLBasic to actually work.
The idea behind the GLBasic dll is that I need to put together a few computer lessons for later this year, for a group of bright school kids.
Basic is easier to learn than c++, so I've opted to go the GLBasic route. I hope it all works out.

[Hemlos]

We have alot of experts watching this thread....has anyone been able to compile a dll lately or is this a thread for the moths?

[backspace]

To compile a dll is pretty simple, so I've learned after about 2 days of reading about dlls in the forum and some trial and error. By setting the Project->Options: Platform configuration to Win32-dll and then Compiler->Build multiplatform: Win32-dll. I get a dll with no problem. I thought that my problems were solved.

The problem happens when trying to call the dll from GLBasic. The exe test does not seem to see the dll, no matter what DECLARE format I try. I tried making a small c dll, and that seems to work great.

The GLB DLL code. I tried with both EXPORT addem, and EXPORT addem#, and they both compile fine.

Code (glbasic) Select Expand


FUNCTION addem#: number1#, number2#
   LOCAL result#
   result# = number1# + number2#
   RETURN result#
ENDFUNCTION

EXPORT addem

The GLBasic code to test the dll. With all 4 DECLARE options. They all seem to not see the dll at all, no matter which I use

Code (glbasic) Select Expand


GLOBAL num1#, num2#, res#


INLINE
   //DECLARE(addem, "littledll.dll", (float, float), float);
   //DECLARE_C(addem, "littledll.dll", (float, float), float);
   //DECLARE_ALIAS(addit, "littledll.dll", "addem",  (float, float), float);
   DECLARE_C_ALIAS(addit, "littledll.dll", "addem",  (float, float), float);

ENDINLINE


num1# = 123.45
num2# = 234.21
res# = 101.01

INLINE
    PRINT(res,20,0);
//if(addem){  //without alias
if(addit){    //with alias
    PRINT ("FOUND DLL", 20,20);
//res = addem(num1,num2);  //without alias
res = addit(num1,num2);    //with alias
}else{
    PRINT ("DLL NOT FOUND !!", 20,20);
}
ENDINLINE

PRINT res#, 20,80
SHOWSCREEN
MOUSEWAIT

I sincerely hope that someone knows how to make this work. I don't mind making c dlls, but I'd love to allow the kids to make their own, because it is so easy in GLBasic. Ok the call is a bit more complex, but it should easy to work from an example template.

Thanks for your interest.

[Hemlos]

Edit: i rewrote this message...the project needs to be altered again if im not mistaking.
From what i can remember(i may be wrong here)...you build the driver, then use it with your wrapper in a new project.

On the right handside of your ide, select the files tab, and add the dll to your project.
Also i think, not positive here, but i do believe your project a windows project, not a dll.

In my case....i cant get the ide to output a dll file at all.

PS.
what version are you using?

[Hemlos]

I just searched my hdd....theres no driver outputed, using the beta v11.

Im thinking theres a bug here, lets get the GLBTeam to verify this before i push the thread..anyone else able to output a dll in v11?

[backspace]

I'm using IDE Version: 10.283
The two sources I posted files come from two different projects. The dll file is compiled as a dll, the exe is a different project compiled as a Windows executable. The exe and the dll are created in their own ".app" folder, under the project folder.

I''ve attached the dll and exe in a zip file.

Edit: I don't know about wrappers, but one should be able to test the "calling" program as a "stand-alone.exe". The .dll was copied into the same folder as the .exe so that it could be found without using a path. The idea of using a dll is to not link anything to the calling program. This "linking" to the dll functions happens at runtime. I have no problem calling a little dll compiled in "c", from GLBasic. Maybe I need some "wrapper" when doing the calling to a GLB dll. I'm new to this in GLB, so really have no clue.



[attachment deleted by admin]

[Hemlos]

The wrapper provides the project a method to access the function inside the dll.
The wrapper is created at the same time the dll is built.
Almost certainly youll need some form of this wrapper included into your project, whether you use it as is, or appended into your main source.

The easiest way to include a source(in this case the wrapper) into a project is by opening it in the ide, then right click with mouse and select "insert into project".
At this point that source file will be added into the source file list on the right side of the ide under the files tab.

The wrapper will be named the same name as your dll source code, with the -dll added to the name, which you will find in your directory with the source for the driver program.
In other words, if your project source file is called "littledll.gbas", then the wrapper should be there in the same directory and named "littledll-dll.gbas"

You will need both of these files included into your project, the project which uses the driver.

IMO this is rather a most advanced way of building software, and not "basic" at all.

Originally, when the dll option in GLBasic was introduced into the language, the intentions were to "lock away" code to make unavailable the "proprietary secrets" of some algorithms "magic"....this was an alterntative to GBAL libraries which are considered to be "unsafe" from prying eyes.





[attachment deleted by admin]

[Hemlos]

Awesome work backspace!

I split the topic and pushed your final message into its own thread in the codesnippets section:

http://www.glbasic.com/forum/index.php?topic=8837.0

Welcome to the GLBasic team!

-Neil
PS. this also has resulted in abug report for the beta version.
The beta version IMO has many improvements upon version 10, however, at this point v11 needs to be fixed with this dll subject, i think.
There is a section here in the forums for bug reports, tune in there to see the results for v11 before making your switch to that version, if you plan using dll as a teaching platform for your students.