Date   

Action on Pop

Rick Aurbach
 

iOS 13+, Xcode 11.4.1, Storyboard-based application.

I am using a navigation stack to manage some data edits. That is,
  • nav-controller root  is a list of items.
  • tap on item to segue to a detail panel to edit an item (which is a collection of subItems)
  • subItems may either be edited on the detail panel or
  • tap on a subItem to segue to a subDetail panel
        ... etc.

(Typically, this stack is three layers deep, but I'm looking for a solution that works for arbitrary depth.)

Now for all levels of this hierarchy, if the user taps the back button (or performs a gesture with same effect), I need to recognize this fact so that I can pass data up the hierarchy (hopefully without requiring strong coupling throughout).

The way I'm currently doing this is to execute a closure in each panel's deinit method. (Note that viewWillDisappear does not work except in the case of stack-depth == 2)). However putting this kind of code in deinit seems to me to be a code-smell.

Can you suggest an alternate that works at all levels of an arbitrarily deep navigation stack?

Rick Aurbach


Re: [OT] AppleScript List

Dave
 

I subscribed to this, but I am unable for post to the list. I’m not sure how long they take to activate the account?

On 27 Apr 2020, at 11:47, Bill Cheeseman <wjcheeseman@...> wrote:

And here: https://macscripter.net

Bill Cheeseman

On Apr 26, 2020, at 8:51 AM, Dave <dave@...> wrote:

I see that the old AppleScript list that was hosted by Apple is no more, does anyone know of an alternative?



Re: [OT] AppleScript List

Dave
 

Hi,

I posted to it, but it doesn’t seem to be working, and not received any mail from it since 2016!

Cheers
Dave

On 27 Apr 2020, at 14:12, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 26 Apr 2020, at 10:51 pm, Dave <dave@looktowindward.com> wrote:

I see that the old AppleScript list that was hosted by Apple is no more
It's still alive today.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>




Re: [OT] AppleScript List

Dave
 

Hi,

I registered for it, but haven’t I haven’t had an acknowledgement?  Could you check for me? 


Cheers
Dave


On 26 Apr 2020, at 23:44, Jens Alfke <jens@...> wrote:



On Apr 26, 2020, at 5:51 AM, Dave <dave@...> wrote:

I see that the old AppleScript list that was hosted by Apple is no more, does anyone know of an alternative?

Why, there's an AppleScript list right here: https://apple-dev.groups.io/g/applescript

—Jens


Re: [OT] AppleScript List

Shane Stanley
 

On 26 Apr 2020, at 10:51 pm, Dave <dave@looktowindward.com> wrote:

I see that the old AppleScript list that was hosted by Apple is no more
It's still alive today.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: [OT] AppleScript List

Bill Cheeseman
 

And here: https://macscripter.net

Bill Cheeseman

On Apr 26, 2020, at 8:51 AM, Dave <dave@...> wrote:

I see that the old AppleScript list that was hosted by Apple is no more, does anyone know of an alternative?


Re: [OT] AppleScript List

 



On Apr 26, 2020, at 5:51 AM, Dave <dave@...> wrote:

I see that the old AppleScript list that was hosted by Apple is no more, does anyone know of an alternative?

Why, there's an AppleScript list right here: https://apple-dev.groups.io/g/applescript

—Jens


[OT] AppleScript List

Dave
 

Hi,

I see that the old AppleScript list that was hosted by Apple is no more, does anyone know of an alternative?

Thanks a lot
Dave


Re: Crash, but only in release version

John Brownie
 

Of course, as soon as I sent the message, I figured out a way to do the debugging, by setting the optimisation level for the debug version. So now I can see where the problem is, sort of.

It's weird. I unwrapped a bunch of macros and an inline function to get the various components visible in the debugger, and it works, but doesn't if I leave the macros and inline function there. Something strange in the optimiser, perhaps? I guess I'll leave the unwrapped version there since it works, and go from there.

