AutoSave for Windows

[Gerriet M. Denkmann]

macOS 12.1, Xcode Version 8.1 (8T61a).

App with two windows: FestEvent and Preferences, which have Autosave names of 
FestEvent, resp.  Preferences.

Start App → FestEvent window will show.
Make it to show Preferences window as well.
Move both windows around and observe Preferences.plist to have absolutely 
plausible values for both: “NSWindow Frame Preferences” and: “NSWindow Frame 
FestEvent”.
Quit the app.

Start App again →  FestEvent window will show, but NOT at its previous location 
as recorded in Preferences.plist, but at the location of the Preferences window.

At this second run of my app the following happens:

13:15:49.967892  -[AppDelegate applicationDidFinishLaunching:] Preferences 1030 
348 383 83 0 0 1440 877
13:15:49.967929  -[AppDelegate applicationDidFinishLaunching:] FestEvent   0 
142 383 247 0 0 1440 877
13:16:06.615131  -[FestWindowController windowDidResize:]  FestEvent   {{0, 
142}, {383, 247}}
13:16:06.639579  -[FestWindowController windowDidLoad] FestEvent   {{0, 
142}, {383, 247}}
13:16:06.714612  -[AppDelegate applicationDidFinishLaunching:] FestEvent   {{0, 
142}, {383, 247}}

So far everything is fine: the FestEvent window has the correct location.

But now some obnoxious NSPersistentUIRestorer takes over:

13:16:14.950504  -[FestWindowController windowDidResize:]  FestEvent   
{{1030, 348}, {383, 83}}
Note: this is the location of the Preferences window.


(lldb) bt
* thread #1: tid = 0x20a79e, 0x00017784 
FestEvent`-[FestWindowController windowDidResize:](self=0x618e0900, 
_cmd="windowDidResize:", notification=@"NSWindowDidResizeNotification") + 260 
at FestWindowController.m:116, queue = 'com.apple.main-thread', stop reason = 
step over
  * frame #0: 0x00017784 FestEvent`-[FestWindowController 
windowDidResize:](self=0x618e0900, _cmd="windowDidResize:", 
notification=@"NSWindowDidResizeNotification") + 260 at 
FestWindowController.m:116
frame #1: 0x7fff8dba95ec 
CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
frame #2: 0x7fff8dba94eb CoreFoundation`_CFXRegistrationPost + 427
frame #3: 0x7fff8dba9252 
CoreFoundation`___CFXNotificationPost_block_invoke + 50
frame #4: 0x7fff8db67972 CoreFoundation`-[_CFXNotificationRegistrar 
find:object:observer:enumerator:] + 2018
frame #5: 0x7fff8db6695b CoreFoundation`_CFXNotificationPost + 667
frame #6: 0x7fff8f5940e3 Foundation`-[NSNotificationCenter 
postNotificationName:object:userInfo:] + 66
frame #7: 0x7fff8b8e6177 AppKit`-[NSWindow 
_setFrameCommon:display:stashSize:] + 3326
frame #8: 0x7fff8b8e546b AppKit`-[NSWindow 
_setFrame:display:allowImplicitAnimation:stashSize:] + 222
frame #9: 0x7fff8b8e5386 AppKit`-[NSWindow setFrame:display:] + 67
frame #10: 0x7fff8b8e4e9f AppKit`-[NSWindow 
_setFrameFromString:overrideTopLeft:preferActiveDisplay:constrainFullFrame:force:]
 + 1398
frame #11: 0x7fff8bb548c5 AppKit`-[NSWindow restoreStateWithCoder:] + 
902
frame #12: 0x7fff8bb144ec 
AppKit`restorePersistentStateWithWindowRestoration + 1043
frame #13: 0x7fff8bb54501 AppKit`-[NSPersistentUIRestorer 
invokeRestoration:] + 574
frame #14: 0x7fff8bb54264 AppKit`__79-[NSPersistentUIRestorer 
finishedRestoringWindowsWithZOrder:completionHandler:]_block_invoke + 219
frame #15: 0x7fff8bb5402b AppKit`+[NSWindow 
_batchMinimizeWindowsWithBlock:] + 89
frame #16: 0x7fff8bb14a29 AppKit`-[NSPersistentUIRestorer 
finishedRestoringWindowsWithZOrder:completionHandler:] + 746
frame #17: 0x7fff8bb532e8 AppKit`__82-[NSPersistentUIRestorer 
restoreStateFromRecords:usingDelegate:completionHandler:]_block_invoke_3 + 166
frame #18: 0x7fff8bb5321b 
AppKit`__99-[NSApplication(NSPersistentUIRestorationSupport) 
_restoreWindowWithRestoration:completionHandler:]_block_invoke + 401
frame #19: 0x7fff8c26350f 
AppKit`__99-[NSApplication(NSPersistentUIRestorationSupport) 
_restoreWindowWithRestoration:completionHandler:]_block_invoke.762 + 57
frame #20: 0x7fff8dbb330c 
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
frame #21: 0x7fff8db94634 CoreFoundation`__CFRunLoopDoBlocks + 356
frame #22: 0x7fff8db93da5 CoreFoundation`__CFRunLoopRun + 917
frame #23: 0x7fff8db937b4 CoreFoundation`CFRunLoopRunSpecific + 420
frame #24: 0x7fff8d12ffbc HIToolbox`RunCurrentEventLoopInMode + 240
frame #25: 0x7fff8d12fcf9 HIToolbox`ReceiveNextEventCommon + 184
frame #26: 0x7fff8d12fc26 
HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71
frame #27: 0x7fff8b819b79 AppKit`_DPSNextEvent + 1093
frame #28: 0x7fff8bf2f1c3 AppKit`-[NSApplication(NSEvent) 
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1637
frame #29: 0x7fff8b80e53d AppKit`-[NSApplication run] + 926
frame #30: 0x7fff8b7d91ad AppKit`NSApplicationMain + 1237
frame #31: 0x00016f02 

Re: NSComboBoxCell subclass pointers?

[James Walker]

On 11/20/2016 8:15 PM, Robert Monaghan wrote:

I have been working on a custom UI for my Cocoa application. By looking around 
the internet, I have managed to learn how to subclass a large number of UI 
objects on MacOSX. In many cases I could make the appearance work the way I 
want.

The last UI element that I am working on, is NSComboBoxCell. It appears to be a 
NSTextFieldCell with an NSButtonCell attached. It seems fairly easy to override
“drawWithFrame:inView"  and draw a replacement artwork. But there are a bunch 
of unknowns/pitfalls..

The part that I suspect that I have to subclass is the NSButtonCell that I believe 
is drawing the "Arrow Button”.
But how is this done, along side the NSTextField that makes up the 
NSComboBoxCell class? When I look at the NSComboBoxCell header files, I don’t 
see any obvious clues to figure out the geometry of the NSButtonCell, that is 
apparently being used alongside the NSTextField, itself.

Are there any ways to get to the NSButtonCell stored inside the NSComboBoxCell 
Object? (Ideally so that I can override and install my own NSButtonCell..)


In my NSComboBoxCell subclass, I figured out where the "button" part 
ought to be as follows:


NSRect drawingRect = [self drawingRectForBounds: cellFrame];
NSRect titleBounds = [self titleRectForBounds: drawingRect];
NSRect buttonBounds = NSMakeRect( NSMaxX( titleBounds ),
NSMinY(drawingRect),
NSMaxX(drawingRect) - NSMaxX( titleBounds ),
NSHeight(drawingRect) );

And then I drew my own button content.
___

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: Swift DispatchQueue docs?

[Wim Lewis]

On Nov 21, 2016, at 1:48 PM, Rick Mann  wrote:
> Is there a way to look at the C header files for GCD? I tried opening 
> Dispatch.h, and Xcode is stuck "Generating Interface…", presumably a Swift 
> interface I don't want to see.

I've found that if I tell Xcode to open Foo.h, and Xcode gets stuck generating 
a nonexistent interface like that, opening Foo.h *again* while looking at the 
empty "Generating Interface…" or "No editor" pane will cause Xcode to actually 
open Foo.h.

> They seem pretty terrible. No explanation of any of the things.

I haven't found a universal way to discover how a given API is mapped into 
Swift except by getting Xcode's code-completion to suggest names for me. It is 
pretty terrible.

In some cases you can find a proposal for the API on swift-evolution and use it 
as documentation:

https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
 



___

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: Swift DispatchQueue docs?

[Rick Mann]

Hmm. If you scroll down in the generated Swift interface file, you get a bunch 
of block comments from the C version. Sigh.

> On Nov 21, 2016, at 13:48 , Rick Mann  wrote:
> 
> They seem pretty terrible. No explanation of any of the things.
> 
> The GCD guide from Apple is very old, with out-of-date info, and lacking info 
> on the newer things (AFAICT).
> 
> Is there a way to look at the C header files for GCD? I tried opening 
> Dispatch.h, and Xcode is stuck "Generating Interface…", presumably a Swift 
> interface I don't want to see.
> 
> -- 
> 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/rmann%40latencyzero.com
> 
> This email sent to rm...@latencyzero.com


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

Swift DispatchQueue docs?

[Rick Mann]

They seem pretty terrible. No explanation of any of the things.

The GCD guide from Apple is very old, with out-of-date info, and lacking info 
on the newer things (AFAICT).

