Re: Screen <--> View Coordinate system conversion

2016-01-19 Thread Ken Thomases 
On Jan 19, 2016, at 6:30 PM, Graham Cox  wrote:
> 
> OK, I got this working - thanks for all the help.
> 
> There is a follow-up issue though. On 10.11 (others not yet tried), the 
> drawing only appears on the main screen. When I make my transparent window, I 
> size it to the union of all NSScreens, thinking that would cover the entire 
> desktop no matter how many screens I have. Obviously, I need to do more to 
> make this work across multiple monitors, but I’m not sure what. This has 
> always worked in the (distant) past, but probably the changes to screen 
> behaviour from 10.9 has nixed that.
> 
> What shoudl I be looking for to make an overlay window that will work across 
> any number of screens, and also back to the older OS versions? (10.7 at 
> least).

You can't reliably make a window which spans multiple screens.  You have to use 
a separate window for each screen and draw the same way to each (with proper 
coordinate transforms).  This has been true, as you noted, since 10.9.  If 
"Displays have separate Spaces" is enabled in System Preferences, windows are 
simply clipped to their screen, which is determined either by which screen 
holds the majority of their area or, if they were dragged by the user, which 
screen the cursor was on when the drag ended.


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: Screen <--> View Coordinate system conversion

2016-01-19 Thread Graham Cox 
OK, I got this working - thanks for all the help.

There is a follow-up issue though. On 10.11 (others not yet tried), the drawing 
only appears on the main screen. When I make my transparent window, I size it 
to the union of all NSScreens, thinking that would cover the entire desktop no 
matter how many screens I have. Obviously, I need to do more to make this work 
across multiple monitors, but I’m not sure what. This has always worked in the 
(distant) past, but probably the changes to screen behaviour from 10.9 has 
nixed that.

What shoudl I be looking for to make an overlay window that will work across 
any number of screens, and also back to the older OS versions? (10.7 at least).

—Graham







> On 16 Jan 2016, at 5:19 PM, Graham Cox  wrote:
> 
> In fact this is now 90% working, it’s just the refresh that’s out of kilter, 
> which is no surprise since the CTM is only modified when drawing. I think I’m 
> close….


___

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:

2016-01-19 Thread Jens Alfke 

> On Jan 19, 2016, at 10:11 AM, Aandi Inston  wrote:
> 
> Thank you. The problem turned out to be a foolish mistake in the caller,
> but this has alerted me to the need for a systematic check of the
> conversion between BOOL and C integers.

The only thing likely to cause problems is if values other than 0 or 1 get 
assigned to a bool or BOOL, specifically values > 255. For example if you 
assign 256 to a BOOL it may end up as 0. This can happen if you refactor 
something like
if (count)
doSomething();
into
BOOL shouldDoSomething = (count);
…
if (shouldDoSomething)
doSomething();
Depending on the value of `count`, this can cause an overflow in the BOOL 
variable and give it an incorrect false value. The fix is to change the 
assignment to `(count != 0)`.

That being said, any Cocoa method that returns BOOL should be trustable to 
return only NO (0) or YES (1), so there shouldn’t be a need to do any extra 
checks on conversions.

—Jens
___

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:

2016-01-19 Thread Aandi Inston 
Thank you. The problem turned out to be a foolish mistake in the caller,
but this has alerted me to the need for a systematic check of the
conversion between BOOL and C integers.

On 19 January 2016 at 17:15, Jake Petroules 
wrote:

Note that BOOL is a typedef for signed char in the legacy (32-bit OS X)
> runtime, and a typedef for bool in the modern (64-bit OS X, iOS, tvOS,
> watchOS) runtime. You should use `return !!ok` or `return ok != NO` to
> force boolean coercion.
>
___

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:

2016-01-19 Thread Jake Petroules 

> On Jan 19, 2016, at 7:44 AM, Aandi Inston  wrote:
> 
> I have this handy routine:
> 
> int MacNSOpenFileWithDefaultApp ( char *path )
> {
>NSString *nsstring = [NSString stringWithUTF8String: path] ;
>BOOL ok = [[NSWorkspace sharedWorkspace] openFile:nsstring] ;
> return ok ;
> }
> 
> Suppose we pass a folder name. The intention is to open the folder in the
> Finder.
> 
> When the app is compiled as 32-bit and run on Mac OS 10.10.5, it opens the
> folder
> and returns 1.
> 
> But when the app is compiled as 64-bit and run on the same system, it still
> opens the folder but returns 0.
> 
> Any ideas? Thanks in advance.
> ___
> 
> 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/jake.petroules%40petroules.com
> 
> This email sent to jake.petrou...@petroules.com


Note that BOOL is a typedef for signed char in the legacy (32-bit OS X) 
runtime, and a typedef for bool in the modern (64-bit OS X, iOS, tvOS, watchOS) 
runtime. You should use `return !!ok` or `return ok != NO` to force boolean 
coercion.
-- 
Jake Petroules - jake.petroules at petroules.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

[no subject]

2016-01-19 Thread Aandi Inston 
I have this handy routine:

int MacNSOpenFileWithDefaultApp ( char *path )
{
NSString *nsstring = [NSString stringWithUTF8String: path] ;
BOOL ok = [[NSWorkspace sharedWorkspace] openFile:nsstring] ;
return ok ;
}

Suppose we pass a folder name. The intention is to open the folder in the
Finder.

When the app is compiled as 32-bit and run on Mac OS 10.10.5, it opens the
folder
and returns 1.

But when the app is compiled as 64-bit and run on the same system, it still
opens the folder but returns 0.

Any ideas? Thanks in advance.
___

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

Aspect ratio constraints multiplying

2016-01-19 Thread Rick Mann 
I was laying out a number keypad of UIButtons. I gave a button a 1:1 aspect 
ratio constraint, and set up a few other constraints. Then I option-dragged it. 
The aspect ratio constraint was copied with it, and I created additional 
external constraints (e.g. next to the previous button, same height, same 
bottom). I did this for all the digits 0-9.

Then I noticed that many of the buttons had multiple 1:1 aspect ratio 
constraints. I figured IB has a bug that it was creating more than one each 
time I option-drag-copied them. No biggie, I selected the redundant ones and 
deleted them.

Only they didn't delete, they turned grey (i.e. disabled), and still exist.

What's going on?

-- 
Rick Mann
rm...@latencyzero.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