World: r3wp

It is on you to not override the length of the string IMO You have 
to deal with this as you are working with static  memory so it is 
not a problem of Rebol itself. I think you ca easily write 'dangerous' 
code when dealing with DLL interfaces ;) Making error in this are 
usually ends up with crash (memory acces violation).

yes I know that ;)

maybe that IS a good point to make it harder to crash at the interface. 
 The toughest code to write is always the in-between stuff.

the main purpose I purchase is to enhance and simplify the rebol 
interaction with external lib and C/C++/VB structure binary file 
based

and that's why I can here to expose the difficulties I see on that 
issue and try with you to get infos or solutions to propose to Carl

so what is your solution? Do you know how to improve the interface?

It takes a guru level REBOLer who is also profishant in C to write 
an interface to a DLL, although there are becoming more and simple 
examples...but maybe shadwolf wants to make it a graphical process?

not that far .... lol

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
]