Is there a way to look at the C header files for GCD? I tried opening 
Dispatch.h, and Xcode is stuck "Generating Interface…", presumably a Swift 
interface I don't want to see.

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

Re: Flipped print previews

[Gary L. Wade]

Definitely follow that train.  Doing things with the wrong context is 
definitely one possibility.  By the way, the setNeedsDisplay doesn’t need to 
happen on that view; it could be a subview, and there could be some other 
operation that implicitly causes such a dirtying—remember, there’s also 
setNeedsDisplayInRect:.  The app I referred to was doing stuff with the current 
field editor, recalculating its size and position to provide a combo box-like 
display, as a side effect of a side effect of the draw.  There’s some graphics 
context debugging options you can turn on, as well as coloration options that 
might also help.  You mentioned you broke on setNeedsDisplay.  Try adding 
setNeedsDisplayInRect: and turn on a breakpoint for all classes, not just that 
one view.
--
Gary L. Wade
http://www.garywade.com/ 
> On Nov 21, 2016, at 1:13 PM, Jeff Evans  wrote:
> 
> Thanks again Gary - but I looked into this by breaking at attempts to call 
> setDisplayNeeded on the view, with no luck. Can't find anything in my code 
> that is dirtying the view during the print draw.
> 
> However, another idea arises:
> I am using this method to obtain the current CGContext  during all this 
> drawing of various objects:
> 
> NSGraphicsContext* nsContext = [NSGraphicsContext currentContext];
> CGContextRef currentCGContext = [nsContext CGContext];
> 
> I notice that during [printOperation runOperation] the nsContext returned is 
> an NSPrintPreviewGraphicsContext*, which sounds right. But if, as is usually 
> the case, the print preview draws reduced and mirrored, I force a redraw of 
> the print preview by touching one of the dialog controls - and then I get a 
> different NSPrintPreviewGraphicsContext*, and this one always works properly.
> 
> I should think that the graphics context would be the same for the initial 
> draw and a subsequent refresh, so perhaps this is a hint. The two certainly 
> behave differently. But why would the initial one be wrong?
> 
> Another hint is that sometimes the first attempt to print a file works shows 
> a correct preview, while subsequent ones require the refresh to display 
> properly.  More often the initial attempt is wrong. Don't you hate those 
> problems that are not reliably repeatable? Yet that also should be a hint, if 
> I could make sense of it.
> 
> Jeff
> 
> 
> On Nov 20, 2016, at 11:43 PM, Gary L. Wade wrote:
> 
> 
> 
> I remembered seeing something like that in an app that had been doing some 
> things deep with the drawRect: call that was causing the view to become dirty 
> again. I fixed it by getting rid of that code. Try looking for something like 
> that first.
> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/
> 
>> On Nov 20, 2016, at 9:33 PM, Jeff Evans  wrote:
>> 
>> p.s. As I was unclear: the image returns YES to flipped and draws on that 
>> assumption, looking good. When I say the image in the print dialog is 
>> "flipped" I mean that it is backwards - mirrored - the reverse of what it 
>> should be - as if it were an unflipped view - until it is drawn a second 
>> time.
>> 
>> 
>> I'm printing from a view-based OSX app (compiled for 10.11), and have found 
>> it easy to print by creating a print operation from the view in question. 
>> The view is flipped (that is, returns YES to IsFlipped) and looks good on 
>> screen. The view creates a print operation this way:
>> 
>>  NSPrintOperation* printOp = [NSPrintOperationWithView: self printInfo: 
>> [NSPrintInfo sharedPrintInfo]];
>> 
>>  //..then setting of margins, etc. in [printOp printInfo], then
>> 
>>  [printOp runOperation]
>> 
>>  Running the operation does the whole thing and creates a beautiful preview 
>> of the page - 
>> 
>>  BUT not on the first draw. The initial image displayed in the print dialog 
>> is flipped and often reduced to miniature. If you touch the pages-to-print 
>> choice, or the All choice,  the preview image in the print dialog redraws 
>> and redraws correctly. The actual print then works fine.
>> 
>>  This does make it more difficult print to pdf when the first draw is wrong, 
>> since the pdf is also wrong on the first draw. But if I choose "view pdf in 
>> preview" then all is well - it draws nicely and I can then use Preview's 
>> export command to save it, or print.
>> 
>>  But this is no way to live. Don't want to have to tell customers to use a 
>> work-around.
>> 
>>  There must be something that needs initializing that is corrected after 
>> that first draw. Or is this just a glitch?
>> 
>> 
>>  Thanks, Jeff
>> 
> 
> 
> 
> 
> --
> If this email is spam, please report it to
> https://support.onlymyemail.com/view/report_spam/MTAxOTYyOjE5NDI1ODMyNTY6amV2YW5zQGFycy1ub3ZhLmNvbTpkZWxpdmVyZWQ
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators