NSFitPagination
I cannot detect the value of the check-box Scale to fit paper size on the print panel. I would like to know whether I have to scale my view within the method - (NSRect)rectForPage:(NSInteger)pageNumber For sure it has nothing to do with NSFitPagination. In facts NSLog(@pMode %ld, %ld, [pi horizontalPagination], [pi verticalPagination]); returns always 1, 1. Any idea? Regards -- Leonardo ___ 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
Deconstructing Text Tables
It’s very easy to create an NSAttributedString that represents a text table, then show the table in a TextView so the user can edit information in the cells. The documentation on how to create a text table (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/TextLayout/Articles/TextTables.html) is fairly clear. What I don’t see—and maybe it’s there but I just don’t understand it—is how to pull the table apart again. Suppose I want to grab all text from the first cell after the user has edited it. How do I do that? — Charles Jenkins ___ 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: Deconstructing Text Tables
On Nov 18, 2014, at 2:38 AM, Charles Jenkins cejw...@gmail.com wrote: It’s very easy to create an NSAttributedString that represents a text table, then show the table in a TextView so the user can edit information in the cells. The documentation on how to create a text table (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/TextLayout/Articles/TextTables.html) is fairly clear. What I don’t see—and maybe it’s there but I just don’t understand it—is how to pull the table apart again. Suppose I want to grab all text from the first cell after the user has edited it. How do I do that? -rangeOfTextBlock:atIndex: might be your best bet. The hard part is finding exactly where you are interested in. If you are only interested in where a user has edited, a delegate method may get you there, otherwise, I don't know. You may need to keep meta-data about constructed tables. HTH, Keary Suska Esoteritech, Inc. ___ 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
help with debugging
Hi folks Pretty uneducated in anything other than the basics of debugging, so I have a bug in my app which I can't reproduce my end, but I get several user reports that all show the same console.log errors. The bug is near-fatal, i.e. doesn't crash the app, but stops it displaying a window containing the problematic text view: 0 CoreFoundation 0x7fff8cd5664c __exceptionPreprocess + 172 1 libobjc.A.dylib 0x7fff975c86de objc_exception_throw + 43 2 CoreFoundation 0x7fff8cd564fd +[NSException raise:format:] + 205 3 AppKit 0x7fff967f3814 -[NSTextView replaceCharactersInRange:withString:] + 209 4 YourApp 0x00010f63ccf1 YourApp + 27889 5 YourApp 0x00010f637a6f YourApp + 6767 6 AppKit 0x7fff96aad039 -[NSIBObjectData I know which class this belongs to, and I see the error is generated by the call at line 3 above. However, in this class there's a huge number of replaceCharactersInRange: calls. How can I narrow down the search? Is there any way to use the info above to determine which line of code is failing? (e.g, what do the numbers after the '+' sign mean and is it possible to use them to help me find the bug? ). TIA Phil ___ 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: help with debugging
On Wed, 19 Nov 2014 00:52:13 +0700, sqwarqDev said: 0 CoreFoundation 0x7fff8cd5664c __exceptionPreprocess + 172 1 libobjc.A.dylib 0x7fff975c86de objc_exception_throw + 43 2 CoreFoundation 0x7fff8cd564fd + [NSException raise:format:] + 205 3 AppKit 0x7fff967f3814 -[NSTextView replaceCharactersInRange:withString:] + 209 4 YourApp 0x00010f63ccf1 YourApp + 27889 5 YourApp 0x00010f637a6f YourApp + 6767 6 AppKit 0x7fff96aad039 -[NSIBObjectData I know which class this belongs to, and I see the error is generated by the call at line 3 above. However, in this class there's a huge number of replaceCharactersInRange: calls. How can I narrow down the search? Is there any way to use the info above to determine which line of code is failing? (e.g, what do the numbers after the '+' sign mean and is it possible to use them to help me find the bug? ). Those offsets tell you how far into the function (in bytes I think) it was. You can indeed bring that back to a line number. See here: http://lldb.llvm.org/symbolication.html Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: help with debugging
On Nov 18, 2014, at 10:04 AM, Sean McBride s...@rogue-research.com wrote: Those offsets tell you how far into the function (in bytes I think) it was. You can indeed bring that back to a line number. See here: http://lldb.llvm.org/symbolication.html http://lldb.llvm.org/symbolication.html That info is for live debugging in lldb, but Phil said these are crash logs coming from users, so he's going to need a tool that symbolicates a log file. I know there are tools for that but I don't know offhand what they are, since I've never had to do this myself; can anyone fill in the gaps? —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: help with debugging
On Tue, 18 Nov 2014 10:25:07 -0800, Jens Alfke said: Those offsets tell you how far into the function (in bytes I think) it was. You can indeed bring that back to a line number. See here: http://lldb.llvm.org/symbolication.html http://lldb.llvm.org/ symbolication.html That info is for live debugging in lldb Not exclusively it isn't. but Phil said these are crash logs coming from users No he didn't. He said in fact that it doesn't crash, but there's a backtrace from an uncaught exception in Console logs. so he's going to need a tool that symbolicates a log file. I know there are tools for that but I don't know offhand what they are, since I've never had to do this myself; can anyone fill in the gaps? It's in the doc I linked to. Scroll to the lldb.macosx.crashlog part. I've never tried with an exception backtrace, but there's likely enough info it that doc to do it all. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: help with debugging
Just a thought off the top (please excuse me if I'm far off)... but what about wrapping in a @try/@catch to handle the exception and get more details? Again, sorry if I'm far off, still having my first cup of coffee. https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Exceptions/Tasks/HandlingExceptions.html On Tue, Nov 18, 2014 at 1:30 PM, Sean McBride s...@rogue-research.com wrote: On Tue, 18 Nov 2014 10:25:07 -0800, Jens Alfke said: Those offsets tell you how far into the function (in bytes I think) it was. You can indeed bring that back to a line number. See here: http://lldb.llvm.org/symbolication.html http://lldb.llvm.org/ symbolication.html That info is for live debugging in lldb Not exclusively it isn't. but Phil said these are crash logs coming from users No he didn't. He said in fact that it doesn't crash, but there's a backtrace from an uncaught exception in Console logs. so he's going to need a tool that symbolicates a log file. I know there are tools for that but I don't know offhand what they are, since I've never had to do this myself; can anyone fill in the gaps? It's in the doc I linked to. Scroll to the lldb.macosx.crashlog part. I've never tried with an exception backtrace, but there's likely enough info it that doc to do it all. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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/rejekted%40gmail.com This email sent to rejek...@gmail.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: Deconstructing Text Tables
Keary, Thanks for responding. :-) Your answer is what I was afraid of… If “index” only applies to characters, and therefore index 0 is the position of the first visible character in the TextView’s NSAttributedString, I could iterate through, finding the range of each cell’s characters, then jumping to the next index after that and asking again. That should work, but what the heck would I pass as the textBlock pointer? Since a text block is exactly what I’m trying to find, I don’t have a good pointer to start with, do I? — Charles Jenkins On Tuesday, November 18, 2014 at 12:50, Keary Suska wrote: On Nov 18, 2014, at 2:38 AM, Charles Jenkins cejw...@gmail.com (mailto:cejw...@gmail.com) wrote: It’s very easy to create an NSAttributedString that represents a text table, then show the table in a TextView so the user can edit information in the cells. The documentation on how to create a text table (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/TextLayout/Articles/TextTables.html) is fairly clear. What I don’t see—and maybe it’s there but I just don’t understand it—is how to pull the table apart again. Suppose I want to grab all text from the first cell after the user has edited it. How do I do that? -rangeOfTextBlock:atIndex: might be your best bet. The hard part is finding exactly where you are interested in. If you are only interested in where a user has edited, a delegate method may get you there, otherwise, I don't know. You may need to keep meta-data about constructed tables. HTH, Keary Suska Esoteritech, Inc. ___ 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: Deconstructing Text Tables
On Nov 18, 2014, at 6:38 AM, Charles Jenkins cejw...@gmail.com wrote: It’s very easy to create an NSAttributedString that represents a text table, then show the table in a TextView so the user can edit information in the cells. The documentation on how to create a text table (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/TextLayout/Articles/TextTables.html) is fairly clear. What I don’t see—and maybe it’s there but I just don’t understand it—is how to pull the table apart again. Suppose I want to grab all text from the first cell after the user has edited it. How do I do that? You would presumably enumerate the attributed string's ranges for the NSParagraphStyleAttributeName attribute, using -enumerateAttribute:inRange:options:usingBlock:. For each paragraph style object, you would check its textBlocks property to determine which cell the range is part of. You're presumably either dealing with just a one-level table or the top-level table, so you would be interested in the firstObject of the textBlocks array. After verifying that it's an NSTextTableBlock, you'd check its table, startingRow, rowSpan, startingColumn, and columnSpan to determine which cell it's a part of. If you're interested in the entire contents of the first cell, you'll need to accumulate the ranges that are part of it, since they won't necessarily all be part of a single range as enumerated. 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: NSFitPagination
It should just work without you having to do anything. It'll ask your view to image the rect, then it will scale it using a transform it has calculated to scale it to fit the paper. The pagination settng will be set to NSFitPagination when scaling the page to fit, just as you found. Unless the view is overriding it, the pagination will be a single vertical column of pages. -rectForPage: isn't called unless you are returning YES from -knowsPageRange according to documentation, but I believe that's not strictly true - it *is* called when 'scale to fit paper' is checked as well, because it needs to know the rect so that it can calculate the scaling transform. But looking at the pagination setting will always return NSFitPagination, because it's only when that's set that the method is invoked in normal circumstances. (Note, this is based on my own observation some time ago and may not be accurate - do your own tests. In fact 'fit to paper' is a newish standard feature of the print dialog - my app added its own back in the day and still has it. When I see my checkbox toggle, I change the pagination of the print info record between NSFitPagination and NSAutoPagination. The print system does the rest). --Graham I cannot detect the value of the check-box Scale to fit paper size on the print panel. I would like to know whether I have to scale my view within the method - (NSRect)rectForPage:(NSInteger)pageNumber For sure it has nothing to do with NSFitPagination. In facts NSLog(@pMode %ld, %ld, [pi horizontalPagination], [pi verticalPagination]); returns always 1, 1. Any idea? ___ 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
