Re: UIColor in CoreData database into NSColor

[Alex Kac]

Since we’ll be changing future databases to store the data as our own “PIColor” 
that can be made into an NSColor/UIColor, the issue isn’t all that important 
for long/term/future - but simply backups made already from the last 5 years.

So if there is a way that we can get it working 9 times out of 10 - just to 
convert backups - then I’m OK with that.

> On Feb 20, 2015, at 2:48 PM, Quincey Morris 
>  wrote:
> 
> On Feb 20, 2015, at 11:15 , Alex Kac mailto:a...@webis.net>> 
> wrote:
>> 
>> So with that in mind, has anyone tackled a conversion process of reading in 
>> UIColor data into NSColor via CoreData?
> 
> I suspect that *really* solving this is going to be impossible.
> 
> When you say “UIColor data”, do you mean the data resulting from archiving a 
> UIColor object, or did you use something else to put it in the CoreData 
> store? If it’s archived, you could try following the suggestion in the last 
> response in this thread:
> 
>   
> http://stackoverflow.com/questions/3292836/create-uicolor-from-nscolor-data 
> 
> 
> That is to say, treat the raw data as a string, and then pick the components 
> out of the string.
> 
> The trouble you’re going to have is that a UIColor may not always be 
> represented as components, since some standard colors may have an arbitrary 
> enum—is representation. You also have to deal with possible alternate 
> representations that might have been saved by the iOS app running on older 
> versions of iOS. Even if you have components, you really need to match 
> colorspaces as well.
> 
> This makes me think you can get as far as getting NSColors that are at least 
> similar to the UIColors, though sometimes they may not be exactly the same.
> 

Alex Kac - President and Founder
Web Information Solutions, Inc.

"Forgiveness is not an occasional act: it is a permanent attitude." 
-- Dr. Martin Luther King




___

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: UIColor in CoreData database into NSColor

[Georg Seifert]

That would only work it UIColor and NSColor would encode themselves in exactly 
the same way. Any guess what, they aren’t.

Georg

On 20 Feb 2015, at 22:53, Alex Zavatone  wrote:

> Would it be correct to not care about UIColor or NSColor, encode the data to 
> be stored in 64 bit NSData, store that and when accessed, decode it?
> 
> Sent from my iPad. Please pardon typos.
> 
> On Feb 20, 2015, at 2:15 PM, Alex Kac  wrote:
> 
>> We have a CoreData database on iOS that we want our users to be able to 
>> restore in our OS X app from backups. It uses UIColor while our desktop app 
>> uses NSColor for now. The correct method for us is to save our color info in 
>> a non-platform specific way…but people have database backups where its going 
>> to stay a UIColor - its a backup and we can’t go and change those.
>> 
>> So with that in mind, has anyone tackled a conversion process of reading in 
>> UIColor data into NSColor via CoreData?


___

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: UIColor in CoreData database into NSColor

[Alex Zavatone]

Would it be correct to not care about UIColor or NSColor, encode the data to be 
stored in 64 bit NSData, store that and when accessed, decode it?

Sent from my iPad. Please pardon typos.

On Feb 20, 2015, at 2:15 PM, Alex Kac  wrote:

> We have a CoreData database on iOS that we want our users to be able to 
> restore in our OS X app from backups. It uses UIColor while our desktop app 
> uses NSColor for now. The correct method for us is to save our color info in 
> a non-platform specific way…but people have database backups where its going 
> to stay a UIColor - its a backup and we can’t go and change those.
> 
> So with that in mind, has anyone tackled a conversion process of reading in 
> UIColor data into NSColor via CoreData?
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.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: UIColor in CoreData database into NSColor

[Quincey Morris]

On Feb 20, 2015, at 11:15 , Alex Kac  wrote:
> 
> So with that in mind, has anyone tackled a conversion process of reading in 
> UIColor data into NSColor via CoreData?

I suspect that *really* solving this is going to be impossible.

When you say “UIColor data”, do you mean the data resulting from archiving a 
UIColor object, or did you use something else to put it in the CoreData store? 
If it’s archived, you could try following the suggestion in the last response 
in this thread:


http://stackoverflow.com/questions/3292836/create-uicolor-from-nscolor-data 


