World: r3wp

an ez-dll.r which takes in a .h and a .dll and lets you play, experiment, 
and try to controll any .dll might be a fun project.

Cyphre not at all and that's why I came here first to expose the 
problems then to seek solutions with you

I have written a research proposal grant for such a tool...

Interfacing with lower-level naguages (such as C) from Rebol looks 
a bit harder but when you gain more experience with it (=no crashes 
anymore ;)) you realize it works logically. I was also dissapointed 
for the firt time I tried to use some DLL. But now I'm more optimistic. 
The only think I miss is the callback handling.

grant proposal (ah, was writing backwards in French)

eFishAnt your right !!! in a C# ressource explorer motion (wich you 
can see in Shardevolp IDE for example ) could be an amazing thing 
and even more if the same code all you to do so on evry OS rebol 
stands in

Cyphre - you should let Carl know that you want callback handling. 
 I know several of us have wanted that.

Josh wrote a simple hello example .dll a while back, including how 
to write the .dll...I started to mention this to him, but we talk 
about lots of things...so not done yet...guess I can tell him to 
read this.

I mentioned this to Carl few times but you know... ;-)

ah, you must have made him think then of REBOL Platform ... ;-)

If I take Cal Dixon's libopengl.r software for example we clearly 
notice that it only use the multi float functions in opengl and not 
the vectorial float functions that leads me to think  glColor3fv( 
my_colors[ 0.3, 0.5, 0.0 ]) kind of function are un explotable as 
is in rebol and many are the external libray that deal with array 
of data for arguments instead of fractionnal multi datas

I used succesfully such arrays of floats as argument in my interface 
to AGG...this is no problem IMO

Cyphre do you have documentation on AGG anywhere?

cyphre how do you do it ?

it's curiosity not evilness ...

Paul: the docs aren't still for public..due to alpha state. When 
we reach beta the information in the docs will be 'stable' enough 
so all people could write code which syntax don't change.

Excellent at least there exist some docs :)

Shadwolf: let me show you some example...

oki

to-double-array: func [blk /no-header /local result][
	result: make binary! []
	if not no-header [

  insert tail result third make struct! [d [double]] reduce [length? 
  blk]
	]
	foreach dbl blk [
		insert tail result third make struct! [d [double]] reduce [dbl]
	]
	result
]


pass-doubles: make routine! [
	doubles [binary!]
	return: [int]
] some-lib "PassDoubles"

my-doubles: to-double-array [10.5 2.8 3.0 2.325]


pass-doubles my-doubles

---------------------------

on your C side:

extern "C"
MYDLL_API int GradientPen(unsigned char* doubles)
{
	<your code here>
	return 1;
}

this way you can pass a block of decimal!s to C side

note: the first value is the length of the array if you don't use 
the /no-header refinement

ups: the 'GradientPen' should be  'PassDoubles'

but I hope you got it

yes I understand i think

...then you can either work on the array directly using C code or 
copy it into new array etc.

but how to handle in rebol a C function of this kind void  my_func 
( int my_arg[25] ) { code... }

without adapting the C function argument type

let me check...

If I'm the conseptor of the external C lib i can do ma best for preprepare 
the data to be use to be teh easier to deal for rebol but I want 
to use a yet existant lib I will have to work pretty hard to be allowed 
to inteerface rebol code and this library

in PassDoule on C side you have a char * double argument that's not 
the same as handling a pre defined PassDoubles( unsigne double [4])

in PassDoule on C side you have a char * double argument that's not 
the same as handling a pre defined PassDoubles( unsigne double doubles 
[4])

I'm agree with you char * can feet every thing but this will need 
you on C side to make the spliting of the char content user << and 
&& maks to be able to retrieve your initial data passthue by rebol 
;)

it's impossible on C side  code to do without a spliting statement 
the direct exploitation of the data you pass to the lib

using rebol

here is teh example of your case:

test: make routine! [
	arg [binary!]
	return: [int]
] my-lib "SumIt"

probe test #{0100000002000000030000000400000005000000}

==15

the C side:

extern "C"
MYDLL_API int SumIt(int my_arg[5])
{
	int result = 0;
	for(int i = 0;i<5;i++){
		result+=my_arg[i];
	}
   return result;
}

you can build the binary! array using this function

int-to-bin-array: func [blk /local result][
	result: make binary! []
	foreach int blk [
		insert tail result third make struct! [d [int]] reduce [int]
	]
	result
]

>> int-to-bin-array [1 2 3 4 5]
== #{0100000002000000030000000400000005000000}
>>

hope this helps you

yes it helps me a lot

so you can see everything is possible to do (except the callbacks 
;))

to figure out in simle example this looks easy .... (hum not a lot 
in fact beacaus all the science is done by int-to-array reebol function 
witch is not pretty accessible to common or mortals )

maybe one improvemet would be great for us:

have some faster way how to construct those binary! data from Rebol

I hope this could solve the REBIN feature or else we need some another 
native functionality for that