John

Alex Zavatone via groups.io wrote on 20/4/20 14:46:

One thing I forgot is if you are debugging a release version (I expect that this is a Mac app), you may want to make sure that you are not stripping debug symbols.  

On Apr 20, 2020, at 6:44 AM, Alex Zavatone via groups.io <zav@...> wrote:

Report the properties of the URL beforehand.  At one case, I even had my old reporter get the properties, put them in a string and mail them to a specific email account to see what was going on.

You can also log to a specific file on disk and then open that up and tail it from the terminal to get only your specific output written to that file and updated instantly on screen right before the crash.



On Apr 20, 2020, at 6:22 AM, John Brownie <john_brownie@...> wrote:

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
   MALLOC_LARGE_REUSABLE  0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
   MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                   0x00007fff6e14381d objc_msgSend + 29
1   com.apple.CoreFoundation          0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
-- 
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland







--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Crash, but only in release version

Alex Zavatone
 

One thing I forgot is if you are debugging a release version (I expect that this is a Mac app), you may want to make sure that you are not stripping debug symbols.  

On Apr 20, 2020, at 6:44 AM, Alex Zavatone via groups.io <zav@...> wrote:

Report the properties of the URL beforehand.  At one case, I even had my old reporter get the properties, put them in a string and mail them to a specific email account to see what was going on.

You can also log to a specific file on disk and then open that up and tail it from the terminal to get only your specific output written to that file and updated instantly on screen right before the crash.



On Apr 20, 2020, at 6:22 AM, John Brownie <john_brownie@...> wrote:

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
   MALLOC_LARGE_REUSABLE  0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
   MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                   0x00007fff6e14381d objc_msgSend + 29
1   com.apple.CoreFoundation          0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
-- 
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland







Re: Crash, but only in release version

Alex Zavatone
 

Report the properties of the URL beforehand. At one case, I even had my old reporter get the properties, put them in a string and mail them to a specific email account to see what was going on.

You can also log to a specific file on disk and then open that up and tail it from the terminal to get only your specific output written to that file and updated instantly on screen right before the crash.

On Apr 20, 2020, at 6:22 AM, John Brownie <john_brownie@sil.org> wrote:

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
MALLOC_LARGE_REUSABLE 0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
MALLOC_NANO 0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff6e14381d objc_msgSend + 29
1 com.apple.CoreFoundation 0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



Crash, but only in release version

John Brownie
 

I am getting a crash, but only in the release version. I get a very helpful "Error 1" if I try to debug the release version, and logging doesn't get me anything, as the crash prevents the log entry from appearing (I think).

Anyway, the crash is in CFURLCreateWithFileSystemPath, where it's calling length, and I get crash reports like the following:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [40981]

VM Regions Near 0x3eaddd9f4338:
    MALLOC_LARGE_REUSABLE  0000000113885000-0000000114085000 [ 8192K] rw-/rwx SM=PRV
-->
    MALLOC_NANO            0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV

Application Specific Information:
objc_msgSend() selector name: length


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                   0x00007fff6e14381d objc_msgSend + 29
1   com.apple.CoreFoundation          0x00007fff3544dfb5 _CFURLCreateWithFileSystemPath + 67

The VM Regions list can vary a bit, but it's always the same stack trace and signal.

It looks a bit weird that a Core Foundation function is trying to call an Objective-C method. Ironically, this crash is triggered when I'm attempting to show the user an error message, and the upstream call is essentially a call to get a localized version of a string.

Any pointers on how to debug this? How to get the debugger to connect with the release version? Or how to work out what is different between the release and debug versions that might be forcing the error?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Strange controls behaviour in sheet modal window

jader.feijo@...
 

Hi Graham,

I have just encountered this exact same issue, and indeed, keeping a copy around of my window solved the issue. The approach that I took was a little different though and did not require me to create a property in the caller, but rather I managed to find a way to do it all locally.

So, my panel NSWindowController has a method which allows it to be presented in another NSWindow as a panel, here's what the method signature looks like (in Swift):
@objc func presentInWindow(_ window: NSWindow, callback: @escaping FileFormatSelectionResult)
Where FileFormatSelectionResult is a closure defined as:
typealias FileFormatSelectionResult = (SelectedFormat, Bool) -> Void
The closure is stored inside my NSWindowController instance until such time as the user makes a selection (Cancel or Import) which dismisses the sheet. After the sheet is dismissed, the callback closure is called.

This allowed me to write the following code in the caller (in Objective-C) which keeps the sheet NSWindowController around for the duration of the interaction:
__block FileFormatSelectionWindowController *fileFormatSelectionController = [[FileFormatSelectionWindowController alloc] initWithWindowNibName:@"FileFormatSelectionWindow"];
[fileFormatSelectionController presentInWindow:[[document mainWindowController] window] callback:^(enum SelectedFormat format, BOOL cancelled) {
if (!cancelled) {
// do something with the result
}
fileFormatSelectionController = nil;
}];
The __block variable for the panel NSWindowController instance allows the block to capture it, and set it to nil at the end of the interaction, without the need to introduce a property or a local variable in the caller. The same could be accomplished in Swift as well.

I thought I'd post this here in case someone else runs into this issue and needs a simple approach to solving it.

Hope it helps.


Re: String handling not working — am I going nuts?

 



On Apr 6, 2020, at 4:53 PM, Marco S Hyman <marc@...> wrote:

var str = try String(contentsOf: urlContext.url) // (1)
let lines = str.split(separator: “\r\n”) // (3)

works and is faster in that you’ve removed an O(n) operation,

You've also removed support for Unix line endings. Now it only supports Windows line endings; probably a bad idea.



On Apr 7, 2020, at 10:30 AM, Rick Aurbach via groups.io <rlaurb@...> wrote:

So I have a solution, but I don’t understand the original code didn’t work. Any insights?

I'm mystified too, but IMHO enumerateLines is a better way to do it.

—Jens


Re: String handling not working — am I going nuts?

Rick Aurbach
 

Ok, I still don’t understand what’s going on, but I’ve got an alternative solution. (Maybe somebody can clarify this for me??)

WHAT DOESN’T WORK IN MY CONTEXT:

do {
    var str = try String(contentsOf: urlContext.url)
    str.removeAll { $0 == “\r” }
    let lines = str.split(separator: “\n”)
   …
} catch {}

BUT THE FOLLOWING WORKS NICELY::

var lines = [String]()
do {
    let str = try String(contentsOf: urlContext.url)
    str.enumerateLines { (line, stop) in
        lines.append(line)
        stop = false
    }
} catch {}

Note: since enumerateLines is not labeled ’throws’, Xcode complains if I try to throw from it’s closure. So instead of working one line at a time within the closure, I need to build a line array and then process it (one line at a time) in a second do-block.

So I have a solution, but I don’t understand the original code didn’t work. Any insights?

Cheers,

Rick Aurbach


Re: manual item enabling

Graham Cox
 

Hi Kurt, re-reading the documentation on basic event handling might help:

particularly “The Path of Key Events”, and “Handling Key Equivalents"

Note that I mentioned NSResponder. Both NSApplication and NSView both subclass NSResponder, so there are two very different objects that receive events. I was thinking about this in terms of NSView, but NSApplication does things a little differently.

but if keyDown is what calls performKeyEquivalent, then how could performKeyEquivalent help

NSApplication’s -sendEvent: calls -performKeyEquivalent: but AFAICS, no -keyDown: method ever calls it - it’s always handled before that is called.