That is to say, treat the raw data as a string, and then pick the components 
out of the string.

The trouble you’re going to have is that a UIColor may not always be 
represented as components, since some standard colors may have an arbitrary 
enum—is representation. You also have to deal with possible alternate 
representations that might have been saved by the iOS app running on older 
versions of iOS. Even if you have components, you really need to match 
colorspaces as well.

This makes me think you can get as far as getting NSColors that are at least 
similar to the UIColors, though sometimes they may not be exactly the same.



___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Raglan T. Tiger]

> On Feb 20, 2015, at 2:09 PM, Ken Thomases  wrote:
> 
> Are you sure the app window (m_window) is the window you think it is?  Log 
> its title and its "visible" property.



NSWindow *appWindow = [NSApp mainWindow];

ETAboutWindowController *aboutWindowController = [[ETAboutWindowController 
alloc] initWithWindowNibName:@"ETAboutWindowController"];
NSWindow *aboutWindow = [aboutWindowController window];

NSLog(@"aboutWindowController  %@",aboutWindowController);
NSLog(@"   window  %@",aboutWindow);
   
NSLog(@"appWindow from outlet  %@",m_window);
NSLog(@"title  %@",[m_window title]);
NSLog(@"   visibility  %i",[m_window isVisible]);
   
NSLog(@"appWindow from call%@",appWindow);
NSLog(@"  title%@",[appWindow title]);
NSLog(@" visibility%i",[appWindow isVisible]);

[NSApp beginSheet:aboutWindow modalForWindow:m_window modalDelegate:nil 
didEndSelector:nil contextInfo:nil];


2015-02-20 14:39:15.134 [6232:204577] aboutWindowController  

2015-02-20 14:39:15.134 [6232:204577]window  

2015-02-20 14:39:15.134 [6232:204577] appWindow from outlet  
2015-02-20 14:39:15.135 [6232:204577] title  App Window Title
2015-02-20 14:39:15.135 [6232:204577]visibility  1

2015-02-20 14:39:15.135 [6232:204577] appWindow from call
2015-02-20 14:39:15.135 [6232:204577]   titleApp Window Title
2015-02-20 14:39:15.135 [6232:204577]  visibility1




-rags
___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Ken Thomases]

On Feb 20, 2015, at 2:34 PM, Raglan T. Tiger  wrote:
> So, I added an outlet of the app window and get:
> 
> 2015-02-20 13:28:21.563 [5792:181060] aboutWindowController 
> 
> 2015-02-20 13:28:21.563 [5792:181060] aboutWindowController window  0x6180001edb00>
> 2015-02-20 13:28:21.563 [5792:181060] appWindow 
> 
> Which on its face looks good ... but the sheet still displays as a window 
> with no title and does not slide down from the app window.
> 
>ETAboutWindowController *aboutWindowController = [[ETAboutWindowController 
> alloc] initWithWindowNibName:@"ETAboutWindowController"];
>NSWindow *aboutWindow = [aboutWindowController window];
> 
>NSLog(@"aboutWindowController %@",aboutWindowController);
>NSLog(@"aboutWindowController window %@",aboutWindow);
>NSLog(@"appWindow %@",m_window);
> 
>[NSApp beginSheet:aboutWindow modalForWindow:m_window modalDelegate:nil 
> didEndSelector:nil contextInfo:nil];
> 
> This just seems too ridiculous for something that has been around forever and 
> that I have successfully implemented in the past.

Are you sure the app window (m_window) is the window you think it is?  Log its 
title and its "visible" property.

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Keary Suska]

On Feb 20, 2015, at 1:34 PM, Raglan T. Tiger  wrote:

> 2015-02-20 13:17:57.666 [5613:177188] aboutWindowController 
> 
> 2015-02-20 13:17:57.666 [5613:177188] aboutWindowController window  0x601e9500>
> 2015-02-20 13:17:57.666 [5613:177188] mainWindow window  0x601e9500>
> 
> You can see that as Steve asked the main window and sheet window are the same.

This would be disconcerting to me--I didn't think that a window could be the 
main window without actually being open, which means that the window is already 
open before beginSheet... is called. Anotehr checkbox to check: is "restorable" 
unchecked? If not, the system may be trying to restore your sheet as a regular 
window and something is getting bunged up.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: NSPredicateEditor's date picker doesn't use user's date format

