> I got some problems passing a callback function value to a DLL, which will
> call the caml function when some event occurs.
> In fact, to use the callback_exn C API function, I have to link with the
> libcamlrun library, but that's not why I want to do because an interpreter
>  ocamlrun ) is already running.

If you're building a DLL whose purpose is to be loaded inside
ocamlrun, then you should link with ocamlrun.lib, which is an "import
library" around the DLL entry points exported by ocamlrun.

> Here's a proposal to resolve such a problem :
> a DLL should have an EntryPoint ( called CamlEntryPoint for exemple ) and
> when it's first load by the run-time system, it call the DLL EntryPoint
> function, passing both cprims and names_of_cprims arrays as parameters. Then
> we only have to add a "caml" callback func (useless in caml !) to enable DLL
> callback.

There are many more functions (and global variables) from the runtime
system that need to be known to the DLL.  The import library solution
is a lot easier, especially since the source code of the DLL can also
be compiled as a statically-linked library for use with ocamlc -custom.

> I don't know how LabTk works... I'll have a look at it.

Good idea.  You may want to start with a simpler example, e.g.
otherlibs/str/Makefile.nt in the OCaml sources.

On to your other questions:

> I got some trouble with the garbage collector.
> I manage to make callbacks from my dynamic linked library, passing it
> the callbackN_exn C API function address when it loads.
> Now i'm doing theses things :
> [Store a Caml value as a window data]
> So , the user got the ' v ' caml value which mainly contains the real handle
> of the window and the callback.
> And the window itself can obtain ' v ' from handle by calling
> etWindowData( handle_of_window );
> in the window proc I'm getting that ' v ' data like that and then I'm
> calling caml callback.
> All it's fine, but after 10 seconds, the garbage collector collects my ' v '
> data ( I can see that the Tag_val is set to Zero ).

Of course.  You didn't tell it that you've kept a pointer to "v" in
the window data.  So, as far as the GC is concerned, nobody is
pointing to "v", so it can be freed.

> How can i prevent that ?
> Shall I use CAMLparamX and other garbage-living-in-harmony-stuff ?

Yes, you definitely need to learn how to "live in harmony" with the GC :-)

Here, CAMLparamX isn't what you need, because "v" isn't local to the C
function.  You need to use register_global_root().

If you cannot get the memory address where SetWindowData stores its
window data, you'll need to put an additional indirection through a
malloc()-ed block.

> Theses macros are using local_root so do I have to make my library ask the
> current local_root from the interpreter ?

The import library takes care of all that.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr