fbcocoa Digest 2 Jul 2010 08:17:05 -0000 Issue 22

#1 · July 2, 2010, 6:39 am

Quote from Forum Archives on July 2, 2010, 6:39 am
Posted by: carnationsoftware <carnationsoftware@...>

Don't know if this is relevant or not but this is the way you do alerts in Objective-C on the iPhone

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"My Alert Title"

message: @"My Alert Message"

delegate: self

cancelButtonTitle:nil

otherButtonTitles:@"OK", nil];

[alert show];

[alert release];

Rich

On Jul 2, 2010, at 3:17 AM, [email protected] wrote:

fbcocoa Digest 2 Jul 2010 08:17:05 -0000 Issue 22

Topics (messages 126 through 141):

Re: Notification Manager ( old ) replacement
126 by: Bernie
127 by: Brian S
128 by: Brian S
129 by: Brian S
130 by: Bernie
131 by: Brian S
132 by: Bernie
133 by: Bernie
134 by: Brian S
135 by: Brian S
136 by: Brian S
137 by: Bernie
138 by: Bernie
139 by: Bernie
140 by: Brian S
141 by: Bernie

Administrivia:

To subscribe to the digest, e-mail:
<[email protected]>

To unsubscribe from the digest, e-mail:
<[email protected]>

To post to the list, e-mail:
<[email protected]>

----------------------------------------------------------------------

From: Bernie <[email protected]>

Date: June 30, 2010 6:38:38 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

'---------------
/*
  RequestUserAttention

  Bernie Wylde 20100630

  Notes:
- 'Compile as Objective-C'
- Run then click on another app

  Request types:
- _kRUACritical bounces the dock icon until the app becomes active
- _kRUAInformational bounces the dock icon for one second
- Because this example puts up a modal dialog, the dock icon continues to bounce when _kRUAInformational
  is used (see requestUserAttention: method discussion in NSApplication Class Reference)
*/

include "Tlbx Dialogs.incl"
include "Util_CE.incl"

BeginCFunction
long RequestUserAttention( UInt32 requestType )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
NSInteger requestIdentifier = [[NSApplication sharedApplication] requestUserAttention:requestType];
[localPool release];
return (long)requestIdentifier;
}

void CancelUserAttentionRequest( long requestIdentifier )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
[[NSApplication sharedApplication] cancelUserAttentionRequest:(NSInteger)requestIdentifier];
[localPool release];
}
EndC
toolbox fn RequestUserAttention( UInt32 requestType ) = long
toolbox CancelUserAttentionRequest( long requestIdentifier )

// request types
_kRUACritical = 0
_kRUAInformational = 10

local fn MyAppDeactivatedHandler( nextHandler as EventHandlerCallRef, theEvent as EventRef, userData as ptr ) as OSStatus
'~'1
dim as DialogRef   dialogRef

fn RequestUserAttention( _kRUACritical )
fn CreateStandardAlert( _kAlertNoteAlert, @"kEventAppDeactivated.", 0, #0, @dialogRef )
fn RunStandardAlert( dialogRef, #0, #0 )
end fn = _noErr

fn CEAddEvent( _kEventClassApplication, _kEventAppDeactivated )
fn CEInstallApplicationEventHandler( @fn MyAppDeactivatedHandler, 0, 0 )

RunApplicationEventLoop()
'---------------

Bernie

From: Brian S <[email protected]>

Date: June 30, 2010 10:41:31 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Brian S <[email protected]>

Date: June 30, 2010 10:54:08 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

fn CreateStandardAlert( _kAlertNoteAlert, @"kEventAppDeactivated.", 0, #0, @dialogRef )
fn RunStandardAlert( dialogRef, #0, #0 )

As Bernie knows, I’ve been using these calls for most of my error handling. If you type “CreateStandardAlert” ( san quotes ) into Xcode docs there are two API entries on the top left. One says Dialog Manager is Legacy and the other doesn’t.

<Screen shot 2010-06-30 at 8.50.41 AM.png>

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Brian S <[email protected]>

Date: June 30, 2010 12:32:59 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 8:54 AM, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

fn CreateStandardAlert( _kAlertNoteAlert, @"kEventAppDeactivated.", 0, #0, @dialogRef )
fn RunStandardAlert( dialogRef, #0, #0 )

As Bernie knows, I’ve been using these calls for most of my error handling. If you type “CreateStandardAlert” ( san quotes ) into Xcode docs there are two API entries on the top left. One says Dialog Manager is Legacy and the other doesn’t.

<Screen shot 2010-06-30 at 8.50.41 AM.png>

Looks like NSAlert can do exactly the same thing. The following code is from Apple’s docs:

NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:@"OK"];

[alert addButtonWithTitle:@"Cancel"];

[alert setMessageText:@"Delete the record?"];

[alert setInformativeText:@"Deleted records cannot be restored."];

[alert setAlertStyle:NSWarningAlertStyle];

Also, the “class factory” method ( apparently an older method ---but less verbose ) is shown in the docs too:

NSAlert *alert = [NSAlert alertWithMessageText:@"Delete the record?"

defaultButton:@"OK" alternateButton:@"Cancel"

otherButton:nil informativeTextWithFormat:

@"Deleted records cannot be restored."];

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: June 30, 2010 6:19:04 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On 30 Jun 2010, at 16:41, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Would bringing the modal dialog to the front automatically bring the app to the front? If so, that may not be desirable.

Bernie

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Brian S <[email protected]>

Date: June 30, 2010 7:27:36 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 4:19 PM, Bernie wrote:

On 30 Jun 2010, at 16:41, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Would bringing the modal dialog to the front automatically bring the app to the front? If so, that may not be desirable.

Don’t know. However, as you point out, the modal dialog should not bring the background app to the front. The Notification Manager call does not bring the app to the foreground but the modal dialog does come to the foreground. That is the behavior I’m hoping to find.

Brian

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 1, 2010 1:54:22 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On 1 Jul 2010, at 01:27, Brian S wrote:

On Jun 30, 2010, at 4:19 PM, Bernie wrote:

On 30 Jun 2010, at 16:41, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Would bringing the modal dialog to the front automatically bring the app to the front? If so, that may not be desirable.

Don’t know. However, as you point out, the modal dialog should not bring the background app to the front. The Notification Manager call does not bring the app to the foreground but the modal dialog does come to the foreground. That is the behavior I’m hoping to find.

If you use NSAlert, I suppose you could do:

[[alert window] setLevel:NSFloatingWindowLevel];

May not be what you want because it is always in front of other app windows.

Bernie

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 1, 2010 6:02:35 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

This version combines dock bounce and alert in one call. It also eliminates multiple alerts.

'---------------
/*
  RequestUserAttention

  Bernie Wylde 20100630

  Notes:
- 'Compile as Objective-C'
- Run then click on another app
*/

include "Tlbx Dialogs.incl"
include "Util_CE.incl"

BeginCFunction
long RequestUserAttention( CFStringRef title, CFStringRef msg, CFStringRef info, CFStringRef defaultBtn, CFStringRef alternateBtn, CFStringRef otherBtn )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
NSInteger result = 0;
static BOOL displayed;
if ( displayed == NO ) {
[[NSApplication sharedApplication] requestUserAttention:NSCriticalRequest];
NSAlert *alert = [NSAlert alertWithMessageText:(NSString *)msg
                                  defaultButton:(NSString *)defaultBtn
                                alternateButton:(NSString *)alternateBtn
                                    otherButton:(NSString *)otherBtn
                      informativeTextWithFormat:(NSString *)info];
if ( title != nil ) [[alert window] setTitle:(NSString *)title];
[[alert window] setLevel:NSFloatingWindowLevel];
displayed = YES;
result = [alert runModal];
displayed = NO;
}
[localPool release];
return (long)result;
}
EndC
toolbox fn RequestUserAttention( CFStringRef title, CFStringRef msg, CFStringRef info, CFStringRef defaultBtn, CFStringRef altBtn, CFStringRef otherBtn ) = long

local fn MyAppDeactivatedHandler( nextHandler as EventHandlerCallRef, theEvent as EventRef, userData as ptr ) as OSStatus
'~'1
if ( fn RequestUserAttention( 0, @"We have a problem.", @"Brian's App must quit.", 0, 0, 0 ) ) then end
end fn = _noErr

fn CEAddEvent( _kEventClassApplication, _kEventAppDeactivated )
fn CEInstallApplicationEventHandler( @fn MyAppDeactivatedHandler, 0, 0 )

RunApplicationEventLoop()
'---------------

Bernie

From: Brian S <[email protected]>

Date: July 1, 2010 11:14:29 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 4:02 AM, Bernie wrote:

This version combines dock bounce and alert in one call. It also eliminates multiple alerts.

Thanks Bernie. I will review it later today.

[[NSApplication sharedApplication] requestUserAttention:NSCriticalRequest];

My own attempt failed with a “kCGErrorInvalidConnection” runtime error ( i.e. it compiled and linked fine ) which says the connection to the window server failed.

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue. Your prior example clearly uses the call but I overlooked its importance.

Question: how did you discover the NSApplication sharedApplication call was required? When I was coding my own example yesterday ( see my Q&D attempt below just for grins ) it was clear something was missing but I didn’t find a simple solution.

Thanks again,

Brian S

'--------------
BeginCFunction
#import <Cocoa/Cocoa.h>

UInt32 MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, NSAlertStyle warningStyle )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:(NSString *)okBtn];

[alert addButtonWithTitle:(NSString *)canBtn];

[alert setMessageText:(NSString *)msg1];

[alert setInformativeText:(NSString *)msg2];

[alert setAlertStyle:(NSAlertStyle)warningStyle];
NSInteger whichBtn = [alert runModal];
[alert release];
[localPool release];
return whichBtn;
}

EndC
toolbox fn MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, UInt32 warningStyle ) = UInt32

