On Jan 13, 2013, at 9:32 PM, Jerry Krinock wrote:
>
> You've established previously that this is definitely a bug in Mac OS 10.6.
I'm not sure I had reached that decision. I have now been able to reproduce the
problem with a bare-bones core data document app. But still I wonder if it is
some
Unlike NSView, there is no -registeredDraggedTypes method in NSWindow.
How do I find out which dragged types a window is registered to?
Thanks.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator commen
On 14 Jan 2013, at 11:17, Oleg Krupnov wrote:
> Unlike NSView, there is no -registeredDraggedTypes method in NSWindow.
> How do I find out which dragged types a window is registered to?
>
Your window has to know what drag types it will respond to.
NSDraggingDestination defines the methods that
> Will -autorelease work with ARC?
I don't think so. I didn't realize you were using ARC. I suppose you could
opt out of ARC in your Method Replacement file, in order to compile that
-autorelease.
> Could you hint how to do that? A category on NSTreeController?
I can't find the article on A
On Jan 14, 2013, at 5:02 AM, jonat...@mugginsoft.com wrote:
>
> On 14 Jan 2013, at 11:17, Oleg Krupnov wrote:
>
>> Unlike NSView, there is no -registeredDraggedTypes method in NSWindow.
>> How do I find out which dragged types a window is registered to?
>>
>
> Your window has to know what dr
I have sandboxed an app that allows users to run scripts as a major feeature
(i.e., dealbreaker on sandboxing only answer is to delete this feature). I was
pleased that I can run AppleScripts fine through the sandboxed app from Apple's
Script Editor, but the user experience is much (much, much)
On 14 Jan 2013, at 17:50, John Nairn wrote:
> I have sandboxed an app that allows users to run scripts as a major feeature
> (i.e., dealbreaker on sandboxing only answer is to delete this feature). I
> was pleased that I can run AppleScripts fine through the sandboxed app from
> Apple's Scrip
On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
> When compiled under ARC, NSTimer should have a weak, not strong, reference to
> its target.
If you want this, file a bug. Posting on the mailing list isn't guaranteed to
get your request anywhere close to the persons responsible for evaluatin
Sent from my iPhone
On Jan 4, 2013, at 9:45 PM, Steve Christensen wrote:
> On Jan 4, 2013, at 10:40 AM, Mike Abdullah wrote:
>
>> On 4 Jan 2013, at 18:12, Eric Gorr wrote:
>>
>>> Good point Mike.
>>>
>>> However, after it has completed the layout, is it possible to determine the
>>> heigh
On 14 Jan 2013, at 18:09, Eric Gorr wrote:
>
>
> Sent from my iPhone
>
> On Jan 4, 2013, at 9:45 PM, Steve Christensen wrote:
>
>> On Jan 4, 2013, at 10:40 AM, Mike Abdullah wrote:
>>
>>> On 4 Jan 2013, at 18:12, Eric Gorr wrote:
>>>
Good point Mike.
However, after it has
On 14 Jan 2013, at 17:59, Mike Abdullah wrote:
>
>>
>
> Go watch the sandboxing videos from WWDC this year. They cover automation
> quite a bit, and all will be made much clearer.
>
You want session 206 - Secure automation techniques in OS X.
If you don't have access we can probably paraph
On Jan 14, 2013, at 10:07 AM, David Duncan wrote:
> On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
>
>> When compiled under ARC, NSTimer should have a weak, not strong, reference
>> to its target.
>
> If you want this, file a bug. Posting on the mailing list isn't guaranteed to
> get your
For a kiosk-style iPad app, I have a UIViewController (outer controller) that
responds to a button my allocating an overlay view and making it a subview of
the outer controller's view. The outer controller sets the overlay's height to
100 as a placeholder.
The overlay view contains a UIWebView.
On 14 Jan 2013, at 11:50 AM, John Nairn wrote:
> The errorInfo dictionary has only NSAppleScriptErrorNumber = -43 and no other
> details. I could not find this error number in a google search.
For what it's worth:
$ macerror -43
Mac OS error -43 (fnfErr): File not found
--
Fritz Anderson
Xco
On Jan 14, 2013, at 1:23 PM, John McCall wrote:
> On Jan 14, 2013, at 10:07 AM, David Duncan wrote:
>> On Jan 12, 2013, at 10:49 AM, Gordon Apple wrote:
>>
>>> When compiled under ARC, NSTimer should have a weak, not strong, reference
>>> to its target.
>>
>> If you want this, file a bug. Po
I'd forgotten that when I created the web view, I set the autoresizing flags so
the height and width are flexible. Here is the new windowDidFinishLoad:
- (void) webViewDidFinishLoad: (UIWebView *) webView
{
CGRect myFrame = self.frame;
myFrame.size.height = self.preferredHeight;
On Mon, Jan 14, 2013, at 11:49 AM, Charles Srstka wrote:
> Not impossible at all. All you have to do is add a new API, as for
> instance NSMapTable did in 10.8. Old code that continues to use the old
> API continues to get the existing behavior.
Given that Gordon's explicit use case involves one p
One more thing. Here's the skeleton of the HTML I'm feeding to the web view. It
may be a coincidence, but the height the view eventually attains (which is not
the .preferredHeight it is set to) is pretty good for the first two paragraphs
of the #content .
(id="content" looks collision-prone, bu
On Jan 14, 2013, at 12:49 PM, Charles Srstka wrote:
> On Jan 14, 2013, at 1:23 PM, John McCall wrote:
>
>> It is effectively impossible: unlike GC, ARC is not a new runtime
>> environment. Different NSTimers may be used from different parts of the
>> program that are compiled under different
On Jan 14, 2013, at 12:38 , Kyle Sluder wrote:
> Given that Gordon's explicit use case involves one part of his app
> setting up timers that point at objects in other parts of his app that
> know nothing of the timers' existence, this sounds like a fragility
> nightmare.
>
> The NSTimer ship has
On Jan 14, 2013, at 2:38 PM, Kyle Sluder wrote:
> Given that Gordon's explicit use case involves one part of his app
> setting up timers that point at objects in other parts of his app that
> know nothing of the timers' existence, this sounds like a fragility
> nightmare.
>
> The NSTimer ship ha
On Jan 14, 2013, at 5:45 PM, Charles Srstka wrote:
> Make versions of the +timerWithTimeInterval:etc:etc: classes
That obviously should be methods, not classes. Sorry; I've had a long day.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.co
On Jan 14, 2013, at 4:45 PM, Charles Srstka wrote:
> On Jan 14, 2013, at 2:38 PM, Kyle Sluder wrote:
>
>> Given that Gordon's explicit use case involves one part of his app
>> setting up timers that point at objects in other parts of his app that
>> know nothing of the timers' existence, this s
On Jan 14, 2013, at 16:03, William Sumner wrote:
> On Jan 14, 2013, at 4:45 PM, Charles Srstka wrote:
>
>> On Jan 14, 2013, at 2:38 PM, Kyle Sluder wrote:
>>
>>> Given that Gordon's explicit use case involves one part of his app
>>> setting up timers that point at objects in other parts of hi
24 matches
Mail list logo
