[us...@lists.monobjc.net] SynchronizationContext for Cocoa/Monobjc

[Oscar Blasco]

I have uploaded to my blog
(http://traxnet.wordpress.com/2009/12/24/synchronizationcotext-for-cocoamono
bjc/) the code of our implementation of a SynchronizationContext for
Cocoa/Monobjc. Please feel free to comment the implementation, correct it or
improve it too.

 

 If you feel like it is ok, we don't mind if you publish the article  or the
code directly on the Monobjc page or in whatever place you think could be
useful for others. 

 

Happy Christmas all,

 

Oscar Blasco
Senior Software Developer
Video Stream Networks, S.L. 
Telf. +34 96 5993670
Fax. +34 96 5993673
obla...@vsn.es
www.vsn-tv.com <http://www.vsn-tv.com/> 

 

 



 

using System;

using System.Collections.Generic;

using System.Text;

using System.Threading;

using Monobjc.Cocoa;

using Monobjc;

 

namespace vsn.MacOSXComponents.Threading

{

[ObjectiveCClass]

public class SyncObject : NSObject

{

private SendOrPostCallback m_Callback;

private Object m_State;

 

public delegate void DeregisterDelegate(SyncObject sync_object);

#if USE_SYNCOBJS_DICTIONARY

private DeregisterDelegate m_DeregisterDelegate;

#endif

 

 public static readonly Class SyncObjectClass =
Class.GetClassFromType(typeof(SyncObject));

 

///

/// Initializes a new instance of the  class.

///

public SyncObject() { }

 

///

/// Initializes a new instance of the  class.

///

///

 

public SyncObject(IntPtr nativePointer)

: base(nativePointer) { }

 

public override void  Dispose()

