I tend to believe that it's because of step 4 that some developers
(#include me) still do not like auto layout. Because even with a very
simple view, you can waste a lot of time with this step.
On Thu, Apr 21, 2016 at 9:49 PM, Bill Cheeseman wrote:
>
>> On Apr 21, 2016, at 3:19 PM, Charles Srstka
I’ve never had to do anything like step 4. I’ve certainly added or changed
constraints and fetched up a load of red boxes but never does it take more than
a little bit of consideration to work out which constraints to remove or
change.
Basically - it just isn’t that hard.
> On 22 Apr 2016, a
Hi All,
Is there any way of “pinning” one of my App’s windows so it is always in front
of a window owned by another application? I’m using a Floating Window style at
the moment, which works ok, but the window floats in fronts of everything. I’d
like my window to always be just in front of the
The only way you will be able to track a window owned by another process is via
the AX (accessibility) APIs.
This comes with a caveat that users have to opt in to allow your app to control
their computer.
There is an API to request it.
And one to see if you have it.
If you have it, then you ca
On 22 Apr 2016, at 15:23, Dave wrote:
> Is there any way of “pinning” one of my App’s windows so it is always in
> front of a window owned by another application? I’m using a Floating Window
> style at the moment, which works ok, but the window floats in fronts of
> everything. I’d like my wind
While doing some cleanup of memory problems on our software, I
discovered that HIThemeGetTextDimensions seemed to be leaking memory.
(At minimum, it seemed to be allocating a CFString and a CFDictionary and
never fully releasing them). This seems to be an old Carbon-era function
which is poorly
> On Apr 19, 2016, at 1:50 PM, John McCall wrote:
>
> We strongly encourage you not to worry about any of this and just always call
> methods using the right method signature.
Sorry to beat a dead horse, but does this mean that there is no inherent way to
handle the 1000s of Foundation and Ap
On Apr 22, 2016, at 14:48 , Carl Hoefs wrote:
>
> does this mean that there is no inherent way to handle the 1000s of
> Foundation and AppKit method signatures which don't specify an object but a
> value parameter? There is no recommended way to have them performed on the
> main thread?
The
> On Apr 22, 2016, at 2:57 PM, Quincey Morris
> wrote:
>
> The recommended way to have them performed on the main thread is to use a
> block and GCD dispatch_async (dispatch_get_main_queue (), …).
Ahh, that's clean. Implemented and working! That saves me a lot of effort.
Thanks!
-Carl
__
On Apr 22, 2016, at 2:57 PM, Quincey Morris
wrote:
>
> If you must use performSelector, then you can write your own glue method that
> takes an object parameter and invokes the API that takes the scalar parameter.
-performSelectorOnMainThread:withObject:waitUntilDone:modes: can handle
NSRunLo
If you really need the block to run in specific runloop modes, you can use
CFRunLoopPerformBlock:
CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopCommonModes, ^{
//Code to be performed on main thread
});
> On Apr 22, 2016, at 16:00, Carl Hoefs wrote:
>
> On Apr 22, 2016, at 2:57
Yes, CFRunLoopPerformBlock: works well!
Thanks,
-Carl
> On Apr 22, 2016, at 4:09 PM, Clark Cox wrote:
>
> If you really need the block to run in specific runloop modes, you can use
> CFRunLoopPerformBlock:
>
>
>
> CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopCommonModes, ^{
> //
On Apr 22, 2016, at 16:12 , Carl Hoefs wrote:
>
> Yes, CFRunLoopPerformBlock: works well!
But it sounded like you *didn’t* want to prevent the block from running. In
that case, dispatch_async would be all you’d need. (AFAIK, it doesn’t interact
with run loops, which means the block will always
I have a window that contains a split view of 2 split items. The item on the
left is a source list whose width constraint is '>= 70’ @priority 1000. The
item on the right is a view whose width constraint is '>= 700’ @priority 1000.
The window itself has no minimum size specified in IB or any oth
> On 23 Apr 2016, at 6:04 AM, Tom Doan wrote:
>
> Is there a more modern and well-behaved alternative to this?
-[NSString sizeWithAttributes:…];
—Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests o
On Apr 22, 2016, at 6:19 PM, Quincey Morris
wrote:
>
> On Apr 22, 2016, at 16:12 , Carl Hoefs wrote:
>>
>> Yes, CFRunLoopPerformBlock: works well!
>
> But it sounded like you *didn’t* want to prevent the block from running. In
> that case, dispatch_async would be all you’d need. (AFAIK, it d
On Apr 22, 2016, at 7:15 PM, Quincey Morris
wrote:
>
> I have a window that contains a split view of 2 split items. The item on the
> left is a source list whose width constraint is '>= 70’ @priority 1000. The
> item on the right is a view whose width constraint is '>= 700’ @priority
> 1000.
On Apr 22, 2016, at 18:56 , Ken Thomases wrote:
>
> First, the split view holding priorities should generally be less than 490.
> That's NSLayoutPriorityDragThatCannotResizeWindow. If they are greater than
> that, then they'll potentially override the window's size.
Sorry, I misspoke, or rat
On Apr 22, 2016, at 18:56 , Ken Thomases wrote:
>
> After that, what is the design-time size of the left split view and the
> window? You should set them to the default configuration. The window will
> stay that way so long as there are no constraints of priority 500
> (NSLayoutPriorityWindo
19 matches
Mail list logo
