Re: Resizing last column of NSTableView when it touches window border

2014-05-09 Thread Jakob Egger

> Looking at Finder windows in column view, I see that it’s able to 
> discriminate column resizing from window resizing when the last column ends 
> at the edge of the window (though it’s not always clear that the correct 
> cursor is displayed). But it’s really hard to tell exactly where the mouse is 
> pointing, since pixels are mostly pretty small these days.

Actually Finder has the same problem. Open a folder in list view. It's 
impossible to resize the last column. To resize a column, you have to drag the 
last column to a different position, resize it, and drag it back. Unfortunately 
my app doesn't allow rearranging columns :(

Adding an empty 5px spacer column at the end is possible, but an ugly hack. If 
I can't think of anything better, I'll have to go with that.

Jakob
___

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: NSNumberFormatter 10.0+ style exception with zero

2014-05-09 Thread Howard Moon
If I select the new-style NSNumberFormatter, I don't see a "Zero" field in 
Xcode/IB where I can enter that.  Since it's working when I just create the 
formatter in code, I'll just keep doing that.

What's really strange is that using the an almost identical project converted 
from Xcode 3.2 to Xcode 4, but where my text fields were NOT then dragged 
inside a new tab view, the same type of text fields hooked up to the same type 
of formatter works perfectly, and shows "N/A" when my text field values are 0.  
But in the project I'm working on, even if I delete the text fields and the 
formatter and drag&drop new ones, as long as they're inside the tab view, I get 
this behavior when the formatter is dragged&dropped in the xib, but no problems 
when the formatter is created in code.  No time to track down why any more, 
though… got deadlines to meet! :-)

Thanks,
Howard

On May 7, 2014, at 4:13 PM, Greg Parker  wrote:

> The implementation of old-style NSNumberFormatter has some sort of 
> compatibility code for old archive formats. It's possible that new versions 
> of Xcode don't write that old format correctly, or even try to do it at all.
> 
> (The error occurs because the Zero field came back as an NSString instead of 
> an NSAttributedString, and the code wasn't expecting that.)
> 
> Can you switch to the new-style NSNumberFormatter now? The new-style 
> NSNumberFormatter's zeroSymbol didn't work in 10.4 itself but should work in 
> later OS versions.
> 
> 
> On May 7, 2014, at 2:51 PM, Gary L. Wade  wrote:
> 
>> There are occasional bugs when converting from earlier formats. What I do 
>> besides reporting the bug is to look at the underlying XML in the earlier 
>> version of the XIB and the later version and try to manually make the 
>> necessary changes using a text editor. I've sometimes had to quit Xcode, 
>> edit the XIB, lock the XIB so Xcode won't change it, and then relaunch 
>> Xcode. You may not have to go that far, but I wouldn't doubt that support 
>> for pre-10.4 number formatters to be lost in test for later-XIB formats.
>> --
>> Gary L. Wade (Sent from my iPhone)
>> http://www.garywade.com/
>> 
>>> On May 7, 2014, at 2:37 PM, Howard Moon  wrote:
>>> 
>>> Ok, this seems to be an IB issue.  I've made my own NSNumberFormatter, set 
>>> its properties, and set it as the formatter for my text fields, all in 
>>> code, and that works perfectly.  No idea why the same object created in 
>>> Xcode fails, but I'll do whatever it takes to make it work, I guess!
>>> 
>>> Regards,
>>>  Howard
>>> 
>>> 
 On May 7, 2014, at 1:47 PM, Howard Moon  wrote:
 
 Hm, it may be that something else is at play here.  I did make ONE change 
 when porting… I put my text fields inside a tab view.  I wonder if maybe 
 there's a problem accessing the number formatter from a control inside a 
 tab view?  All the connections *appear* to be there, and the call stack 
 does show that it's accessing an NSNumberFormatter (and there's only on in 
 my project).  Need to run a test...
 
 Ok… I just tested the same code using the OLD xib, WITHOUT the tab view, 
 and it works with no problems!
 
 So… does anyone know if simply adding a (two-tab) tab view and dragging 
 existing objects on its pages causes any problems like this? Is there a 
 connection I've overlooked that I need to make once the objects are inside 
 that tab view?
 
 Thanks,
  -Howard
 
> On May 7, 2014, at 9:34 AM, Howard Moon  wrote:
> 
> Hi,
> 
>  is the 10.0+ style of NSNumberFormatter no longer supported?  I recently 
> moved from developing in Xcode3 under OS X 10.7 to Xcode 4 under OS X 
> 10.8, and from having a Base SDK of 10.6 to 10.7, and from a Deployment 
> Target of 10.5 to 10.6, and am now having problems with my xib-base 
> NSTextFields connected to an NSNumberFormatter.  The formatter uses the 
> 10.0+ style, allowing me to set the "Zero" field, which I am setting to 
> the string N/A.  This worked fine, even when running in 10.8 or 10.9, but 
> crashes now that I've compiled under these new conditions.
> 
> Here is the call stack when the exception is thrown:
> 
> 2014-05-07 08:32:15.225 Cubase 7.5[947:707] -[__NSCFString string]: 
> unrecognized selector sent to instance 0x1050188d0
> 2014-05-07 08:32:15.226 Cubase 7.5[947:707] NSInvalidArgumentException - 
> -[__NSCFString string]: unrecognized selector sent to instance 0x1050188d0
> 0   CoreFoundation  0x7fff92b32aee 
> __exceptionPreprocess + 174
> 1   libobjc.A.dylib 0x7fff8b8b13f0 
> objc_exception_throw + 43
> 2   CoreFoundation  0x7fff92bc940a 
> -[NSObject(NSObject) doesNotRecognizeSelector:] + 186
> 3   CoreFoundation  0x7fff92b2102e 
> ___forwarding___ + 414
> 4   CoreFoundation

Re: Resizing last column of NSTableView when it touches window border

2014-05-09 Thread Quincey Morris
On May 9, 2014, at 02:59 , Jakob Egger  wrote:

> Adding an empty 5px spacer column at the end is possible, but an ugly hack. 
> If I can't think of anything better, I'll have to go with that.

Just to clarify the scenario for posterity, you’re envisaging a situation where:

— the user drags the right edge of the rightmost column either to the left or 
to the right

— if left, the column gets smaller, so what the user actually sees is the rest 
of the table slide to the right?

— if right, the column gets bigger, so the user sees the rest of the table 
slide left?

— in neither case does the rightmost column edge itself move to where it’s 
dragged according to the mouse pointer?

Although it’s logical and consistent, it doesn’t seem like a great user 
experience to me. (A mere opinion, I know, and so basically worthless.) I would 
have thought that the natural way to make the last column smaller would be to 
drag its left edge rightwards, and the natural way to make it bigger would be 
to make the window wider.

Technically, I think there may be a way to do what you want with a 
NSTrackingArea. You could put one that’s 5pt x row-height over the right end of 
the header cell, and write your own tracking loop that resizes the column when 
a drag starts there. (You’d have to override the table view’s hitTest: method 
to make this work.) Or even put a little view up there. It’d be a fairly hacky 
solution, but it doesn’t sound non-doable.

___

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