fn MyShowAlert( @"OK", @"Cancel", @"Delete Contents of Disk?", @"Warning: Could be fatal!", 1 )

RunApplicationEventLoop()
'--------------

From: Brian S <[email protected]>

Date: July 1, 2010 11:19:56 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 9:14 AM, Brian S wrote:

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue.

and it does. Inserting [NSApplication sharedApplication]; just prior to the NSAlert alloc/init allows it to run.

Brian S

From: Brian S <[email protected]>

Date: July 1, 2010 11:48:50 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 9:14 AM, Brian S wrote:

On Jul 1, 2010, at 4:02 AM, Bernie wrote:

This version combines dock bounce and alert in one call. It also eliminates multiple alerts.

Thanks Bernie. I will review it later today.

Very nice! The idea of setting the alert to be a floating window occurred to me but I didn’t know how to implement it. I like the use of the C static var ( without resorting to a global ) to handle multiple deactivations when the modal dialog hasn’t been dismissed.

very minor note: the Tlbx Dialogs.incl is obviously superfluous

Excellent! Thanks.

Brian S

From: Bernie <[email protected]>

Date: July 1, 2010 12:07:27 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

Brian wrote:

On Jul 1, 2010, at 9:14 AM, Brian S wrote:

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue.

and it does. Inserting [NSApplication sharedApplication]; just prior to the NSAlert alloc/init allows it to run.

I hadn't tried displaying the alert without the call to requestUserAttention:. If I had, I may have realised that NSApplicationLoad(); is required. Looks like [NSApplication sharedApplication]; does same thing.

Bernie

From: Bernie <[email protected]>

Date: July 1, 2010 12:31:54 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

I hadn't tried displaying the alert without the call to requestUserAttention:. If I had, I may have realised that NSApplicationLoad(); is required. Looks like [NSApplication sharedApplication]; does same thing.

btw, it looks like the global constant NSApp can be used instead of [NSApplication sharedApplication] (as long as NSApplicationLoad() has already been called). So, this line can be simplified:

[NSApp requestUserAttention:NSCriticalRequest];

Bernie

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 1, 2010 12:49:44 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

An updated RequestUserAttention example is now in the FBCocoa files area: <https://welovegod.org/groups/fbcocoa/www>.

Bernie

From: Brian S <[email protected]>

Date: July 1, 2010 2:56:42 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 9:19 AM, Brian S wrote:

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue.

and it does. Inserting [NSApplication sharedApplication]; just prior to the NSAlert alloc/init allows it to run.

For those following along, here is the working Alert code ( without the notification ---bouncing dock icon etc. ). It could be used to replace legacy code ( such as: CreateStandardAlert and RunStandardAlert as found in the recent Applescript example named: LaunchMailPressSendII ). Bernie’s code with the bouncing dock icon is the replacement for the NM calls but a general alert function is helpful too. Even though the Cocoa enum for third button return value is shown, it is not used/coded in this example. Returning a UInt32 was Q&D since runModal actually returns an NSInteger.

'--------------

Include "ConsoleWindow"

begin enum 1000

_NSAlertFirstButtonReturn

_NSAlertSecondButtonReturn

_NSAlertThirdButtonReturn

end enum

BeginCFunction

UInt32 MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, NSAlertStyle warningStyle )

{

NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];

[NSApplication sharedApplication]; // carbon calling Cocoa must do this or NSApplicationLoad()

NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:(NSString *)okBtn];

[alert addButtonWithTitle:(NSString *)canBtn];

[alert setMessageText:(NSString *)msg1];

[alert setInformativeText:(NSString *)msg2];

[alert setAlertStyle:(NSAlertStyle)warningStyle];

NSInteger whichBtn = [alert runModal];

[localPool release];

return whichBtn;

}

EndC

toolbox fn MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, UInt32 warningStyle ) = UInt32

dim as UInt32 whichBtn

select fn MyShowAlert( @"OK", @"Cancel", @"Delete Contents of Disk?", @"Warning: Could be fatal!", 1 )

case _NSAlertFirstButtonReturn

print "OK button pressed"



case _NSAlertSecondButtonReturn

print "Cancel button pressed"

case _NSAlertThirdButtonReturn

print "Third button pressed"

end select

RunApplicationEventLoop()

'--------------

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 2, 2010 3:16:48 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

Brian wrote:

BeginCFunction

UInt32 MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, NSAlertStyle warningStyle )

{

NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];

[NSApplication sharedApplication]; // carbon calling Cocoa must do this or NSApplicationLoad()

NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:(NSString *)okBtn];

[alert addButtonWithTitle:(NSString *)canBtn];

[alert setMessageText:(NSString *)msg1];

[alert setInformativeText:(NSString *)msg2];

[alert setAlertStyle:(NSAlertStyle)warningStyle];

NSInteger whichBtn = [alert runModal];

[localPool release];

return whichBtn;

}

EndC

Couple comments.

[1] AFAIK, repeatedly calling NSApplicationLoad() doesn't cause any problems but is inefficient. Probably better to declare it:
toolbox fn NSApplicationLoad = Boolean

and call just once during app init:
fn NSApplicationLoad()

An added advantage is we then don't have to remember to include that line in every function of Objective-C code in our app.

[2] Quite often, we can use dot syntax to set a class' instance variable values (similar to setting an FB record field value). For example, this line in Brian's code:
[alert setMessageText:(NSString *)msg1];

could also be written as:
alert.messageText = (NSString *)msg1;

Bernie

Rich Love - Carnation Software

Get 'Say it & Mail it' for iPhone

http://www.SayitMailit.com

MacWise Terminal emulation for Macintosh

http://www.CarnationSoftware.com

Twitter - http://twitter.com/CarnationSW

Email - [email protected]

512 858-9234

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

Posted by: carnationsoftware <carnationsoftware@...>

Don't know if this is relevant or not but this is the way you do alerts in Objective-C on the iPhone

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"My Alert Title"

message: @"My Alert Message"

delegate: self

cancelButtonTitle:nil

otherButtonTitles:@"OK", nil];

[alert show];

[alert release];

Rich

On Jul 2, 2010, at 3:17 AM, [email protected] wrote:

fbcocoa Digest 2 Jul 2010 08:17:05 -0000 Issue 22

Topics (messages 126 through 141):

Re: Notification Manager ( old ) replacement
126 by: Bernie
127 by: Brian S
128 by: Brian S
129 by: Brian S
130 by: Bernie
131 by: Brian S
132 by: Bernie
133 by: Bernie
134 by: Brian S
135 by: Brian S
136 by: Brian S
137 by: Bernie
138 by: Bernie
139 by: Bernie
140 by: Brian S
141 by: Bernie

Administrivia:

To subscribe to the digest, e-mail:
<[email protected]>

To unsubscribe from the digest, e-mail:
<[email protected]>

To post to the list, e-mail:
<[email protected]>

----------------------------------------------------------------------

From: Bernie <[email protected]>

Date: June 30, 2010 6:38:38 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

'---------------
/*
  RequestUserAttention

  Bernie Wylde 20100630

  Notes:
- 'Compile as Objective-C'
- Run then click on another app

  Request types:
- _kRUACritical bounces the dock icon until the app becomes active
- _kRUAInformational bounces the dock icon for one second
- Because this example puts up a modal dialog, the dock icon continues to bounce when _kRUAInformational
  is used (see requestUserAttention: method discussion in NSApplication Class Reference)
*/

include "Tlbx Dialogs.incl"
include "Util_CE.incl"

BeginCFunction
long RequestUserAttention( UInt32 requestType )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
NSInteger requestIdentifier = [[NSApplication sharedApplication] requestUserAttention:requestType];
[localPool release];
return (long)requestIdentifier;
}

void CancelUserAttentionRequest( long requestIdentifier )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
[[NSApplication sharedApplication] cancelUserAttentionRequest:(NSInteger)requestIdentifier];
[localPool release];
}
EndC
toolbox fn RequestUserAttention( UInt32 requestType ) = long
toolbox CancelUserAttentionRequest( long requestIdentifier )

// request types
_kRUACritical = 0
_kRUAInformational = 10

local fn MyAppDeactivatedHandler( nextHandler as EventHandlerCallRef, theEvent as EventRef, userData as ptr ) as OSStatus
'~'1
dim as DialogRef   dialogRef

fn RequestUserAttention( _kRUACritical )
fn CreateStandardAlert( _kAlertNoteAlert, @"kEventAppDeactivated.", 0, #0, @dialogRef )
fn RunStandardAlert( dialogRef, #0, #0 )
end fn = _noErr

fn CEAddEvent( _kEventClassApplication, _kEventAppDeactivated )
fn CEInstallApplicationEventHandler( @fn MyAppDeactivatedHandler, 0, 0 )

RunApplicationEventLoop()
'---------------

Bernie

From: Brian S <[email protected]>

Date: June 30, 2010 10:41:31 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Brian S <[email protected]>

Date: June 30, 2010 10:54:08 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

fn CreateStandardAlert( _kAlertNoteAlert, @"kEventAppDeactivated.", 0, #0, @dialogRef )
fn RunStandardAlert( dialogRef, #0, #0 )

As Bernie knows, I’ve been using these calls for most of my error handling. If you type “CreateStandardAlert” ( san quotes ) into Xcode docs there are two API entries on the top left. One says Dialog Manager is Legacy and the other doesn’t.

<Screen shot 2010-06-30 at 8.50.41 AM.png>

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Brian S <[email protected]>

Date: June 30, 2010 12:32:59 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 8:54 AM, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

fn CreateStandardAlert( _kAlertNoteAlert, @"kEventAppDeactivated.", 0, #0, @dialogRef )
fn RunStandardAlert( dialogRef, #0, #0 )

As Bernie knows, I’ve been using these calls for most of my error handling. If you type “CreateStandardAlert” ( san quotes ) into Xcode docs there are two API entries on the top left. One says Dialog Manager is Legacy and the other doesn’t.

<Screen shot 2010-06-30 at 8.50.41 AM.png>

Looks like NSAlert can do exactly the same thing. The following code is from Apple’s docs:

NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:@"OK"];

[alert addButtonWithTitle:@"Cancel"];

[alert setMessageText:@"Delete the record?"];

[alert setInformativeText:@"Deleted records cannot be restored."];

[alert setAlertStyle:NSWarningAlertStyle];

Also, the “class factory” method ( apparently an older method ---but less verbose ) is shown in the docs too:

NSAlert *alert = [NSAlert alertWithMessageText:@"Delete the record?"

defaultButton:@"OK" alternateButton:@"Cancel"

otherButton:nil informativeTextWithFormat:

@"Deleted records cannot be restored."];

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: June 30, 2010 6:19:04 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On 30 Jun 2010, at 16:41, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Would bringing the modal dialog to the front automatically bring the app to the front? If so, that may not be desirable.

Bernie

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Brian S <[email protected]>

Date: June 30, 2010 7:27:36 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jun 30, 2010, at 4:19 PM, Bernie wrote:

On 30 Jun 2010, at 16:41, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Would bringing the modal dialog to the front automatically bring the app to the front? If so, that may not be desirable.

Don’t know. However, as you point out, the modal dialog should not bring the background app to the front. The Notification Manager call does not bring the app to the foreground but the modal dialog does come to the foreground. That is the behavior I’m hoping to find.

Brian

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 1, 2010 1:54:22 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On 1 Jul 2010, at 01:27, Brian S wrote:

On Jun 30, 2010, at 4:19 PM, Bernie wrote:

On 30 Jun 2010, at 16:41, Brian S wrote:

On Jun 30, 2010, at 4:38 AM, Bernie wrote:

Brian wrote:

Even though the old Notification Manager calls still work ( and there is no need to use pascal strings because they accept a pointer ), I’m hoping to find a modern replacement ( could be ’NS’ of ‘CF’ ). Searches of Xcode docs and the Carbon dev list did not find such support( looks like Eric Schlegel wrote a note about not having time to write a replacement ). I can find CFUserNotification ( bw wrote some nice examples in FB examples ) but a) I’m not sure if those work when the app is in the background and b) they don’t bounce the doc icon of the app. The NSNotification stuff doesn’t appear to cover this area on first reading but I could be wrong since it was only a cursory pass. Any thoughts?

I wonder if this will do it?

Excellent idea! I obviously didn’t know where to look. Only issue I can see OTTOMH is the modal dialog is not brought to the foreground ( see quote below from Apple’s Xcode docs ) which means it can potentially be hidden if the foreground app’s window covers it ( the old Notification Manager brings the dialog to the foreground ). I’ll play with this later and to see if there is an option to bring the dialog to the foreground. Thanks Bernie.

Noted in NSApplication requestUserAttention:

"The modal panel is not brought to the front for an inactive application”.

Would bringing the modal dialog to the front automatically bring the app to the front? If so, that may not be desirable.

Don’t know. However, as you point out, the modal dialog should not bring the background app to the front. The Notification Manager call does not bring the app to the foreground but the modal dialog does come to the foreground. That is the behavior I’m hoping to find.

If you use NSAlert, I suppose you could do:

[[alert window] setLevel:NSFloatingWindowLevel];

May not be what you want because it is always in front of other app windows.

Bernie

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 1, 2010 6:02:35 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

This version combines dock bounce and alert in one call. It also eliminates multiple alerts.

'---------------
/*
  RequestUserAttention

  Bernie Wylde 20100630

  Notes:
- 'Compile as Objective-C'
- Run then click on another app
*/

include "Tlbx Dialogs.incl"
include "Util_CE.incl"

BeginCFunction
long RequestUserAttention( CFStringRef title, CFStringRef msg, CFStringRef info, CFStringRef defaultBtn, CFStringRef alternateBtn, CFStringRef otherBtn )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
NSInteger result = 0;
static BOOL displayed;
if ( displayed == NO ) {
[[NSApplication sharedApplication] requestUserAttention:NSCriticalRequest];
NSAlert *alert = [NSAlert alertWithMessageText:(NSString *)msg
                                  defaultButton:(NSString *)defaultBtn
                                alternateButton:(NSString *)alternateBtn
                                    otherButton:(NSString *)otherBtn
                      informativeTextWithFormat:(NSString *)info];
if ( title != nil ) [[alert window] setTitle:(NSString *)title];
[[alert window] setLevel:NSFloatingWindowLevel];
displayed = YES;
result = [alert runModal];
displayed = NO;
}
[localPool release];
return (long)result;
}
EndC
toolbox fn RequestUserAttention( CFStringRef title, CFStringRef msg, CFStringRef info, CFStringRef defaultBtn, CFStringRef altBtn, CFStringRef otherBtn ) = long

local fn MyAppDeactivatedHandler( nextHandler as EventHandlerCallRef, theEvent as EventRef, userData as ptr ) as OSStatus
'~'1
if ( fn RequestUserAttention( 0, @"We have a problem.", @"Brian's App must quit.", 0, 0, 0 ) ) then end
end fn = _noErr

fn CEAddEvent( _kEventClassApplication, _kEventAppDeactivated )
fn CEInstallApplicationEventHandler( @fn MyAppDeactivatedHandler, 0, 0 )

RunApplicationEventLoop()
'---------------

Bernie

From: Brian S <[email protected]>

Date: July 1, 2010 11:14:29 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 4:02 AM, Bernie wrote:

This version combines dock bounce and alert in one call. It also eliminates multiple alerts.

Thanks Bernie. I will review it later today.

[[NSApplication sharedApplication] requestUserAttention:NSCriticalRequest];

My own attempt failed with a “kCGErrorInvalidConnection” runtime error ( i.e. it compiled and linked fine ) which says the connection to the window server failed.

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue. Your prior example clearly uses the call but I overlooked its importance.

Question: how did you discover the NSApplication sharedApplication call was required? When I was coding my own example yesterday ( see my Q&D attempt below just for grins ) it was clear something was missing but I didn’t find a simple solution.

Thanks again,

Brian S

'--------------
BeginCFunction
#import <Cocoa/Cocoa.h>

UInt32 MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, NSAlertStyle warningStyle )
{
NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];
NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:(NSString *)okBtn];

[alert addButtonWithTitle:(NSString *)canBtn];

[alert setMessageText:(NSString *)msg1];

[alert setInformativeText:(NSString *)msg2];

[alert setAlertStyle:(NSAlertStyle)warningStyle];
NSInteger whichBtn = [alert runModal];
[alert release];
[localPool release];
return whichBtn;
}

EndC
toolbox fn MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, UInt32 warningStyle ) = UInt32

fn MyShowAlert( @"OK", @"Cancel", @"Delete Contents of Disk?", @"Warning: Could be fatal!", 1 )

RunApplicationEventLoop()
'--------------

From: Brian S <[email protected]>

Date: July 1, 2010 11:19:56 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 9:14 AM, Brian S wrote:

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue.

and it does. Inserting [NSApplication sharedApplication]; just prior to the NSAlert alloc/init allows it to run.

Brian S

From: Brian S <[email protected]>

Date: July 1, 2010 11:48:50 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 9:14 AM, Brian S wrote:

On Jul 1, 2010, at 4:02 AM, Bernie wrote:

This version combines dock bounce and alert in one call. It also eliminates multiple alerts.

Thanks Bernie. I will review it later today.

Very nice! The idea of setting the alert to be a floating window occurred to me but I didn’t know how to implement it. I like the use of the C static var ( without resorting to a global ) to handle multiple deactivations when the modal dialog hasn’t been dismissed.

very minor note: the Tlbx Dialogs.incl is obviously superfluous

Excellent! Thanks.

Brian S

From: Bernie <[email protected]>

Date: July 1, 2010 12:07:27 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

Brian wrote:

On Jul 1, 2010, at 9:14 AM, Brian S wrote:

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue.

and it does. Inserting [NSApplication sharedApplication]; just prior to the NSAlert alloc/init allows it to run.

I hadn't tried displaying the alert without the call to requestUserAttention:. If I had, I may have realised that NSApplicationLoad(); is required. Looks like [NSApplication sharedApplication]; does same thing.

Bernie

From: Bernie <[email protected]>

Date: July 1, 2010 12:31:54 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

I hadn't tried displaying the alert without the call to requestUserAttention:. If I had, I may have realised that NSApplicationLoad(); is required. Looks like [NSApplication sharedApplication]; does same thing.

btw, it looks like the global constant NSApp can be used instead of [NSApplication sharedApplication] (as long as NSApplicationLoad() has already been called). So, this line can be simplified:

[NSApp requestUserAttention:NSCriticalRequest];

Bernie

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 1, 2010 12:49:44 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

An updated RequestUserAttention example is now in the FBCocoa files area: <https://welovegod.org/groups/fbcocoa/www>.

Bernie

From: Brian S <[email protected]>

Date: July 1, 2010 2:56:42 PM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

On Jul 1, 2010, at 9:19 AM, Brian S wrote:

The above call to sharedApplication is apparently the key and its description sounds like it would solve my issue.

and it does. Inserting [NSApplication sharedApplication]; just prior to the NSAlert alloc/init allows it to run.

For those following along, here is the working Alert code ( without the notification ---bouncing dock icon etc. ). It could be used to replace legacy code ( such as: CreateStandardAlert and RunStandardAlert as found in the recent Applescript example named: LaunchMailPressSendII ). Bernie’s code with the bouncing dock icon is the replacement for the NM calls but a general alert function is helpful too. Even though the Cocoa enum for third button return value is shown, it is not used/coded in this example. Returning a UInt32 was Q&D since runModal actually returns an NSInteger.

'--------------

Include "ConsoleWindow"

begin enum 1000

_NSAlertFirstButtonReturn

_NSAlertSecondButtonReturn

_NSAlertThirdButtonReturn

end enum

BeginCFunction

UInt32 MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, NSAlertStyle warningStyle )

{

NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];

[NSApplication sharedApplication]; // carbon calling Cocoa must do this or NSApplicationLoad()

NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:(NSString *)okBtn];

[alert addButtonWithTitle:(NSString *)canBtn];

[alert setMessageText:(NSString *)msg1];

[alert setInformativeText:(NSString *)msg2];

[alert setAlertStyle:(NSAlertStyle)warningStyle];

NSInteger whichBtn = [alert runModal];

[localPool release];

return whichBtn;

}

EndC

toolbox fn MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, UInt32 warningStyle ) = UInt32

dim as UInt32 whichBtn

select fn MyShowAlert( @"OK", @"Cancel", @"Delete Contents of Disk?", @"Warning: Could be fatal!", 1 )

case _NSAlertFirstButtonReturn

print "OK button pressed"



case _NSAlertSecondButtonReturn

print "Cancel button pressed"

case _NSAlertThirdButtonReturn

print "Third button pressed"

end select

RunApplicationEventLoop()

'--------------

Brian S

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

From: Bernie <[email protected]>

Date: July 2, 2010 3:16:48 AM CDT

To: [email protected]

Subject: Re: [fbcocoa] Notification Manager ( old ) replacement

Brian wrote:

BeginCFunction

UInt32 MyShowAlert( CFStringRef okBtn, CFStringRef canBtn, CFStringRef msg1, CFStringRef msg2, NSAlertStyle warningStyle )

{

NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];

[NSApplication sharedApplication]; // carbon calling Cocoa must do this or NSApplicationLoad()

NSAlert *alert = [[NSAlert alloc] init];

[alert addButtonWithTitle:(NSString *)okBtn];

[alert addButtonWithTitle:(NSString *)canBtn];

[alert setMessageText:(NSString *)msg1];

[alert setInformativeText:(NSString *)msg2];

[alert setAlertStyle:(NSAlertStyle)warningStyle];

NSInteger whichBtn = [alert runModal];

[localPool release];

return whichBtn;

}

EndC

Couple comments.

[1] AFAIK, repeatedly calling NSApplicationLoad() doesn't cause any problems but is inefficient. Probably better to declare it:
toolbox fn NSApplicationLoad = Boolean

and call just once during app init:
fn NSApplicationLoad()

An added advantage is we then don't have to remember to include that line in every function of Objective-C code in our app.

[2] Quite often, we can use dot syntax to set a class' instance variable values (similar to setting an FB record field value). For example, this line in Brian's code:
[alert setMessageText:(NSString *)msg1];

could also be written as:
alert.messageText = (NSString *)msg1;

Bernie

Rich Love - Carnation Software

Get 'Say it & Mail it' for iPhone

http://www.SayitMailit.com

MacWise Terminal emulation for Macintosh

http://www.CarnationSoftware.com

Twitter - http://twitter.com/CarnationSW

Email - [email protected]

512 858-9234

To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]