[Steve Mills]

Oops, we lost the cocoa list for a message or two. Re-adding.


> On Feb 20, 2015, at 14:28:12, Shane Stanley  
> wrote:
> 
> On 20 Feb 2015, at 7:13 pm, Steve Mills  wrote:
>> 
>> But why isn't it already set up to use the correct format like every other 
>> place where a date is formatted?
>> 
>> NSString*fmt = [NSDateFormatter dateFormatFromTemplate:@"/MM/dd" 
>> options:0 locale:[NSLocale currentLocale]];
>> 
>> -->MM/dd/
>> 
>> Bwuh?
> 
> How do you define "correct"? What if you set your system short format to 
> /MMM/dd?
> 
> As I understand it, the method just reorders the values according to the 
> values for the supplied locale. user settings are therefore irrelevant.

Yes, it should be using the order that's defined in the locale, and according 
to the docs for currentLocale, it should be using *my custom settings as 
defined in System Prefs*:

"The logical locale for the current user. The locale is formed from the 
settings for the current user’s chosen system locale overlaid with any custom 
settings the user has specified."

Regardless of whether or not it can be changed programmatically, it's still a 
bug that it doesn't default to the user's display format. I'm writing up a bug.

--
Steve Mills
Drummer, Mac geek


___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Steve Mills]

On Feb 20, 2015, at 14:34:29, Raglan T. Tiger  wrote:
> 
> 2015-02-20 13:17:57.666 [5613:177188] aboutWindowController 
> 
> 2015-02-20 13:17:57.666 [5613:177188] aboutWindowController window  0x601e9500>
> 2015-02-20 13:17:57.666 [5613:177188] mainWindow window  0x601e9500>
> 
> You can see that as Steve asked the main window and sheet window are the same.
> 
> So, I added an outlet of the app window and get:
> 
> 2015-02-20 13:28:21.563 [5792:181060] aboutWindowController 
> 
> 2015-02-20 13:28:21.563 [5792:181060] aboutWindowController window  0x6180001edb00>
> 2015-02-20 13:28:21.563 [5792:181060] appWindow 
> 
> Which on its face looks good ... but the sheet still displays as a window 
> with no title and does not slide down from the app window.
> 
> ETAboutWindowController *aboutWindowController = 
> [[ETAboutWindowController alloc] 
> initWithWindowNibName:@"ETAboutWindowController"];
> NSWindow *aboutWindow = [aboutWindowController window];
> 
> NSLog(@"aboutWindowController %@",aboutWindowController);
> NSLog(@"aboutWindowController window %@",aboutWindow);
> NSLog(@"appWindow %@",m_window);
> 
> [NSApp beginSheet:aboutWindow modalForWindow:m_window modalDelegate:nil 
> didEndSelector:nil contextInfo:nil];
> 
> This just seems too ridiculous for something that has been around forever and 
> that I have successfully implemented in the past.

Yes, I agree. It should be smart enough, for instance, to use a window 
regardless of whether or not it has a title bar. The only other suggestions I 
have is to make sure your xib's File Owner's class is ETAboutWindowController, 
and its window outlet it hooked up to the window. But I assume both of those 
are correct, otherwise we wouldn't be seeing that output.

Have you thought about trying the non-deprecated methods for displaying sheets, 
e.g. those in NSWindow? I'm using those for mine, but I'm targeting 10.9 and 
later.

--
Steve Mills
Drummer, Mac geek


___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Raglan T. Tiger]

> On Feb 20, 2015, at 12:51 PM, Keary Suska  wrote:
> 
> Does [NSApp mainWindow] return a non-nil value at the point the code is 
> invoked?


> On Feb 20, 2015, at 12:57 PM, Steve Mills  wrote:
> 
> Or is it pointing to the same window that you're trying to make a sheet?


2015-02-20 13:17:57.666 [5613:177188] aboutWindowController 

2015-02-20 13:17:57.666 [5613:177188] aboutWindowController window 
2015-02-20 13:17:57.666 [5613:177188] mainWindow window 

You can see that as Steve asked the main window and sheet window are the same.

So, I added an outlet of the app window and get:

2015-02-20 13:28:21.563 [5792:181060] aboutWindowController 

2015-02-20 13:28:21.563 [5792:181060] aboutWindowController window 
2015-02-20 13:28:21.563 [5792:181060] appWindow 

Which on its face looks good ... but the sheet still displays as a window with 
no title and does not slide down from the app window.

ETAboutWindowController *aboutWindowController = [[ETAboutWindowController 
alloc] initWithWindowNibName:@"ETAboutWindowController"];
NSWindow *aboutWindow = [aboutWindowController window];

NSLog(@"aboutWindowController %@",aboutWindowController);
NSLog(@"aboutWindowController window %@",aboutWindow);
NSLog(@"appWindow %@",m_window);

[NSApp beginSheet:aboutWindow modalForWindow:m_window modalDelegate:nil 
didEndSelector:nil contextInfo:nil];

This just seems too ridiculous for something that has been around forever and 
that I have successfully implemented in the past.

-rags


___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Steve Mills]

On Feb 20, 2015, at 13:51:35, Keary Suska  wrote:
> 
> Does [NSApp mainWindow] return a non-nil value at the point the code is 
> invoked?

Or is it pointing to the same window that you're trying to make a sheet?

--
Steve Mills
Drummer, Mac geek


___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Keary Suska]

On Feb 20, 2015, at 12:35 PM, Raglan T. Tiger  wrote:

> 
>> On Feb 20, 2015, at 12:27 PM, Steve Mills  wrote:
>> 
>> Also ensure that the Title Bar attribute is turned on.
> 
> Under Appearance "Title Bar" and "Shadow" are selected.

Does [NSApp mainWindow] return a non-nil value at the point the code is invoked?

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Raglan T. Tiger]

> On Feb 20, 2015, at 12:27 PM, Steve Mills  wrote:
> 
> Also ensure that the Title Bar attribute is turned on.

Under Appearance "Title Bar" and "Shadow" are selected.

-rags
___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Steve Mills]

On Feb 20, 2015, at 13:19:11, Raglan T. Tiger  wrote:
> 
> Under Behavior , "Visible at Launch" is not selected.

Also ensure that the Title Bar attribute is turned on. This tripped me up for 
hours as well. It totally goes against what should be logical. After all, 
sheets don't appear with a titlebar, so why turn on the checkbox? That's goofy.

--
Steve Mills
Drummer, Mac geek


___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Raglan T. Tiger]

> On Feb 20, 2015, at 12:09 PM, Kyle Sluder  wrote:
> 
> Inspect the "Display At Launch" checkbox for the window in the nib. 

Under Behavior , "Visible at Launch" is not selected.

-rags
___

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

UIColor in CoreData database into NSColor

[Alex Kac]

We have a CoreData database on iOS that we want our users to be able to restore 
in our OS X app from backups. It uses UIColor while our desktop app uses 
NSColor for now. The correct method for us is to save our color info in a 
non-platform specific way…but people have database backups where its going to 
stay a UIColor - its a backup and we can’t go and change those.

So with that in mind, has anyone tackled a conversion process of reading in 
UIColor data into NSColor via CoreData?
___

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: -beginSheet:modalForWindow:modalDelegate:didEndSelector

[Kyle Sluder]

On Fri, Feb 20, 2015, at 12:54 PM, Raglan T. Tiger wrote:
> My App has one window which is displayed.  I want to display a sheet when
> a button is clicked.
> 
> In the action for the button click I do:
> 
> ETAboutWindowController *windowController = [[ETAboutWindowController
> alloc] initWithWindowNibName:@"ETAboutWindowController"];
>[NSApp beginSheet:[windowController window] modalForWindow:[NSApp
>mainWindow] modalDelegate:nil didEndSelector:nil contextInfo:nil];
> 
> The sheet displays like a modal window with no title bar rather than
> sliding down from the main widow as I expect and the spinning beach ball
> appears.
> 
> What is my mistake here?

Inspect the "Display At Launch" checkbox for the window in the nib. If
that's set, the window will be immediately ordered in as soon as it's
decoded from the nib, which is obviously not what you want.

If that's what happened, file a bug against Interface Builder. This
trips up _everyone_, experienced and new alike.

--Kyle
___

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

-beginSheet:modalForWindow:modalDelegate:didEndSelector

[Raglan T. Tiger]

My App has one window which is displayed.  I want to display a sheet when a 
button is clicked.

In the action for the button click I do:

ETAboutWindowController *windowController = [[ETAboutWindowController 
alloc] initWithWindowNibName:@"ETAboutWindowController"];
   [NSApp beginSheet:[windowController window] modalForWindow:[NSApp 
mainWindow] modalDelegate:nil didEndSelector:nil contextInfo:nil];

The sheet displays like a modal window with no title bar rather than sliding 
down from the main widow as I expect and the spinning beach ball appears.

What is my mistake here?




-rags



___

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: Datatypes still not recognized after adding bridging header...

[Fritz Anderson]

On 19 Feb 2015, at 9:59 PM, Peters, Brandon  wrote:

> I added a bridging header so that I could use the FMDB Objective-C code in 
> Swift. However, the compiler still says it cannot recognize the datatype. 
> Under Swift Compiler -> Code Generation I added the bridging header there. Is 
> there something else I am missing? I am running Xcode 6.3 beta on 10.10.2.

Are you compiling FMDB as a separate module, or folding it into the target 
compilation phase?

Can you show us the bridging header (which implies you’ve added FMDB in-target)?

Are you importing the FMDB module into your Swift source (if a separate module)?

Does Swift not-recognize all of the FMDB classes, or just some? Or is “the 
datatype” something other than an FMDB-defined class?

Beyond this, I’d be getting into things from the Using Swift with Cocoa and 
Objective-C document.

— 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

checking for app store receipts

[Torsten Curdt]

Let's say I have a Mac app store app but for intermediate releases and/or
support of trial version I would like to also have version that is
distributed from my own site. So besides the app store build I would have
another build (distributed by me) that needs to know whether there is a
valid app store receipt for the app store build or not.

What I found so far:

http://stackoverflow.com/questions/4261348/mac-app-store-receipt-validation-code
http://receigen.etiemble.com/

Any further recommendations, pointers or success stories?

cheers,
Torsten
___

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

NSOpenPanel() crash in Swift 1.1

[Bill Cheeseman]

I'm writing a single-window utility application in Xcode 6.1.1 on OS X 10.10.2 
using Swift 1.1. This code statement crashes:

 let panel = NSOpenPanel()

For the first several days after I added this statement, it worked correctly -- 
the panel opened and I was able to select a file in the panel and dismiss it 
and process the file. Then yesterday, after changing some unrelated code 
elsewhere in the application, it started crashing, and now it always crashes.

When execution stops at the statement in issue, the debug log entry says 
"Unable to simultaneously satisfy constraints", and it lists a bunch of 
constraints apparently in the open panel provided by the system. It says it 
will "attempt to recover by breaking" one of the constraints, but when I 
continue execution I get the log entry "Method cache corrupted. This may be a 
message to an invalid object, or a memory error somewhere else," with 
additional information that I don't know how to interpret.

Googling the problem, I find one thread a few months ago describing the 
identical crash (including the message about incompatible constaints) stating 
that this is a known Apple bug in NSOpenPanel and that there is no workaround.

Does anybody know whether this has been fixed or a workaround exists? Reading 
the Swift 1.2 beta release notes gives me no comfort, and I hesitate to move my 
project to OS X 10.10.3 beta just to find out that it still doesn't work. I 
can't imagine that such an important Cocoa object would be left inoperable for 
very long.

-- 

Bill Cheeseman - b...@cheeseman.name 


-- 

Bill Cheeseman - b...@cheeseman.name

___

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

assertion failed: 12B466: libxpc.dylib

[Rick Mann]

I have a very old app in the app store (last updated in pre-iPhone 5 days). One 
of its bugs is that it crashes on first launch. I always assumed it was taking 
too much time to process the large amount of data it now downloads, or used to 
much memory in doing so. But looking into it, it's something else. Here's a 
line from the console, definitely not in my code:

: assertion failed: 12B466: libxpc.dylib + 51947 
[E4684D2E-0C18-3463-8A17-401C7133B92B]: 0x7d

Here's all the logging I can find:

http://pastebin.com/Kfrbq6ut

The first few lines are the console output. The rest is the generated crash log.

Any ideas what this is?

Thanks!

-- 
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