pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] A better way to deal w/sig 10 & 11 exceptions

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> But there is now a better way to deal with sig 10/11.   I added a 
> Signals module to PyObjCTools.  When installed as follows....
> 
> from PyObjCTools import Signals
> Signals.dumpStackOnFatalSignal()
> 
> .... it will trap all fatal signals-- all signals that normally cause
> a core dump-- and attempt to dump the python stack before reverting
> the signal handler back to the default handler and resignaling.
> 
> I.e. if you invoke the above code and then your app crashes with 
> SIGBUS, it will dump the Python stack trace before croaking entirely.
> 
> It is likely an improvement, anyway...

That would be extremely useful. However, I can't get it to work when
there's a real crash. I don't get a Python stack trace when I patch your
demo like this:

Index: signal-demo.py
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/Examples/signal-demo.py,v
retrieving revision 1.1
diff -c -r1.1 signal-demo.py
*** signal-demo.py  4 Jun 2003 02:37:21 -0000   1.1
--- signal-demo.py  4 Jun 2003 08:06:48 -0000
***************
*** 13,19 ****
  ## the script again.
  
  def badness():
!     os.kill(os.getpid(), signal.SIGQUIT)
  
  class Foo:
      def baz(self):
--- 13,21 ----
  ## the script again.
  
  def badness():
!   import Foundation
!   o = Foundation.NSObject.alloc().init()
!   o.release()
  
  class Foo:
      def baz(self):


Could this ever work to begin with? It seems that upon such a crash the
state of the program is undefined, and executing Python code may no
longer work.

Just

[Pyobjc-dev] More fun with NSTableView

[Mitch C. <mit...@ea...>]

Hi,

[Python 2.3b1, PyObjC from CVS, updated less than five minutes ago.]

I'm trying to figure out how to supply instances of user-defined Python  
classes
as values for display in an NSTableView, and am stumped again.

In the end I'd like to be able to supply one of these Python objects to  
a subclass
of NSCell which extracts rendering information (say, a list of polygon  
vertices)
from the Python objects.

I thought I'd start simple:  define a Python "value" class which knows  
how
to represent itself as a string.  But I didn't start simply enough.

Suppose the value class looks like this:

class CustomCellValue(NSObject):
     """Provides the value for a custom cell."""

Suppose the table's data source does this:
     def tableView_objectValueForTableColumn_row_(self, aTableView,  
aTableColumn, rowIndex):
         """Get the object value for a table cell."""
         ident = aTableColumn.identifier()
         result = "%s %s" % (ident, rowIndex)
         if ident == "custom_column":
             # Trying to create a simple Python object which is  
accessible
             # from OC.
             result = CustomCellValue.alloc().init()
         return result

When I run the program, I get the following error on the first rendering
attempt.

2003-06-03 21:44:02.624 CustomTableCell[15987] *** -[CustomCellValue  
copyWithZone:]: selector not recognized
Traceback (most recent call last):
   File  
"/Users/mitchchapman/projects/br/Prototypes/CustomTableCell/build/ 
CustomTableCell.app/Contents/Resources/__main__.py", line 24, in ?
     sys.exit(AppKit.NSApplicationMain(sys.argv))
ValueError: NSInvalidArgumentException - *** -[CustomCellValue  
copyWithZone:]: selector not recognized

This looks peculiar because NSObject provides a valid implementation
of +copyWithZone:, and the docs say you should not override it.

I have verified that my instance actually gets created without incident.
It just doesn't seem to understand copyWithZone:.

Thanks again for clues.

--
Mitch

[Pyobjc-dev] A better way to deal w/sig 10 & 11 exceptions

[<bb...@ma...>]

On Tuesday, Jun 3, 2003, at 21:09 US/Eastern, Ben Golding wrote:
> Also, is there a better way to debug problems causing sig 10 or 11 
> than attaching via to the process with gdb and checking the stack 
> trace?  It'd even be nice if you could launch a pyobjc app from 
> ProjectBuilder under the debugger and look at the stack trace there.  
> At present when you do that, it complains about missing stack frames.

