Re: [Linux1394-devel] Announce: SDPAVC
Brought to you by:
aeb,
bencollins
From: Manfred W. <e95...@st...> - 2000-04-04 20:52:25
|
"Timothy M. Shead" wrote: > > After much playing around, I figured it out ... thanks! So, without > further ado, anyone interested in a C++ library for controlling devices > through AV/C (the protocol-of-choice for DV camcorders) should check-out > SDPAVC, located at my website: http://www.k-3d.com. The library, which Are you sure that this works. I neither compiled nor tested it, but I had a look at the code, and I see the following problem: Let's inspect the function sdpAvcSubUnit::RawCommand in sdpavcsubunit.cpp, especially line 105: raw1394_set_fcp_handler(m_Handle, FCPHandler); You try to register a handler, which has (ragarding to raw1394.h) to be of the type int (*)(raw1394handle_t, nodeid_t nodeid, int response size_t length, unsigned char *data). But according to line 134, your handler has the type int (sdpAvcSubUnit::*) (raw1394handle_t Handle, ... , unsigned char* Data). It is no ordinary function, but a member function of a class and incompatible to the type, raw1394_set_fcp_handler expects (because C++ adds a pointer to the object [the instance of the class] it belongs to as a "hidden" argument to the argument list of the function, which therefore has one parameter too many. I have the same problem. It is not possible to register a member function of a class as handler; it must be an ordinary C-function (which of course cannot access the member variable of the object [because it does not get that hidden pointer to that object]). One can work-around this by using global variables for everything the handler must access as long as there is only one object, but if there are two (or more) instances, there will be troubles (especially, if the application is multithreaded), because the handler wants to hand over things to one particular object, but the global variables are common to all objects. The objects can get individual raw-handles, but the fcp_handler (and the same applies to the iso_handlers) cannot find out, which object did the raw1394_loop_iterate (btw: you should replace raw1394_read in line 113 with a raw1394_loop_iterate-loop until the response-frame arrived) and thus cause it to be called. I do not know a "clean" solution to that problem (as long as we want to use libraw1394). I think, the only way would be to create a new object-oriented version of libraw. One quick solution might be to add a field "private" or something like that to struct raw1394_handle, which we could use to store a pointer to our object. Then we could declare the handler as a friend function of the class and via the pointer (because the handler has the raw-handle as first argument, and therefore would get that pointer) we could access the member variables of the object. Manfred Weihs |