Re: validateUserInterfaceItem not called

2016-07-23 Thread livinginlosangeles 
Ok. That makes so much sense. This was a succinct explanation.

On Jul 23, 2016, at 8:40 PM, Ken Thomases  wrote:

> On Jul 23, 2016, at 10:12 PM, livinginlosange...@mac.com wrote:
>> 
>> I have a simple AppDelegate that instantiates an NSWindowController and 
>> Window. I have an NSMenuItem that invokes an IBAction on the firstResponder 
>> in my xib. This works as expected. When I press command+1, the IBAction 
>> fires. However, I specified that my NSWindowController use the 
>> ‘NSUserInterfaceValidations’ protocol, but my ‘validateUserInterfaceItem’ is 
>> never invoked. Any ideas why?
> 
> Is the class that implements validateUserInterfaceItem the same class that 
> implements the action method?  The frameworks only ask the target that will 
> be sent the action method to validate it.
> 
> Also, if your superclass implements validateMenuItem, then you need to 
> override that.  For actions that your class handles, you can implement it by 
> calling validateUserInterfaceItem if you want to cover all your bases (like 
> toolbar items).  For any other action, return what super returns.  The reason 
> is that NSMenu checks whether the target implements validateMenuItem before 
> it checks if it implements validateUserInterfaceItem.  If it implements the 
> former, it is called and the latter is not.
> 
> Unfortunately, whether a class implements validateMenuItem is not necessarily 
> documented.
> 
> Regards,
> Ken
> 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: validateUserInterfaceItem not called

2016-07-23 Thread Ken Thomases 
On Jul 23, 2016, at 10:12 PM, livinginlosange...@mac.com wrote:
> 
> I have a simple AppDelegate that instantiates an NSWindowController and 
> Window. I have an NSMenuItem that invokes an IBAction on the firstResponder 
> in my xib. This works as expected. When I press command+1, the IBAction 
> fires. However, I specified that my NSWindowController use the 
> ‘NSUserInterfaceValidations’ protocol, but my ‘validateUserInterfaceItem’ is 
> never invoked. Any ideas why?

Is the class that implements validateUserInterfaceItem the same class that 
implements the action method?  The frameworks only ask the target that will be 
sent the action method to validate it.

Also, if your superclass implements validateMenuItem, then you need to override 
that.  For actions that your class handles, you can implement it by calling 
validateUserInterfaceItem if you want to cover all your bases (like toolbar 
items).  For any other action, return what super returns.  The reason is that 
NSMenu checks whether the target implements validateMenuItem before it checks 
if it implements validateUserInterfaceItem.  If it implements the former, it is 
called and the latter is not.

Unfortunately, whether a class implements validateMenuItem is not necessarily 
documented.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

validateUserInterfaceItem not called

2016-07-23 Thread livinginlosangeles 
I have a simple AppDelegate that instantiates an NSWindowController and Window. 
I have an NSMenuItem that invokes an IBAction on the firstResponder in my xib. 
This works as expected. When I press command+1, the IBAction fires. However, I 
specified that my NSWindowController use the ‘NSUserInterfaceValidations’ 
protocol, but my ‘validateUserInterfaceItem’ is never invoked. Any ideas why?

Thanks,

Patrick
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTableView Drag/Drop - Which Column?

2016-07-23 Thread Ken Thomases 
On Jul 23, 2016, at 7:53 AM, Frank D. Engel, Jr.  wrote:
> 
> Does anyone know if there is a way to determine which column of an 
> NSTableView something being dragged is dropped onto?
> 
> I have drag and drop from one table in my application onto a row of another 
> table working, but I would like to know which column of the destination table 
> the source item was released on so that I can have different behavior 
> depending on which column received the object.
> 
> The destination table is view-based if that makes a difference.

I don't know if this works, but you should consider making the cell views 
rather than the table view itself a drag destination.  That will give better 
feedback to the user in terms of drop target highlighting.

Another thing I don't know will work: check if tableView.clickedColumn gives 
the right value.

If all else fails, use [tableView columnAtPoint:[tableView 
convertPoint:info.draggingLocation fromView:nil]].

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTableView Drag/Drop - Which Column?

2016-07-23 Thread Keary Suska 

> On Jul 23, 2016, at 6:53 AM, Frank D. Engel, Jr.  wrote:
> 
> Does anyone know if there is a way to determine which column of an 
> NSTableView something being dragged is dropped onto?
> 
> I have drag and drop from one table in my application onto a row of another 
> table working, but I would like to know which column of the destination table 
> the source item was released on so that I can have different behavior 
> depending on which column received the object.
> 
> The destination table is view-based if that makes a difference.

In your drag operation method have you tried calling [NSEvent mouseLocation] 
and then using -columnAtPoint: to determine which column the pointer is at? 
Noting that +mouseLocation provides screen coordinates, so they will need to be 
converted.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSTableView Drag/Drop - Which Column?

2016-07-23 Thread Frank D. Engel, Jr. 

Hi,

Does anyone know if there is a way to determine which column of an 
NSTableView something being dragged is dropped onto?


I have drag and drop from one table in my application onto a row of 
another table working, but I would like to know which column of the 
destination table the source item was released on so that I can have 
different behavior depending on which column received the object.


The destination table is view-based if that makes a difference.

Thank you!



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSImage from bitmap - then delete bitmap

2016-07-23 Thread Trygve Inda 
> On Jul 22, 2016, at 19:29 , Graham Cox  wrote:
>> 
>> If the worker thread is waiting for -performOnMainThread to complete, it
>> *cannot* possibly get a call from the main thread to terminate
> 
> I nodded agreement when I first read this, then “but wait!” …
> 
> Your logic seems flawed on two counts:
> 
> 1. The selector performed by the worker thread may still be queued, so the
> main thread is doing something else which may result in an attempt to
> terminate the worker thread.

This exactly. We have seen it happen 5 times out of potentially millions of
runs. Only recently did we track down what is happening through a lucky
report submitted by a customer.

T.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSImage from bitmap - then delete bitmap

2016-07-23 Thread Ken Thomases 
On Jul 22, 2016, at 9:29 PM, Graham Cox  wrote:
> 
> 
>> On 23 Jul 2016, at 12:45 AM, Trygve Inda  wrote:
>> 
>> Because the main thread sometimes needs to ask the worker threads to
>> terminate. If it does this after performOnMainThread has been called by a
>> worker thread, but before the main thread has processed it, then the main
>> thread will block waiting for the worker thread to exit, but the worker
>> thread has already blocked when it called performOnMainThread.
>> 
>> Very rare, but it can happen.
> 
> This is wrong thinking.
> 
> If the worker thread is waiting for -performOnMainThread to complete, it 
> *cannot* possibly get a call from the main thread to terminate, because the 
> main thread is dealing with whatever the other thread asked it to do.

No, because the main thread may not have started servicing the performSelector 
request yet.  The background thread has blocked as soon as the request is 
_queued_ for the main thread, not just once the main thread has received the 
request.  If the main thread makes a synchronous request to the background 
thread before it gets back to the run loop to service the pending 
performSelector request, it will deadlock.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com