The problem is that we have to bootstrap the Python executable via 
execve() and, as such, the original binary image is effectively lost.  
Gdb becomes very confused.

In any case, the ObjC stack is of value-- but not a huge amount as most 
of the frames will be in Apple internal API anyway.

But there is now a better way to deal with sig 10/11.   I added a 
Signals module to PyObjCTools.  When installed as follows....

from PyObjCTools import Signals
Signals.dumpStackOnFatalSignal()

... it will trap all fatal signals-- all signals that normally cause a 
core dump-- and attempt to dump the python stack before reverting the 
signal handler back to the default handler and resignaling.

I.e. if you invoke the above code and then your app crashes with 
SIGBUS, it will dump the Python stack trace before croaking entirely.

It is likely an improvement, anyway...

b.bum

[Pyobjc-dev] Example of how to use NSOutlineView?

[Ben G. <bg...@ob...>]

I'm trying to use an NSOutlineView yet the application just crashes 
with a signal 10 bus error or signal 11 segmentation violation when it 
tries to update it.  I've read about how the NSOutlineView only holds 
onto references to objects without bumping their reference counts and 
I've tried to take that into account but I'm still struggling.  I was 
wondering whether anyone had an example of an app that used an 
NSOutlineView that I could swipe, er, I mean, examine?

Also, is there a better way to debug problems causing sig 10 or 11 than 
attaching via to the process with gdb and checking the stack trace?  
It'd even be nice if you could launch a pyobjc app from ProjectBuilder 
under the debugger and look at the stack trace there.  At present when 
you do that, it complains about missing stack frames.

Thanks, we're loving pyobjc,

	Ben.

[Pyobjc-dev] slow loading times

[Gary R. <gro...@tr...>]

Our PyObjC-based app takes a few seconds to load, even though at this point
it's very little code. I'm wondering if anyone has any tips for speeding the
load time.

It occurred to me that perhaps just parsing all PyObjC's Cocoa wrapper
classes is taking a lot of the time -- in which case perhaps we should
create our own wrapper libraries that "steal" from PyObjC's libraries only
the classes we need??

Any input on this would be most appreciated.

--Gary

-- 
<http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org>

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] CVS Build: CFObj_New, CFObj_Convert

[Mitch C. <mit...@ea...>]

On Friday, May 30, 2003, at 11:57  PM, Ronald Oussoren wrote:
> On Saturday, May 31, 2003, at 06:21 Europe/Amsterdam, Mitch Chapman 
> wrote:
>> ld: Undefined symbols:
>> _CFObj_Convert
>> _CFObj_New
>
> These functions are used to improve the integration between PyObjC and 
> MacPython. Jack Jansen introduced these functions very recently in 
> Python (a couple of days ago). The #if guard around them tests for 
> Python >= 2.3b1 because I wanted to test these functions, the test 
> should be for >= 2.3b2. I've checked in a patch.

Works like a champ!  The behavior was just what I expected, too:  I 
created a
test app containing an NSTableView, told the NSTableView that File's 
Owner
(MyDocument) was its dataSource and ran.  Result:  A warning message 
about the
  methods which the dataSource must implement.

I added definitions for those methods, didn't bother to declare 
MyDocument a
subclass of NSTableDataSource, and ran again.  Result: No warnings, just
a properly functioning app.  I didn't even have to hunt through the 
Cocoa docs or
the PyObjC sources for names of relevant informal protocols.

In short, this is a /really/ nice improvement.  Thank you.

--
Mitch

Re: [Pyobjc-dev] CVS Build: CFObj_New, CFObj_Convert

[Ronald O. <ous...@ci...>]

On Saturday, May 31, 2003, at 06:21 Europe/Amsterdam, Mitch Chapman 
wrote:

> Hej san,
>
> I just did a clean checkout from CVS, eager to get hold of Ronald's
> informal_protocol changes.*  The build fails with this error:
>
> ld: Undefined symbols:
> _CFObj_Convert
> _CFObj_New

These functions are used to improve the integration between PyObjC and 
MacPython. Jack Jansen introduced these functions very recently in 
Python (a couple of days ago). The #if guard around them tests for 
Python >= 2.3b1 because I wanted to test these functions, the test 
should be for >= 2.3b2. I've checked in a patch.

Ronald

[Pyobjc-dev] CVS Build: CFObj_New, CFObj_Convert

[Mitch C. <mit...@ea...>]

Hej san,

I just did a clean checkout from CVS, eager to get hold of Ronald's
informal_protocol changes.*  The build fails with this error:

ld: Undefined symbols:
_CFObj_Convert
_CFObj_New
error: command 'gcc' failed with exit status 1

I've copied libffi-src into place and all that.  A quick search through 
archived list
messages turns up nothing relevant.  Any suggestions on what I'm doing 
wrong?

Thanks, as always, for clues.

--
Mitch

*(And thanks for removing the need to subclass from informal protocols. 
  You're
making PyObjC as fuss-free as Python itself!)

[Pyobjc-dev] [ pyobjc-Bugs-746253 ] NSDraggingSource protocol lacks at least one method

[SourceForge.net <no...@so...>]

Bugs item #746253, was opened at 2003-05-30 18:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=746253&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSDraggingSource protocol lacks at least one method

Initial Comment:
The NSDraggingSource protocol does not include the method 
dragPromisedFilesOfTypes:fromRect:source:slideBack:event: as 
described on this page:

http://developer.apple.com/techpubs/macosx/Cocoa/
TasksAndConcepts/ProgrammingTopics/DragandDrop/Tasks/
DraggingFiles.html

The same might be true for other methods described there, also for 
the NSDraggingDestination protocol.

I've just tested this on the latest CVS version of PyObjC where I get 
this error:

"""
    self.dragPromisedFilesOfTypes_fromRect_source_slideBack_event_(
ValueError: depythonifying 'struct', got 'float'
"""



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=746253&group_id=14534

Re: [Pyobjc-dev] Does drag & drop work?

[Chris R. <cp...@em...>]

All--

Sorry for the noise, but I just have to say that what you guys are 
doing with the bridge is truly astonishing. I've never seen quite like 
it, and I've been around a *long* time (almost 35 years in the 
systems/languages/applications business).

It's a real testament to your brains & motivation, to Python and to 
Objective-C itself.

On Friday, May 30, 2003, at 11:10 AM, Ronald Oussoren wrote:

>
> On Friday, May 30, 2003, at 15:48 Europe/Amsterdam, Dinu Gherman wrote:
>
>> Ronald Oussoren:
>>
>>> I'm not sure if the current definitions for NSDraggingSource and
>>> NSDraggingDestionation are entirely correct w.r.t. required me-
>>> thods, I suppose they are too strict.
>>
>> Absolutely. Changing this solves the problem for me!
>
> I've changed the definition of NSDragging{Source,Destionation} to be 
> more correct, they should be the same as the documentation.
>
> And as of now it is no longer necessary to mention informal_protocol 
> objects in your class definitions, the bridge will automaticly find 
> the right protocols based on the methods you implement. I've just 
> checked in the patch that implements this.
>
> Ronald

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

Re: [Pyobjc-dev] Does drag & drop work?

[Ronald O. <ous...@ci...>]

On Friday, May 30, 2003, at 15:48 Europe/Amsterdam, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> I'm not sure if the current definitions for NSDraggingSource and
>> NSDraggingDestionation are entirely correct w.r.t. required me-
>> thods, I suppose they are too strict.
>
> Absolutely. Changing this solves the problem for me!

I've changed the definition of NSDragging{Source,Destionation} to be 
more correct, they should be the same as the documentation.

And as of now it is no longer necessary to mention informal_protocol 
objects in your class definitions, the bridge will automaticly find the 
right protocols based on the methods you implement. I've just checked 
in the patch that implements this.

Ronald

Re: [Pyobjc-dev] Does drag & drop work?

[Ronald O. <ous...@ci...>]

On Friday, May 30, 2003, at 15:48 Europe/Amsterdam, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> I'm not sure if the current definitions for NSDraggingSource and
>> NSDraggingDestionation are entirely correct w.r.t. required me-
>> thods, I suppose they are too strict.
>
> Absolutely. Changing this solves the problem for me!
>
> The currently used scheme for defining required methods doesn't seem
> to allow declaring groups of or dependencies between multiple methods.
> And I'd be surprised if this kind of information did really exist
> anywhere in the Cocoa headers.

The informal_protocol objects are created manually, mostly by reading 
the documentation. The documentation often mentions which methods of an 
informal protocol are required.


>
> AFAIK, the ObjC runtime caches once all available methods of an ob-
> ject and later on just knows if a method is implemented or not. Or it
> might additionally check using the respondsToSelector: method. Isn't
> this an option for the PyObjC bridge?

respondsToSelector works just fine. This method has another function 
than the informal_protocol definitions, the primairy reason those exist 
is to provide accurate method signatures to the bridge without having 
to write them down every time. Once upon a time you actually had to use 
calls to objc.selector if you wanted to write a table model. This is 
very unfriendly towards users, that's why we now have the 
informal_protocol definitions in AppKit and Foundation.

And soon informal_protocols will fade from your field of vision, you'll 
only hear of them when you implement too little of a protocol and will 
not have to mention them explicitly. One step closer to a DWIM system 
:-)

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-746115 ] NSBezierPath.elementAtIndex_associatedPoints_ parameter 2

[SourceForge.net <no...@so...>]

Bugs item #746115, was opened at 2003-05-30 16:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=746115&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martina Oefelein (oefe)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSBezierPath.elementAtIndex_associatedPoints_ parameter 2

