Eloy Duran
eloy.****@gmail*****
Wed Jan 3 20:01:37 JST 2007
Hi Laurant, > The unrecognized octype problem was about long long types that weren't > properly supported, I just fixed the SVN repository. Could you give it > a try again? I can use OSX::QTTime.new without a problem and then pass it over the bridge, but if I use the OSX::QTMakeTime function it still gives the same error: irb(main):003:0> OSX::QTMakeTime(600, 600) 2007-01-03 11:36:39.061 irb[28233] XXX returning ffi type void for unrecognized octype 113 2007-01-03 11:36:39.062 irb[28233] XXX returning ffi type void for unrecognized octype 113 I can use OSX::QTTimeRange.new without a problem and pass it over the bridge, but if I use the OSX::QTMakeTimeRange function some weird things happen with the values: irb(main):001:0> OSX.require_framework 'QTKit' => true irb(main):002:0> time1 = OSX::QTTime.new(600, 600, 0) => #<OSX::QTTime:0x5b15e4> irb(main):003:0> time2 = OSX::QTTime.new(1200, 600, 0) => #<OSX::QTTime:0x5ade58> irb(main):004:0> range1 = OSX::QTTimeRange.new(time1, time2) => #<OSX::QTTimeRange:0x5aa974> irb(main):005:0> OSX::QTStringFromTime(range1.duration).to_s 2007-01-03 11:57:14.967 irb[28258] XXX returning ffi type void for unrecognized octype 113 => "0:00:00:02.00/600" irb(main):006:0> range2 = OSX::QTMakeTimeRange(time1, time2) => #<OSX::QTTimeRange:0x5a3db8> irb(main):007:0> OSX::QTStringFromTime(range2.duration).to_s => "8:15:49:49.974180/6888580" As you can see with range1, we are able to pass the qttime object over the bridge to the C function QTStringFromTime, so that part works. But if you take a look at what range2 returns as the duration.... That would mean that the duration is like 8 days, 15 hours.... etc. But it should be 2 sec. like the first one. > The only thing I couldn't reproduce is the QTZeroTime that returns > 1000000 as timeValue for you (here it's 0). I guess that you're > running 10.4.8, what processor also? Hmm, I rechecked it and I get the correct result now, so that could have been an error on my part.... :) Eloy
