[Openmcl-devel] Can anyone get mouse up events in the Windows/Cocotron version of ccl?

[R. Matthew Emerson]

On Sep 3, 2010, at 1:23 PM, Michael Minerva wrote:

> Thanks for your advice on this issue.  I tried replacing AppKit.1.0.dll and Foundation.1.0.dll from my objective C example with the same dlls from the version of cocotron I use with ccl and when I try and fire up the example it says my example has stopped working and freezes.  I wanted to just downgrade my version of cocotron for xcode to the current version ccl is using but the revisions do not matchup.  The newest revision of cocotron is 828 and the newest revision of the cocotron ccl bundle is 14231, do you know what revision of cocotron was used to make revision 14231?  

Subversion revision numbers represent a version of the entire filesystem tree, so the numbers aren't really useful for figuring out when an individual file changed.

You can use the Trac source browser to get a better idea of when individual files changed.  You will probably be interested to look at http://trac.clozure.com/ccl/browser/trunk/aux/cocotron/win32/cocotron.

This tells us that the AppKit.1.0.dll and Foundation.1.0.dll files in the trunk are built from Cocotron a816befd7eff.

Cocotron switched to using Mercurial instead of Subversion.  Instead of plain decimal integer revision numbers like 828, Mercurial uses a longish hex string as a changeset identifier.  Mercurial commands will accept an unabiguous prefix instead of the whole string.  In this case, a816befd7eff is short for changeset a816befd7effc586f6ed6477f9c478707a584f8f.




> On Sep 2, 2010, at 6:58 PM, Gary Byers wrote:
> 
>> I was going to say that I couldn't reproduce it, but I realized that the Cocotron libraries that I was using were a little old.  I updated
>> my ccl/cocotron directory, rebuilt the IDE, tried your test, and got
>> the same results that you reported (nothing printed on mouseup.)  That
>> strongly suggests that there was a change in the Cocotron libraries between
>> whatever (possibly several months old) version I had installed on that
>> machine and the versions that we're distributing now.
>> 
>> I can't think of anything in CCL that'd affect this (and certainly can't
>> think of anything that'd do so intentionally.)
>> 
>> If you still have the application bundle built by XCode, you might try
>> replacing the AppKit and Foundation .dlls in that bundle with the ones
>> from ccl/cocotron.  If the ObjC application behaves the same way, then
>> we can definitely say that CCL isn't involved.
>> 
>> I don't know whether it'd be necessary to upgrade the Cocotron
>> libraries that we distribute or downgrade them in order to avoid the
>> problem; Gary Palter may have a better idea of that.
>>