Initial Comment:
Python 2.2 (#1, 07/14/02, 23:25:09) 
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from AppKit import *
>>> b = NSBezierPath.bezierPathWithOvalInRect_(((0,0),(1,1)))
>>> for i in range(b.elementCount()):
...     (e, pts) = b.elementAtIndex_associatedPoints_(i)
...     print e, pts
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in ?
TypeError: Need 2 arguments, got 1

According to Apple's documentation, associatedPoints is an output 
parameter, but PyObjC 0.9, treats it as input (of type NSPoint *).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=746115&group_id=14534

Re: [Pyobjc-dev] Does drag & drop work?

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> I'm not sure if the current definitions for NSDraggingSource and
> NSDraggingDestionation are entirely correct w.r.t. required me-
> thods, I suppose they are too strict.

Absolutely. Changing this solves the problem for me!

The currently used scheme for defining required methods doesn't seem
to allow declaring groups of or dependencies between multiple methods.
And I'd be surprised if this kind of information did really exist
anywhere in the Cocoa headers.

AFAIK, the ObjC runtime caches once all available methods of an ob-
ject and later on just knows if a method is implemented or not. Or it
might additionally check using the respondsToSelector: method. Isn't
this an option for the PyObjC bridge?

Dinu

--
Dinu C. Gherman
......................................................................
"We're concerned about AIDS inside our White House - make no mistake
about it."
(George W. Bush, 7 Feb. 2001)

Re: [Pyobjc-dev] Does drag & drop work?

[Ronald O. <ous...@ci...>]

On Friday, May 30, 2003, at 14:11 Europe/Amsterdam, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> It's the old 'you should have mentioned your implementing a protocol' 
>> problem. MyFileWell should inherit from NSDraggingSource and 
>> NSDraggingDestionation (see the warnings in the output panel in PB if 
>> you're using a recent CVS version of PyObjC).
>
> Argh, but funny the destination dragging is working fine! If I add
> these protocols I need to implement all sorts of methods which PB
> now (on 0.9) complains are lacking, but I guess this can be defin-
> ed somewhere as optional/informal.

The crash your seeing is caused by call from ObjC to 
draggingSourceOperationMaskForLocal:. This method has a plain C type 
(int) as its argument. Because you didn't specify a protocol, the 
bridge is assuming that all arguments are objects and therefore it 
tries to interpret the integer that's passed to this method as if it 
were an 'id' (pointer to an object).

I supose a dragging destionation doesn't have to define methods that 
receive plain C types as arguments.

I'm not sure if the current definitions for NSDraggingSource and 
NSDraggingDestionation are entirely correct w.r.t. required methods, I 
suppose they are too strict.

Ronald

Re: [Pyobjc-dev] Does drag & drop work?

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> It's the old 'you should have mentioned your implementing a protocol' 
> problem. MyFileWell should inherit from NSDraggingSource and 
> NSDraggingDestionation (see the warnings in the output panel in PB if 
> you're using a recent CVS version of PyObjC).

Argh, but funny the destination dragging is working fine! If I add
these protocols I need to implement all sorts of methods which PB
now (on 0.9) complains are lacking, but I guess this can be defin-
ed somewhere as optional/informal.

Dinu

--
Dinu C. Gherman
......................................................................
"I understand small business growth. I was one."
(George W. Bush, 19 Feb. 2000)

Re: [Pyobjc-dev] Does drag & drop work?

[Ronald O. <ous...@ci...>]

On Friday, May 30, 2003, at 11:34 Europe/Amsterdam, Dinu Gherman wrote:

> Just van Rossum:
>
>> Where does it crash exactly? Can you post the full program?
>
> Here it is, should be self-explanatory. Sorry for spamming the
> list...

It's the old 'you should have mentioned your implementing a protocol' 
problem. MyFileWell should inherit from NSDraggingSource and 
NSDraggingDestionation (see the warnings in the output panel in PB if 
you're using a recent CVS version of PyObjC).

I'm going to implement Just's suggestion: We can deduce the protocols 
your implementing from the methods your implementing and a list of 
informal_protocol objects. That should make it unnecesary to specify 
what protocols you want to implement.

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-746024 ] Various exception troubles

[SourceForge.net <no...@so...>]

Bugs item #746024, was opened at 2003-05-30 13:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=746024&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Various exception troubles

Initial Comment:
>>> from Foundation import * 
>>> class Foo(NSDictionary):
...   def init(self):
...     self = super(Foo, self).init()
...     print "XXX in init()"
...     return self
... 
>>> d = Foo.alloc().initWithDictionary_({})
2003-05-30 13:40:49.766 python2.3[13648] PyObjC: Exception 
during dealloc of proxy: NSInvalidArgumentException
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: error return without exception set
>>> d = Foo.alloc().initWithDictiona_({})  # note the typo!!
2003-05-30 13:40:58.062 python2.3[13648] PyObjC: Exception 
during dealloc of proxy: 'Foo' object has no attribute 
'initWithDictiona_'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: error return without exception set
>>>
>>> class Doo(NSDictionary):
...   def initWithObjects_forKeys_count_(self, o, k, c):
...     print "XXX---"
...     return super(Doo, self).initWithObjects_forKeys_count_(o, k, c)
... 
>>> d = Doo.dictionaryWithDictionary_({})
Bus error


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=746024&group_id=14534

Re: [Pyobjc-dev] Does drag & drop work?

[Ronald O. <ous...@ci...>]

On Friday, May 30, 2003, at 11:26 Europe/Amsterdam, Just van Rossum 
wrote:

> Dinu Gherman wrote:
>
>> It crashes on the last method call, [ ... ]
>
>          self.dragImage_at_offset_event_pasteboard_source_slideBack_(
>              img, p, (0,0), event, pb, self, YES)
>
> In that case, could it be a duplicate of bug #738252? Ronald?
>

That bugs deals with calling from Objective-C to python with 
struct-values as some of the arguments. This seems to be different. 
I'll have a look at Dinu's example. If it works for me it probably is a 
duplicate of 738252.

Ronald

Re: [Pyobjc-dev] Does drag & drop work?

[Dinu G. <gh...@da...>]

Just van Rossum:

> Where does it crash exactly? Can you post the full program?

Here it is, should be self-explanatory. Sorry for spamming the
list...

Dinu

Re: [Pyobjc-dev] Does drag & drop work?

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> It crashes on the last method call, [ ... ]

         self.dragImage_at_offset_event_pasteboard_source_slideBack_(
             img, p, (0,0), event, pb, self, YES)

In that case, could it be a duplicate of bug #738252? Ronald?

Just

Re: [Pyobjc-dev] Does drag & drop work?

[Dinu G. <gh...@da...>]

Just van Rossum:

> Where does it crash exactly? Can you post the full program?

It crashes on the last method call, self.drawImage... I can try and
strip it down to only this functionality, if it doesn't take me too
long... Let me see...

Dinu

--
Dinu C. Gherman
......................................................................
"People are either hunting for husbands or hiding from them."
(Oscar Wilde)

Re: [Pyobjc-dev] Does drag & drop work?

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> I'm trying to implement a drag & drop operation, much like in Hille-
> gass' book on pp. 261. I'm using this method (in a subclass of
NSImage\
> View), much like he does, but with a simpler icon to be shown during
> dragging:
> 
>      def mouseDragged_(self, event):
>          img = NSImage.imageNamed_("myicon")
>          p = self.convertPoint_fromView_(event.locationInWindow(),
None)
>          pb = NSPasteboard.pasteboardWithName_(NSDragPboard)
>          pb.declareTypes_owner_([NSStringPboardType], None)
>          pb.setString_forType_("foo", NSStringPboardType)
>          self.dragImage_at_offset_event_pasteboard_source_slideBack_(
>              img, p, (0,0), event, pb, self, YES)
> 
> Unfortunately, it crashes with a signal 10 (SIGBUS), so I'm wondering
> if this is a PyObjC problem? Has anybody else implemented similar
> operations successfully?

Where does it crash exactly? Can you post the full program?

Just

Re: [Pyobjc-dev] Does drag & drop work?

[Dinu G. <gh...@da...>]

I wrote:

> Unfortunately, it crashes with a signal 10 (SIGBUS), so I'm wondering
> if this is a PyObjC problem? Has anybody else implemented similar
> operations successfully?

Apparently, the other way round (using the view as a drag destination)
seems to work flawlessly.

Dinu

--
Dinu C. Gherman
......................................................................
"A whole generation has grown up with the idea that it is normal
for them to have no freedom." (Richard M. Stallman)

[Pyobjc-dev] Does drag & drop work?

[Dinu G. <gh...@da...>]

Hi,

I'm trying to implement a drag & drop operation, much like in Hille-
gass' book on pp. 261. I'm using this method (in a subclass of NSImage\
View), much like he does, but with a simpler icon to be shown during
dragging:

     def mouseDragged_(self, event):
         img = NSImage.imageNamed_("myicon")
         p = self.convertPoint_fromView_(event.locationInWindow(), None)
         pb = NSPasteboard.pasteboardWithName_(NSDragPboard)
         pb.declareTypes_owner_([NSStringPboardType], None)
         pb.setString_forType_("foo", NSStringPboardType)
         self.dragImage_at_offset_event_pasteboard_source_slideBack_(
             img, p, (0,0), event, pb, self, YES)

Unfortunately, it crashes with a signal 10 (SIGBUS), so I'm wondering
if this is a PyObjC problem? Has anybody else implemented similar
operations successfully?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"Questions are never indiscreet. Answers sometimes are." (Oscar Wilde)