 {

 // This is here for testing purpouses

 //Console.Write("Disposing SyncObject");

 base.Dispose();

 }

 

///

/// initializes the synchronization object with the given call back
and object state

///

/// callback

/// state

/// if true, the current thread waits until the operation is
performed

///

 

public void Initialize(SendOrPostCallback d, Object state, bool
wait, DeregisterDelegate dereg_delegate)

{

m_Callback = d;

m_State = state;

#if USE_SYNCOBJS_DICTIONARY

m_DeregisterDelegate = dereg_delegate;

#endif

 

// Call the NSObject's performSelector method from csharp code

 
PerformSelectorOnMainThreadWithObjectWaitUntilDone(ObjectiveCRuntime.Selecto
r("bridgedCallback:"), this, wait);

}

 

///

/// This is our callback which is invoked by the main thread's
runloop

///

[ObjectiveCMessage("bridgedCallback:")]

public void BridgedCallback(NSObject param)

{

// Invoke the true callback

m_Callback(m_State); 

 

#if USE_SYNCOBJS_DICTIONARY

 // Un register this object from our cache

if (m_DeregisterDelegate != null)

m_DeregisterDelegate(this);

#endif

 

 // This region is unsafe as we are not protected against
the GC. Monobjc

 // has a cached reference to this object so shouldn't be a
problem but

 // could be a problem if the implementation changes.

 // Consider using a CER

 // GC.Collect(); // Testing

 

 // Mark this object for deletion by an AutoreleasePool

 this.Autorelease();

}

}

 

///

/// Cocoa's SynchronizationContext implementation

///

/// Only Post and Send methods are implemented

///

public class CocoaRunLoopSynchronizationContext : SynchronizationContext

{

private Dictionary m_SyncObjectsDictionary;

private readonly object m_lock = null;

 

///

/// Default constructor

///

public CocoaRunLoopSynchronizationContext()

: base()

{

m_SyncObjectsDictionary = new Dictionary();

m_lock = new object();

}

 

public override void Post(SendOrPostCallback d, Object state)

{

 SyncObject sync = new SyncObject();

#if USE_SYNCOBJS_DICTIONARY

lock(m_lock)

   m_SyncObjectsDictionary.Add(sync.GetHashCode(), sync);

#endif

sync.Initialize(d, state, false, DeregisterSyncObject);

 

}

 

public override void Send(SendOrPostCallback d, Object state)

{

SyncObject sync = new SyncObject();

#if USE_SYNCOBJS_DICTIONARY

lock (m_lock)

m_SyncObjectsDictionary.Add(sync.GetHashCode(), sync);

#endif

sync.Initialize(d, state, true, DeregisterSyncObject);

}

 

///

/// Called by SyncObject to remove itself from the dictionary so
that no 

[us...@lists.monobjc.net] AppleScripting support for NSApplication

[Oscar Blasco]

Hello all,

 

I’m currently trying to expose a property in my NSApplication to the
AppleScript world. The idea is just to expose an string property externals
applications can set to trigger some action in our software.

 

I haven’t found a way to use Cocoa Categories in Monobjc (to extended a new
property for NSApplication) so I have subclassed NSApplication and set this
new class as the application’s main class but had no success so far. 

 

Any tips on how to do this in Monobjc are welcome.

 

Regards,

 

Óscar Blasco Maestro
Senior Software Developer 
oblasco.at.vsn.es  
 
VSN R&D Office, Spain 
C/ 6 de Diciembre, 5, ent izq. 03550 San Juan de Alicante
Telf: (+34) 96 5993670

 

[us...@lists.monobjc.net] Blocks and Monobjc

[Oscar Blasco]

Hello all,

 

I’m currently trying to add a keyboard hooking function using
NSEvent:addGlobalMonitorForEventsMatchingMask method which needs a block as
a callback. To be able to define that block I moved that piece of code to a
native class in a Cocoa  Framework. The framework is wrapped from Monobjc so
that from Mono the code creates an object of that class an calls a native
method which then creates and register the block using the above NSEvent
class method. 

 

I know the upcoming Monobjc major release will add support for blocks, but
this is purely native code (involved in defining the block and assigning it
to the global monitor). Is there any Monobjc/block interaction that forbids
the use of blocks at all?

 

Thanks in advance,

 

Óscar Blasco Maestro
Senior Software Developer 
  obla...@vsn.es
 

RE: [us...@lists.monobjc.net] Blocks and Monobjc

[Oscar Blasco]

 

From: laurent.etiem...@gmail.com [mailto:laurent.etiem...@gmail.com] On
Behalf Of Laurent Etiemble
Sent: jueves, 10 de junio de 2010 10:37
To: users@lists.monobjc.net
Subject: Re: [us...@lists.monobjc.net] Blocks and Monobjc

 

Hello,

 

AFAIK, the method you describe should should work as Monobjc does not
prevent the use of blocks. You just have to be careful about the scope of
the blocks and their lifecycle.

 

You didn't write what was your problem; does your application crash, or
something else ?

 

The block is not being called. It may be due to my lack of knowledge on
blocks life cycle after all. I will further investigate this and let you
know. 

 

Thanks for the tip.

 

Oscar.

 

2010/6/9 Oscar Blasco < <mailto:oblasco...@gmail.com> oblasco...@gmail.com>

Hello all,

 

I’m currently trying to add a keyboard hooking function using
NSEvent:addGlobalMonitorForEventsMatchingMask method which needs a block as
a callback. To be able to define that block I moved that piece of code to a
native class in a Cocoa  Framework. The framework is wrapped from Monobjc so
that from Mono the code creates an object of that class an calls a native
method which then creates and register the block using the above NSEvent
class method. 

 

I know the upcoming Monobjc major release will add support for blocks, but
this is purely native code (involved in defining the block and assigning it
to the global monitor). Is there any Monobjc/block interaction that forbids
the use of blocks at all?

 

Thanks in advance,

 

Óscar Blasco Maestro
Senior Software Developer 
 <mailto:obla...@vsn.es> obla...@vsn.es