I am guessing this won't be something you can do in this manner and even if you could, it will probably break in a future update. Have you tried putting the image on the pasteboard and letting Pages get it from the pasteboard?

Try using these for dictionaries. They work for me.NSData *myData = [NSPropertyListSerialization dataWithPropertyList:myDictionary format:NSPropertyListXMLFormat_v1_0 options:0 error:nil]; NSDictionary *myDictionary = [NSPropertyListSerialization propertyListWithData:myData options:NSPropertyListMutableContainersAndLeaves format:NULL error:outError];

Did you read what I posted? Pressing the red x closes the window. Most likely closing the window also deallocates it. If the window is deallocated, this means it no longer exists. You can do showWindow, unHideWindow, etc. for ever and nothing will happen since there isn't a window to show or unHide. You can't re-open the main window if the main window does not exist. When you want to reopen it, you need to test to see if it still exists. If it doesn't, you need to recreate it before you try to open it.

Closing a window with the red button is not the same as hiding a window. Depending on other settings, closing the window may release it which means it no longer exists.I'm not a swifty so you will have to translate this objective C code on your own.Assuming Preferences is a class which, upon initialization, creates its window.Assuming preferences has been declared in the interface:Note that this could be any window, not just a Preferences window.Preferences *preferences; // in the interface -(IBAction)showMyPreferences:(id)sender { // the action to show the preferences if(!preferences) { preferences = [[Preferences alloc] init]; } [preferences showWindow:self]; // the code to actually show the preferences window }In the Preferences class:-(instancetype)init { self = [super init]; if ((self = [self initWithWindowNibName:@"Preferences"])) { // Preferences is also the nib name of the window // do other initialization stuff here } return self; }If you are determined to keep all your code in one class, the AppDelegate, then you can experiment with testing to see if the window still exists and if not, recreate it and then show it.

Maybe check to see if the window still exists when you try to open it. If it doesn't allocate it before trying to show it. Speaking of showing it, try using showWindow to show it.

Just guessing, but you probably do that by setting the default color in NSColorPanel.[[NSColorPanel sharedColorPanel] setColor:[NSColor blueColor]];I haven't tested this since I don't use the standard font panel. What I do know, however, is that setting things for the color panel in the app delegate, such as applicationDidFinishLaunching, sets up the panel for the whole app (it *is* a shared color panel).

- (void)postNotificationName:(NSNotificationName)aName object:(id)anObject userInfo:(NSDictionary *)aUserInfo;

15 seconds to find it: https://developer.accuweather.com

Maybe a menuItem to showWindow?

It has been a while and I have only briefly experimented with menu bar apps. But, from what I have gathered and from snooping around to see how other apps do it, I suspect you will have to have your app always running. When you "quit" your app, it doesn't fully terminate but unloads as much of it's functionality as possible. The only thing remaining is the implementation of the menu items--most of which you should gray out. The "Start" menu item tells your app to load back all the stuff to make it work again. This is probably why some apps like Dropbox and iTunes have those "helper" applications. Speaking of Dropbox, when you quit it from the menu, it disappears from the menu. To restart it, you need to click on it's application icon found in Applications.There are probably other ways to do it, but that seems to be what comes to my mind.

Hi,I came across your post and it sounds interesting. Maybe you have already solved it. But here is what I would try:NSMutableArray *ingredientsArray = Have the checkboxes update an array every time a checkbox is checked or unchecked. It if it checked, it adds its ingredient to the array. If it is unchecked, it removes its ingredient from the array. NSArray *recipeArray = every recipe has its ingredients stored in its own array.Once all the check boxes are chosen, then a button to "get result" or it could be done as checkboxes are selected/deselected--do a search/sort/compare/etc. with the arrays to find a match for ingredients to recipes. This also opens up possibilities such as, if you had x ingredient, you could make x.

Why do you have float weight and int steps declared in the interface? and why is steps an int when it is a double in queryForQuantityTypeIdentifier?Declare those variables in -(float)calculateCaloriesBurnedForWalkingType: (int)typeIn your queryForQuantityTypeIdentifier, I would return a double.Return that double from queryWeight and querySteps.Then send the steps and weight to: caloriesBurnedInStepsTaken:(double)steps weight:(double)weight and have it return the result.You can then probably do away with the dispatch stuff. Not tested, but this is what I would do instead of having those variables like they are.

It shouldn't make a difference. An attributed string is an attributed string. Send me an email and I will send you a link to download my test code which shows you how to do it both from an NSDocument class and from the WindowController class. Both tested and working as expected.

Sorry for being a bit vague.I just tested a link in TextEdit and it works. This is on 10.14.6. I do my development on 10.15.3 / XCode 11.3 which is where I tested the code sample above.Yes, I wrote all the code involved including what I pasted above. This is a much simpler version of the code I use in my app. I trimmed it down to just what is needed to do the pdf print and tested it before I pasted it. I would not post code that I had not verfied or had not written myself. I'm sure at some point I got the code ideas from someplace else but that was years ago.My app is a text editor of sorts. It uses NSDocument, windowController, textViews, the usual stuff. It has multiple pages with multiple textViews and the layout of the display and printing is quite involved. But, again, I did test the code above. I pulled the attributed string directly from the document's textStorage in NSDocument.No, this is not using the Print, save as method. My code has an Export to PDF menu item. That menu item is connected to the saveDocumentToPDF action in NSDocument. When I export to a pdf in this method, a little window pops up asking for a filename and that's it. No printing panel stuff.I was thinking about your problems and I am wondering if maybe there is something further up the "food chain" causing your issues. Have you verified that yes, indeed, your attributed string really is an attributed string? Is there the possibility that your textView(s) are doing plain text and you don't know it?If you use the above code I posted in an NSDocument class, you should get a pdf file with the attributes in it if indeed your textStorage/attributed string really does have the attributes in it.

I was curious so I just tested it in my app. I created a document, copied the link from this forum, pasted it into the document, and saved it as a pdf. When I open the pdf with preview, the link works--pops up Safari and opens this forum when I click on it.