gregarican [mailto:greg.kujawa@gmail.com]
#Right now I just tackled the first one, initializing the CSTA
#communication stream that connects a client with the PBX system. We'll
#see how long the rest of the methods take now that this one is done.
#I'm hoping now that I have a better idea about the various method
#parameters and their corresponding data types the rest will be a
#downhill battle. There are roughly three dozen methods that will have
#to be included. If/when I complete this I will place something out
#there for people to review. I figure it can possibly make some people's
#lives easier since they won't have to reinvent the wheel if they are
#looking to access CTI using Ruby...
your work could be another ruby killer app. It would expose cleanly the t-apis and there would be no need to resort to C. Ultimately, it would make mystical apps/boxes (like pbxes) appear sooo easy to use and manager...
thanks for your project and kind regards -botp
P wrote:
thanks for your project and kind regards -botp
Four methods down, 95 to go. Checking the TSAPI docs in detail there
are a lot more items in it than I first thought. A lot more than
30-something. All of the pointer passing back and forth between the DLL
file and Ruby gets tedious, but at least the Ruby/DL library makes it
easier than the more manual methods in Win32API. I guess my app would
be portable to non-Windows platforms as long as an alternative library
is loaded in DL instead of the csta32.dll file.
Figure that I owe it to the Ruby community to hand something over when
I finally get done with this thing. Lord knows I have picked people's
brains with the most off base and newbie-ish questions over the past
year 
Four methods down, 95 to go. Checking the TSAPI docs in detail there
are a lot more items in it than I first thought. A lot more than
30-something. All of the pointer passing back and forth between the DLL
file and Ruby gets tedious, but at least the Ruby/DL library makes it
easier than the more manual methods in Win32API.
Hi, I think you may have mentioned SWIG earlier in the
thread - but if you've only taken a brief look at SWIG
so far, I'd definitely recommend having another go at it
(unless there's a known reason why SWIG can't cope with
your particular project.)
I did ruby bindings by hand for a few projects. I kept
looking at SWIG but somehow didn't "get" it from the
documentation - or at least, for whatever reason, everytime
I downloaded SWIG and started trying to figure out how to
use it, I ended up thinking, heck I'd be half-done if I
wrote the bindings by hand by now, and ended up putting off
learning SWIG.
I finally forced myself to learn SWIG doing the bindings
for ruby-ftgl ( http://rubyforge.org/projects/ruby-ftgl/ )
It was worth it. You pretty much just give SWIG the
function declarations from the the library you're trying
to wrap, and the bindings magically appear. Some tweaks
can be needed, such as functions which return values
through paramters - but SWIG can handle that, it just
needs some simple hints.
You can point SWIG at the actual header files from the
library, but it may end up trying to wrap more stuff than
you really wanted. So you can just copy the function
declarations from the library header file(s) you're
interested in, and turn SWIG loose on those. (Which is
good, because you may need to mark up a few of the
declarations slightly, to provide the hints alluded to
above.)
Anyway just wanted to give some props to SWIG in case
you might be at the same point I was for awhile where
SWIG seemed to weird and complicated to bother with. It's
pretty neat.
Regards,
Bill
···
From: "gregarican" <greg.kujawa@gmail.com>