It’s still a little unclear to me why the standard approach that Cocoa takes to menu updating can’t be used here. In both the key equivalent case and the click on the menu case, the responder chain is asked to -validateMenuItem: for as many menu items as needed (I would expect this to be just one for a key equivalent), and you just return YES or NO to indicate the enable state of the item. But that validation method is free to examine any other property of the menu item, so if there is some legacy there of command numbers or whatever, the validation method can use it. The validation method can also change the text of a menu item.

Now I recall that in TCL, the whole menu structure (per menu? I forget now) was passed to the responder chain so it was less granular than Cocoa, so the update mechanism would enable a whole bunch of items at once. Is my understanding correct that you’d rather port that code more or less “as is”? In which case possibly the menu delegate approach is going to be more appropriate than validating individual items.

But I would suggest that handling individual items is not so very different - it’s the same concept, just broken down a little more so that you deal with one item at a time. In fact your code is generally written so that that multiple-calling situation is irrelevant. The same validation method handles ALL the cases pertaining to the current responder object, just as the TCL update method does. It’s just that the Cocoa method is called multiple times, but only one case applies, and the TCL method is called only once, but multiple cases apply. The difference between the two is actually minor. In the cocoa case, you just need to add an additional if() per item that checks that the passed item is actually the one you want.

so for example, in the TCL case, you’d have had code that was equivalent to:

- (void) updateMenu:(CMenu*) menu
{
menu.items[kNewItem].enable = YES;
menu.items[kOpenItem].enable = YES;
menu.items[kQuitItem].enable = YES;

[nextResponder updateMenu:menu];
}

and in Cocoa, you change that to:

- (BOOL) validateMenuItem:(NSMenuItem*) item
{
if( item.command == kNewItem )
return YES;

if( item.command == kOpenItem )
return YES;

if( item.command == kQuitItem )
return YES;

return [nextResponder validateMenuItem:item];
}

Note this is just conceptual code - there is no method on NSMenuItem called -command. So you’d have to deal with that difference, or use the menu item's -action property instead, which is the usual way.

So in my view, you’re overthinking this. Just let Cocoa do its thing and adapt the validation to suit rather than try to stick with your TCL approach and adapt the event handling to suit.

Of course I don’t have your code in front of me, so this may be off base.

—Graham





On 7 Apr 2020, at 10:47 am, Kurt Bigler <kkblists@...> wrote:

Hi,

Thanks Eric, Allan, and Graham for your help on this last November 24-25.  This issue got pushed into the background and I'm only now getting back to it.  I'm replying specifically to Graham's post due to the specifics I'm addressing.

I did not yet take Eric's advice to use menuNeedsUpdate since I'd like to take a shortcut for an interrim release we'd now like to do ASAP.  So this addresses that shortcut described by both Graham and Allan.

I used the approach of overriding NSMenu for the main app menu.  I update menus in the performKeyEquivalent override before calling super.  It does not help.

Curiously also and by implication in contrast with what Graham stated, I'm seeing performKeyEquivalent gets called from within my application-level override of sendEvent, where I added code conditional on [event type] == NSKeyDown prior to [super sendEvent...].  I use that code now just to log the occurrence.  But previously I had tried updating menus there, which also did not work.

So to state the obvious, if per Graham, "key equivalents are pulled out before -keyDown" but if keyDown is what calls performKeyEquivalent, then how could performKeyEquivalent help?  In fact it doesn't.  But I also see Graham mentioning views as possible places to trap performKeyEquivalent and I also wonder whether there is something about that that I'm missing.

Thanks!

-Kurt


On 11/24/19 2:58:17 PM, Graham Cox wrote:
Kurt,
The menu key equivalents are pulled out before -keyDown: is called. You can override that event in -performKeyEquivalent:, a methof of NSResponder (and therefore views, etc). You can probably call your menu update method and then call super to handle the key equivalent.
[...]
—Graham
On 25 Nov 2019, at 8:28 am, Kurt Bigler via Cocoa-dev <cocoa-dev@...> wrote:

The last possible moment for key equivalents is a keyDown event. Unfortunately Cocoa doesn't seem to let me catch this event and act on it to update menus prior to key equivalent processing.

-Kurt Bigler



Re: String handling not working — am I going nuts?

Marco S Hyman
 

do {
var str = try String(contentsOf: urlContext.url) // (1)
str.removeAll { $0 == “\r” } // (2)
let lines = str.split(separator: “\n”) // (3)
Oh. Yeah. That’s too much work.


var str = try String(contentsOf: urlContext.url) // (1)
let lines = str.split(separator: “\r\n”) // (3)

works and is faster in that you’ve removed an O(n) operation,

I created your test file with crlf end-of-line (thank you bbedit) and tried it using this code in a playground:

let url = URL(fileURLWithPath: “/path/to.foo.txt”)
if let str = try? String(contentsOf: url) {
let lines = str.split(separator: "\r\n") // (3)
print(lines)
}

Marc


Re: String handling not working — am I going nuts?

 

Doesn't Swift's String class have higher-level methods to break a string by lines? NSString certainly did.

—Jens


Re: String handling not working — am I going nuts?

Marco S Hyman
 

On Apr 6, 2020, at 3:29 PM, Rick Aurbach via groups.io <rlaurb=me.com@groups.io> wrote:

The file is UTF8, with lines terminated in “\r\n”
Are the lines terminated with a carriage return/line feed pair or are they terminated with the character string "\r\n”. The results of step 2 and 3 are what I’d expect if the string contained the character string \r\n instead of a carriage return/line feed pair.


String handling not working — am I going nuts?

Rick Aurbach
 

Can you take a look at this for me? I think I’ve been cooped up at home too long, because whatever is going on, I’m missing it.
 
Context:
I’m working on a data import function for a new app. It looks like I’ve set things up correctly, since if I drop the file (from my desktop to the Simulator), the sceneDelegate’s scene(_:openURLContexts:) method is called. I set up an operations queue to handle the input in background and instantiate the Operation subclass, passing it a URLContext.
 
In the Operation subclass’s main() method, I do the following:
 
do {
var str = try String(contentsOf: urlContext.url) // (1)
str.removeAll {  $0 == “\r” } // (2)
let lines = str.split(separator: “\n”) // (3)
 
The file is UTF8, with lines terminated in “\r\n”
 
After executing (1), the debugger shows:
 
str String "sugar,NO\r\n1/1/20,154\r\n1/2/20,141\r\n1/3/20,147\r\n1/4/20,154\r\n1/5/20,172\r\n1/6/20,170\r\n1/7/20,164\r\n1/8/20,201\r\n1/9/20,163\r\n1/10/20,171\r\n1/11/20,209\r\n1/12/20,202\r\n1/13/20,164\r\n1/14/20,232\r\n1/15/20,182\r\n1/16/20,211\r\n1/17/20,175\r\n1/18/20,174\r\n1/19/20,147\r\n1/20/20,148\r\n1/21/20,150\r\n1/22/20,141\r\n1/23/20,165\r\n1/24/20,169\r\n1/25/20,260\r\n1/26/20,168\r\n1/27/20,179\r\n1/28/20,160\r\n1/29/20,155\r\n1/30/20,181\r\n1/31/20,156\r\n2/1/20,178\r\n2/2/20,202\r\n2/3/20,188\r\n2/4/20,175\r\n2/5/20,157\r\n2/6/20,166\r\n2/7/20,165\r\n2/8/20,146\r\n2/9/20,192\r\n2/10/20,178\r\n2/11/20,172\r\n2/12/20,180\r\n2/13/20,140”
 
which is what I expect.
 
After executing (2), the string is UNCHANGED. (i.e., the “\r” characters were not removed.
 
After executing (3), the ‘lines’ variable contains 1 item which is the whole string (with both the “\r” and “\n” characters present.
 
I’m going nuts here. What’s going on??

Cheers,

Rick Aurbach

221 - 240 of 1454