Re: [Gtk-osx-users] Fwd: Bluefish crash
- From: Richard Procter <richard n procter gmail com>
- To: GTK+-2 OSX Users <gtk-osx-users lists sourceforge net>
- Subject: Re: [Gtk-osx-users] Fwd: Bluefish crash
- Date: Fri, 04 Mar 2011 09:30:58 +1300
[resending as first copy hasn't made it to the list]
On 3/03/2011, at 2:33 PM, John Ralls wrote:
>
> On Mar 2, 2011, at 5:12 PM, Richard Procter wrote:
>
>> Hi John,
>>
>> On 3/03/2011, at 1:56 PM, John Ralls wrote:
>>
>>> No, it's a bug in the gtk-quartz drag'n drop code. What's happened is that the user has
>>> done a drag and then closed the window that was the source. At this point, Gtk *should* recognize
>>> that the source is no longer available and either load the OSX clipboard with the data types that haven't
>>> already been provided or tell OSX to clear the clipboard entirely. It does neither (I've made a couple of passes at getting it to clear the clipboard, but haven't figured out the right magic). Later, when the App shuts down, OSX sends an event to retrieve the rest of the data types, but the owner object has been deleted, causing an access violation and the crash.
>>
>> Do you know if this is this limited to drag+drop or does it apply to clipboard operations more generally?
>>
>
> I've only seen it with drag&drop of images, but I've never tried copying an image to test it. Text generally seems not to cause the problem.
Pasting an image from a defunct process looks good. This is what I did:
- cause my application to post an image target on the clipboard, amongst others.
- shut it down, at which point it receives a string of requests for the various offered targets.
- open preview and "new from clipboard" succeeds as expected.
Happy to test further if necessary.
regards,
Richard.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]