Re: NSView, Animator, and Autoresizing
Hi, don't have 10.8.X around now. But on redacted, it seems to behave correctly: * when your view is resizing and I start resizing window, * animation is stopped, * your view is being resized correctly according to your mask (left, top, bottom stays, height is resized) R. On Fri, Sep 27, 2013 at 1:33 AM, Seth Willits sli...@araelium.com wrote: So it turns out that if a view is being animated via the animator, autoresizing is ignored. (The same goes for using a non-blocking NSViewAnimation.) Simple project. Click button, and resize window while the view is slowly resizing. http://www.sethwillits.com/temp/ViewAnimatorResize.zip Have one of you clever chaps run into this before and come up with a solution? I very much do not want to use a blocking animation. Is this one of those cases where auto layout can do some magic? -- Seth Willits ___ 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/robert%40tapmates.com This email sent to rob...@tapmates.com ___ 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: CGImageRef as a property of a cocoa object
Err… not “inefficient”. I meant “bad style”. On 26 Sep 2013, at 02:14, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 22 Sep 2013, at 22:44, Kyle Sluder k...@ksluder.com wrote: You're both wrong. CGImageRelease is documented to be functionally equivalent to CFRelease, except for the non-NULL requirement. The reason you can call CGImageRelease with a NULL argument is simply because it doesn't do any dispatch. CFRelease dispatches through the vtable of the object you hand it without checking for NULL. I prefer to call the more specific release if I know the type of the thing I'm releasing. As far as I’ve been informed, there are two reasons why certain APIs have a specialized version of retain/release: 1) They weren’t CFTypes on Mac OS 9 or earlier OS X releases, and were only later turned into CFTypes. 2) Apparently some members of the CoreFoundation team argue that checking for NULL is inefficient and thus insist on CFRetain/CFRelease crashing on NULL so people notice when they’re not writing proper code. People on other teams disagree, and thus write their own versions of retain/release calls that *do* check for NULL to save themselves the pain. In any case, as long as a type is documented as being a CFType, toll-free bridged to a Cocoa type or their retain/release calls are documented as being equivalent to CFRetain/CFRelease, calling the latter is safe (but check for NULL). If not, treat them as if they’re not CFTypes, because they definitely don’t fulfil the contract. Don’t put non-CFTypes in arrays/dictionaries unless you’re providing your own retain/release callbacks. Anyway, pretty much everything these days is a CFType, so using the dedicated retains/releases in favor of CFRetain/CFRelease (or Cocoa’s -retain/-release) is not necessary. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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/witness.of.teachtext%40gmx.net This email sent to witness.of.teacht...@gmx.net Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
Will this get my iOS app rejected???
Hi, Has anyone else noticed that Placeholder text in UITextFields's is very dim in iOS7? It looks ok in iOS 6, but in 7 it can hardly be seen? I found this hack: [self.pNameTextField setValue:[UIColor blackColor] forKeyPath:@_placeholderLabel.textColor]; Which seems to work, but it is still washed out looking, but it should do? is there a better way of doing this then the above code? Or better still am I missing something that makes Placeholder or UITextField's different in iOS 7? Thanks a lot All the Best Dave ___ 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
Updating provisioning profiles xCode 5
Used to be I could manage my development provisioning profiles in the Organizer. Or I could update development profile in Apple Portal with new devices, download, double-click and viola! Neither seems to be the case now. Has this moved or have I gone blind? ___ 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: Will this get my iOS app rejected???
In general if you use private API will get your app rejected or pulled when found as it is clearly forbidden. Don't try to use it if you know it is such. Find another way. File a bug requesting functionality. Sent from my iPhone On 2013/09/27, at 22:59, Steve Christensen puns...@mac.com wrote: I just looked at some UITextFields with placeholder text, both on a device and in the simulator, and it was dim but readable. If you're hot to change the look then I don't recommend using -setValue:forKeyPath:. I don't know that it will get your app rejected but at the very least it's a fragile solution since you're depending on the naming of private ivars. (And they're especially private since they're not even listed in the header file.) A more maintainable solution would be to subclass UITextField and override -drawPlaceholderInRect:. On Sep 27, 2013, at 4:43 AM, Dave d...@looktowindward.com wrote: Hi, Has anyone else noticed that Placeholder text in UITextFields's is very dim in iOS7? It looks ok in iOS 6, but in 7 it can hardly be seen? I found this hack: [self.pNameTextField setValue:[UIColor blackColor] forKeyPath:@_placeholderLabel.textColor]; Which seems to work, but it is still washed out looking, but it should do? is there a better way of doing this then the above code? Or better still am I missing something that makes Placeholder or UITextField's different in iOS 7? Thanks a lot All the Best Dave ___ ___ 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: Will this get my iOS app rejected???
Please see attributedPlaceholder Regards, Mani Am 27.09.2013 um 13:43 schrieb Dave d...@looktowindward.com: Hi, Has anyone else noticed that Placeholder text in UITextFields's is very dim in iOS7? It looks ok in iOS 6, but in 7 it can hardly be seen? I found this hack: [self.pNameTextField setValue:[UIColor blackColor] forKeyPath:@_placeholderLabel.textColor]; Which seems to work, but it is still washed out looking, but it should do? is there a better way of doing this then the above code? Or better still am I missing something that makes Placeholder or UITextField's different in iOS 7? Thanks a lot All the Best Dave ___ 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: Updating provisioning profiles xCode 5
On 27 Sep 2013, at 7:10 AM, Kevin Muldoon caoimgh...@gmail.com wrote: Used to be I could manage my development provisioning profiles in the Organizer. Or I could update development profile in Apple Portal with new devices, download, double-click and viola! Neither seems to be the case now. Has this moved or have I gone blind? Modified-limited blind. For a new device, plug it in. Xcode will ask if you want to add it to your account, then ask for your developer credentials and (if there is more than one) your team. Registration sent, profiles updated, done. For a general refresh: Preferences Accounts select account View Details… circular arrow. Or, simply try building the app for a Run, and let Xcode figure it out. It'll ask if it should renew that profile, and will do the paperwork. (Or it's supposed to. It's simplified for you, but the underlying mechanism is still fiendishly cranky. It looks like anything related to a distribution identity still needs to be hand-made. Those reading the archives in March 2014 should bear in mind that this sort of thing changes constantly.) Also, it seems most of the entitlements file has been moved to Apple-built .mobileprovision files. If you turn a capability on, Xcode does the necessary registrations (including for capabilities that don't strictly need registration) and issues a revised profile. (Or it's supposed to, but I may be misinterpreting what I see.) — F ___ 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: Updating provisioning profiles xCode 5
It's moved. Was discussed yesterday I think, under preferences. I preferred the old way myself but I can see why they did it, too many problems from people who couldn't use the website to make a prov pro with the right combo of iCloud, IAP, gamecenter and .. whatever else. I would advise everyone, have they not yet done so, to watch all the 'What's new in ...' videos from WWDC. I saved myself a few what the heck moments from seeing those. On 27 Sep, 2013, at 8:10 pm, Kevin Muldoon caoimgh...@gmail.com wrote: Used to be I could manage my development provisioning profiles in the Organizer. Or I could update development profile in Apple Portal with new devices, download, double-click and viola! Neither seems to be the case now. Has this moved or have I gone blind? ___ 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/rols%40rols.org This email sent to r...@rols.org ___ 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
Very small rect in drawRect:
I have a CustomView inside a ScrollView. Works fine.
But sometimes (don't know what causes this, or how to reproduce it) my
drawRect: method gets called with a very small rect:
-[DriftView drawRect:] Ignore very small rect {{0, 0}, {1, 1}}; visibleRect
{{0, 0}, {1393, 189}}
I just ignore these 1-pixel draw requests.
But I am curious: what might cause this? Is this normal, or something to be
worried about?
The backtrace does offer me no clues:
#1: 0x7fff8d0f2140 AppKit`-[NSView _drawRect:clip:] + 4437
#2: 0x7fff8d0eefb3 AppKit`-[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
+ 3058
#3: 0x7fff8d0efa44 AppKit`-[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
+ 5763
#4: 0x7fff8d0efa44 AppKit`-[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
+ 5763
#5: 0x7fff8d0efa44 AppKit`-[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
+ 5763
#6: 0x7fff8d0efa44 AppKit`-[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
+ 5763
#7: 0x7fff8d0ee143 AppKit`-[NSThemeFrame
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
+ 314
#8: 0x7fff8d0e9d6d AppKit`-[NSView
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 4675
#9: 0x7fff8d0b3c93 AppKit`-[NSView displayIfNeeded] + 1830
#10: 0x7fff8d0b31cc
AppKit`_handleWindowNeedsDisplayOrLayoutOrUpdateConstraints + 738
#11: 0x7fff8d67e901 AppKit`__83-[NSWindow
_postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01208
+ 46
#12: 0x7fff8c7bb417
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ +
23
#13: 0x7fff8c7bb381 CoreFoundation`__CFRunLoopDoObservers + 369
#14: 0x7fff8c7967b8 CoreFoundation`__CFRunLoopRun + 728
#15: 0x7fff8c7960e2 CoreFoundation`CFRunLoopRunSpecific + 290
#16: 0x7fff8b88eeb4 HIToolbox`RunCurrentEventLoopInMode + 209
#17: 0x7fff8b88eb94 HIToolbox`ReceiveNextEventCommon + 166
#18: 0x7fff8b88eae3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
#19: 0x7fff8d0b0533 AppKit`_DPSNextEvent + 685
#20: 0x7fff8d0afdf2 AppKit`-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
#21: 0x7fff8d0a71a3 AppKit`-[NSApplication run] + 517
#22: 0x7fff8d04bbd6 AppKit`NSApplicationMain + 869
#23: 0x000100036eb2 EnTeP`main(argc=3, argv=0x7fff5fbff870) + 34 at
main.m:13
#24: 0x000119e4 EnTeP`start + 52
Gerriet.
___
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: Very small rect in drawRect:
On Sep 27, 2013, at 22:05 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote: The backtrace does offer me no clues: #1: 0x7fff8d0f2140 AppKit`-[NSView _drawRect:clip:] + 4437 #2: 0x7fff8d0eefb3 AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 3058 #3: 0x7fff8d0efa44 AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 5763 #4: 0x7fff8d0efa44 AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 5763 #5: 0x7fff8d0efa44 AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 5763 #6: 0x7fff8d0efa44 AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 5763 The backtrace does in fact offer clues. Your view needs redrawing, and the frameworks are breaking down the dirty region into non-overlapping component rects that are drawn separately. It just happens that this decomposition process leaves a tiny rect to be drawn separately. As to why it decomposes this way, my guess would be that your view has subviews (and/or controls) which are misaligned by a single pixel, changing what would otherwise be a nice rectangular dirty region into something slightly more complex. ___ 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
