Application Library - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:20:32Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:20, 26 January 2025
Line 63:		Line 63:
	Just like other AmigaOS libraries, the Application Library must be opened before it is used. Further, at least one of its interfaces must be obtained, depending on the functionality you require. The Application Library has two interfaces, called “application” and “prefsobjects”. You always need to obtain the “application” interface because it provides access to most library functions including application registration. You’ll only need to open the “prefsobjects” interface if you intend to make use of the PrefsObjects preferences system.		Just like other AmigaOS libraries, the Application Library must be opened before it is used. Further, at least one of its interfaces must be obtained, depending on the functionality you require. The Application Library has two interfaces, called “application” and “prefsobjects”. You always need to obtain the “application” interface because it provides access to most library functions including application registration. You’ll only need to open the “prefsobjects” interface if you intend to make use of the PrefsObjects preferences system.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct Library *ApplicationBase = NULL;		struct Library *ApplicationBase = NULL;
	struct ApplicationIFace *IApplication = NULL;		struct ApplicationIFace *IApplication = NULL;
Line 86:		Line 86:
	When your application has run its course, don’t forget to clean up and close both the library and its interface(s):		When your application has run its course, don’t forget to clean up and close both the library and its interface(s):

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IExec->DropInterface((struct Interface *)IPrefsObjects);		IExec->DropInterface((struct Interface *)IPrefsObjects);
	IExec->DropInterface((struct Interface *)IApplication);		IExec->DropInterface((struct Interface *)IApplication);
Line 114:		Line 114:
	Now let’s say we have a program, a media player called Audio Monster created by the fictitious software company SuperCoders, Inc. The piece of C code to handle its registration (and unregistration) might look like this:		Now let’s say we have a program, a media player called Audio Monster created by the fictitious software company SuperCoders, Inc. The piece of C code to handle its registration (and unregistration) might look like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	uint32 appID;		uint32 appID;

Line 154:		Line 154:
	The following function call will register Audio Monster as a unique application:		The following function call will register Audio Monster as a unique application:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	appID = IApplication->RegisterApplication("AudioMonster",		appID = IApplication->RegisterApplication("AudioMonster",
	REGAPP_URLIdentifier, "supercoders.com",		REGAPP_URLIdentifier, "supercoders.com",
Line 271:		Line 271:
	The function to set or change application attributes is SetApplicationAttrs(). It is very similar to SetAttrs() used in Intuition programming, only the first parameter is not a pointer to a BOOPSI object but an application identifier. The appID is followed by a tag list, so several attributes can be set at a time. The following example call will inform the system that the application has iconified (or otherwise hidden its GUI) and that the screen blanker can now come to front freely (assuming that the blanker was forbidden before for some reason). The result value indicates whether the call was successful or not:		The function to set or change application attributes is SetApplicationAttrs(). It is very similar to SetAttrs() used in Intuition programming, only the first parameter is not a pointer to a BOOPSI object but an application identifier. The appID is followed by a tag list, so several attributes can be set at a time. The following example call will inform the system that the application has iconified (or otherwise hidden its GUI) and that the screen blanker can now come to front freely (assuming that the blanker was forbidden before for some reason). The result value indicates whether the call was successful or not:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	BOOL result;		BOOL result;

Line 292:		Line 292:
	Based on this information, the respective piece of code that will find our application in the system might look like this:		Based on this information, the respective piece of code that will find our application in the system might look like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	uint32 appID;		uint32 appID;

Line 331:		Line 331:
	The following three structures are defined for carrying Application Library message data:		The following three structures are defined for carrying Application Library message data:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct ApplicationMsg		struct ApplicationMsg
	{		{
Line 433:		Line 433:
	A simplified event loop code could look like the one below. Note that this example loop only waits for and processes Application Library messages. In real use you'll also want to handle other message types, such as input from the user interface (IDCMP events) or ARexx commands.		A simplified event loop code could look like the one below. Note that this example loop only waits for and processes Application Library messages. In real use you'll also want to handle other message types, such as input from the user interface (IDCMP events) or ARexx commands.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	void event_loop(uint32 appID)		void event_loop(uint32 appID)
	{		{
Line 501:		Line 501:
	Also remember that the notifications are addressed to an abstract ''application'' – this makes them rather different from IDCMP messages, which are always sent to a particular ''window'' (Intuition doesn't know what an application is). Whereas Intuition stops sending IDCMP messages as soon as the window becomes closed/iconified, the Application Library keeps passing messages as long as the application is registered, regardless of program window state. So be smart in your code when processing Application Library notifications: check for the availability of the program window and perform uniconification when necessary. For example, this following piece of code		Also remember that the notifications are addressed to an abstract ''application'' – this makes them rather different from IDCMP messages, which are always sent to a particular ''window'' (Intuition doesn't know what an application is). Whereas Intuition stops sending IDCMP messages as soon as the window becomes closed/iconified, the Application Library keeps passing messages as long as the application is registered, regardless of program window state. So be smart in your code when processing Application Library notifications: check for the availability of the program window and perform uniconification when necessary. For example, this following piece of code

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	/* Don't do this!!! */		/* Don't do this!!! */
	case APPLIBMT_ToFront:		case APPLIBMT_ToFront:
Line 522:		Line 522:
	For example, if you want to tell the Audio Monster application to quit, you send it an APPLIBMT_Quit message like this:		For example, if you want to tell the Audio Monster application to quit, you send it an APPLIBMT_Quit message like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct ApplicationMsg appMsg; // message data structure		struct ApplicationMsg appMsg; // message data structure
	uint32 audioMonsterID; // identifier of the receiver		uint32 audioMonsterID; // identifier of the receiver
Line 545:		Line 545:
	Sending [[#Custom Messages\|custom messages]] is done in a similar fashion, the only difference is that you must use a dedicated [[#Data Structures\|data structure]] instead of the generic ''struct ApplicationMsg''. As our Audio Monster application is a media player, it may as well have defined a set of commands for external control, one of them being “Start playback”. Now if another application wants to tell Audio Monster to start playing, it will need to send the custom message like this:		Sending [[#Custom Messages\|custom messages]] is done in a similar fashion, the only difference is that you must use a dedicated [[#Data Structures\|data structure]] instead of the generic ''struct ApplicationMsg''. As our Audio Monster application is a media player, it may as well have defined a set of commands for external control, one of them being “Start playback”. Now if another application wants to tell Audio Monster to start playing, it will need to send the custom message like this:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct ApplicationCustomMsg customMsg; // custom message data structure		struct ApplicationCustomMsg customMsg; // custom message data structure
	uint32 audioMonsterID; // identifier of the receiver		uint32 audioMonsterID; // identifier of the receiver
Line 571:		Line 571:
	Of all the types of Application Library messages, pop-up notifications are surely the easiest to program. They don’t require any setup or event handling; all it takes is a single function call:		Of all the types of Application Library messages, pop-up notifications are surely the easiest to program. They don’t require any setup or event handling; all it takes is a single function call:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	uint32 result;		uint32 result;

Line 587:		Line 587:
	The look and position of the pop-up box is configurable from the Notifications editor located in the Prefs drawer on your system partition. This is Ringhio’s preferences editor: as we have explained above, it is Ringhio that is responsible for the actual display of notification messages. The pop-up box can also show a small custom image (like the one in the picture above) to make the message more easily identifiable as related to a particular application. The maximum size of the image is 32x32 pixels. It can be any format, provided that there is a datatype for it installed in the system. Being application-specific, these images logically cannot be configured system-wide through the Notifications editor; instead, they are specified as part of the Notify() call. Note that a full path to the image file must be provided:		The look and position of the pop-up box is configurable from the Notifications editor located in the Prefs drawer on your system partition. This is Ringhio’s preferences editor: as we have explained above, it is Ringhio that is responsible for the actual display of notification messages. The pop-up box can also show a small custom image (like the one in the picture above) to make the message more easily identifiable as related to a particular application. The maximum size of the image is 32x32 pixels. It can be any format, provided that there is a datatype for it installed in the system. Being application-specific, these images logically cannot be configured system-wide through the Notifications editor; instead, they are specified as part of the Notify() call. Note that a full path to the image file must be provided:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IApplication->Notify(appID,		IApplication->Notify(appID,
	APPNOTIFY_Title, "Important Message",		APPNOTIFY_Title, "Important Message",
Line 603:		Line 603:
	If the text string provided in the APPNOTIFY_BackMsg tag is an URL, the feature works rather differently. Instead of sending the message to the event stream, this particular URL is opened in your default web browser. Because the process is done through the Launch Handler, your system should be recent enough to have it (the Launch Handler was introduced in AmigaOS 4.1 Update 1). The following piece of code will open Audio Monster’s homepage if the user double-clicks on the Ringhio box. The last in the tag list, APPNOTIFY_CloseOnDC, causes the message box to disappear right after the double click.		If the text string provided in the APPNOTIFY_BackMsg tag is an URL, the feature works rather differently. Instead of sending the message to the event stream, this particular URL is opened in your default web browser. Because the process is done through the Launch Handler, your system should be recent enough to have it (the Launch Handler was introduced in AmigaOS 4.1 Update 1). The following piece of code will open Audio Monster’s homepage if the user double-clicks on the Ringhio box. The last in the tag list, APPNOTIFY_CloseOnDC, causes the message box to disappear right after the double click.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	IApplication->Notify(appID,		IApplication->Notify(appID,
	APPNOTIFY_Title, "Important Message",		APPNOTIFY_Title, "Important Message",

Daniel Jedlicka: /* Minimum Application Library Support */

2020-02-09T20:10:09Z

Minimum Application Library Support

← Older revision		Revision as of 20:10, 9 February 2020
Line 55:		Line 55:
	* Allow the application to be shut down externally in a safe and graceful manner in reaction to the [[#Control Messages\|APPLIBMT_Quit]] message.		* Allow the application to be shut down externally in a safe and graceful manner in reaction to the [[#Control Messages\|APPLIBMT_Quit]] message.

	A ~~failure to implement~~ this suggested minimum ~~will mean~~ that the application manager will be unable to control your application properly and consistently. This ~~may~~ cause confusion on the part of the users and degrade their AmigaOS experience.		Not implementing this suggested minimum means that the application manager will be unable to control your application properly and consistently (some of the manager's control buttons or menu items may appear ineffective). This could cause confusion on the part of the users and degrade their AmigaOS experience.

	== Library Opening Chores ==		== Library Opening Chores ==

Daniel Jedlicka: /* Message Handling */

2017-10-25T13:52:28Z

Message Handling

← Older revision		Revision as of 13:52, 25 October 2017
Line 499:		Line 499:
	Like all [[Exec_Messages_and_Ports#Messages\|Exec messages]] obtained via the GetMsg() function, Application Library messages must be [[Exec_Messages_and_Ports#Replying\|replied to]], i.e. returned to the sender after they have been processed. This is what the last command does in the code above. Remember that all message resources are freed after ReplyMsg() so should you need to use the message data (for example, the custom message text string) beyond the event loop, you must copy it to a memory storage of your own.		Like all [[Exec_Messages_and_Ports#Messages\|Exec messages]] obtained via the GetMsg() function, Application Library messages must be [[Exec_Messages_and_Ports#Replying\|replied to]], i.e. returned to the sender after they have been processed. This is what the last command does in the code above. Remember that all message resources are freed after ReplyMsg() so should you need to use the message data (for example, the custom message text string) beyond the event loop, you must copy it to a memory storage of your own.

	Also remember that the notifications are addressed to an abstract ''application'' – this makes them rather different from IDCMP messages, which are always sent to a particular ''window'' (Intuition is ~~unaware~~ of ~~the~~ application ~~concept~~). Whereas Intuition stops sending IDCMP messages as soon as the window becomes closed/iconified, the Application Library keeps passing messages as long as the application is registered, regardless of program window state. So be smart in your code when processing Application Library notifications: check for the availability of the program window and perform uniconification when necessary. For example, if an APPLIBMT_ToFront command is sent to your iconified application, there is no window to come to front; you need to uniconify it first and only then call the ScreenToFront(), WindowToFront() and ActivateWindow() sequence. The mistake of ~~referencing a non-existing window is as silly as it is easy to make!~~		Also remember that the notifications are addressed to an abstract ''application'' – this makes them rather different from IDCMP messages, which are always sent to a particular ''window'' (Intuition doesn't know what an application is). Whereas Intuition stops sending IDCMP messages as soon as the window becomes closed/iconified, the Application Library keeps passing messages as long as the application is registered, regardless of program window state. So be smart in your code when processing Application Library notifications: check for the availability of the program window and perform uniconification when necessary. For example, this following piece of code

			<syntaxhighlight>
			/* Don't do this!!! */
			case APPLIBMT_ToFront:
			IIntuition->ScreenToFront(win->WScreen);
			IIntuition->WindowToFront(win);
			IIntuition->ActivateWindow(win);
			break;
			</syntaxhighlight>

			is broken because if an APPLIBMT_ToFront command were sent to your iconified application, there would be no window to refer to. You need to check for iconified state first, uniconify the window if needed, and only then call the ScreenToFront(), WindowToFront() and ActivateWindow() sequence. The mistake of referencing a non-existing window is as silly as it is easy to make!

	=== Sending Messages ===		=== Sending Messages ===

Daniel Jedlicka: /* Minimum Application Library Support */

2017-05-31T14:37:30Z

Minimum Application Library Support

← Older revision		Revision as of 14:37, 31 May 2017
Line 46:		Line 46:
	=== Minimum Application Library Support ===		=== Minimum Application Library Support ===

	In the foreseeable future, AmigaOS will feature an application manager to control running applications. ~~The~~ ~~idea~~ is to ~~extend~~ or ~~possibly~~ ~~even~~ ~~replace~~ ~~Exchange~~ to ~~offer~~ a single, universal control point for both commodities and applications. In order to allow easy, consistent and predictable program control, developers are encouraged to [[#Registering the Application\|register their applications]] and implement the following suggested minimum Application Library support:		In the foreseeable future, AmigaOS will feature an application manager to control running applications. (A third-party solution called [http://wiki.amiga.org/index.php?title=Exchanger Exchanger] is already available.) The idea is to provide a single, universal control point for both commodities and applications. In order to allow easy, consistent and predictable program control, developers are encouraged to [[#Registering the Application\|register their applications]] and implement the following suggested minimum Application Library support:

	* Provide a short [[#Description\|description]] for a better identification of the application.		* Provide a short [[#Description\|description]] for a better identification of the application.
	* Tell the OS whether ~~the~~ application supports iconification, that is, hiding/showing its GUI ~~(for more information, see [[#Feature Set / Control Scope\|this section]])~~. If iconification is supported:		* Tell the OS whether your application supports iconification, that is, hiding/showing its GUI. If iconification is supported:
			** set the REGAPP_HasIconifyFeature registration tag to TRUE;
	** make the application respond to the [[#Control Messages\|APPLIBMT_Hide and APPLIBMT_Unhide]] control messages;		** make the application respond to the [[#Control Messages\|APPLIBMT_Hide and APPLIBMT_Unhide]] control messages;
	** update the APPATTR_Hidden attribute accordingly each time your application iconifies or uniconifies.		** update the APPATTR_Hidden attribute accordingly each time your application iconifies or uniconifies.
	* Allow the application to be shut down externally in a safe and graceful manner in reaction to the [[#Control Messages\|APPLIBMT_Quit]] message.		* Allow the application to be shut down externally in a safe and graceful manner in reaction to the [[#Control Messages\|APPLIBMT_Quit]] message.

	A failure to implement this suggested minimum will mean that the OS application manager will be unable to control your application properly and consistently. This may cause confusion on the part of the users and degrade their AmigaOS experience.		A failure to implement this suggested minimum will mean that the application manager will be unable to control your application properly and consistently. This may cause confusion on the part of the users and degrade their AmigaOS experience.

	== Library Opening Chores ==		== Library Opening Chores ==

Daniel Jedlicka: Moved the PrefsObjects section into a new page.

2015-09-18T12:37:26Z

Moved the PrefsObjects section into a new page.

Show changes

Daniel Jedlicka: Shortened code example lines that were too long.

2015-04-10T09:27:50Z

Shortened code example lines that were too long.

← Older revision		Revision as of 09:27, 10 April 2015
Line 69:		Line 69:
	if ( (ApplicationBase = IExec->OpenLibrary("application.library", 52)) )		if ( (ApplicationBase = IExec->OpenLibrary("application.library", 52)) )
	{		{
	IApplication = (struct ApplicationIFace *) IExec->GetInterface(ApplicationBase, ~~"application", 2, NULL);~~		IApplication = (struct ApplicationIFace *) IExec->GetInterface(ApplicationBase,
			"application", 2, NULL);
	IPrefsObjects = (struct PrefsObjectsIFace *) IExec->GetInterface(ApplicationBase, ~~"prefsobjects", 2, NULL);~~		IPrefsObjects = (struct PrefsObjectsIFace *) IExec->GetInterface(ApplicationBase,
			"prefsobjects", 2, NULL);
	}		}

Line 293:		Line 295:

	/* if you only know the application name */		/* if you only know the application name */
	appID = IApplication->FindApplication(FINDAPP_Name, "AudioMonster", ~~TAG_END);~~		appID = IApplication->FindApplication(FINDAPP_Name, "AudioMonster",
			TAG_END);

	/* if you know the application name identifier */		/* if you know the application name identifier */
	appID = IApplication->FindApplication(FINDAPP_AppIdentifier, "AudioMonster.supercoders.com", ~~TAG_END);~~		appID = IApplication->FindApplication(FINDAPP_AppIdentifier, "AudioMonster.supercoders.com",
			TAG_END);

	/* if you specifically want to talk to the second running instance */		/* if you specifically want to talk to the second running instance */
	appID = IApplication->FindApplication(FINDAPP_AppIdentifier, "AudioMonster_1.supercoders.com", ~~TAG_END);~~		appID = IApplication->FindApplication(FINDAPP_AppIdentifier, "AudioMonster_1.supercoders.com",
			TAG_END);

	/* if you know the pathname to the program file */		/* if you know the pathname to the program file */
	appID = IApplication->FindApplication(FINDAPP_FileName, "Work:Utils/AudioMonster", ~~TAG_END);~~		appID = IApplication->FindApplication(FINDAPP_FileName, "Work:Utils/AudioMonster",
			TAG_END);
	</syntaxhighlight>		</syntaxhighlight>

Line 722:		Line 728:

	<syntaxhighlight>		<syntaxhighlight>
	PrefsObjects * pDict = IPrefsObjects->PrefsDictionary(NULL, &nError, ALPO_Alloc, 0, ~~TAG_END);~~		PrefsObjects * pDict = IPrefsObjects->PrefsDictionary(NULL, &nError, ALPO_Alloc, 0,
			TAG_END);
	</syntaxhighlight>		</syntaxhighlight>

Line 728:		Line 735:

	<syntaxhighlight>		<syntaxhighlight>
	PrefsObjects * pStr = IPrefsObjects->PrefsString(NULL, &nError, ALPO_Alloc, 0, ~~TAG_END);~~		PrefsObjects * pStr = IPrefsObjects->PrefsString(NULL, &nError, ALPO_Alloc, 0,
			TAG_END);
	</syntaxhighlight>		</syntaxhighlight>

Lyle Hazelwood: /* Registering the Application */ Added warning about underscores in the program name.

2014-08-07T22:58:10Z

Registering the Application: Added warning about underscores in the program name.

← Older revision		Revision as of 22:58, 7 August 2014
Line 92:		Line 92:

	Application registration is a simple process during which a program informs AmigaOS that it should be treated as an application, and provides some basic information about itself: the program name, an associated URL address, or a short description. Also, certain application-related properties can be set at registration time (although some of these may be provided or changed later). Registration typically takes place at program startup; unregistration is normally done at the end of program runtime.		Application registration is a simple process during which a program informs AmigaOS that it should be treated as an application, and provides some basic information about itself: the program name, an associated URL address, or a short description. Also, certain application-related properties can be set at registration time (although some of these may be provided or changed later). Registration typically takes place at program startup; unregistration is normally done at the end of program runtime.

			hint Avoid using the _ underscore character in the registered name. These may cause "charsetconvert" errors when the system boots up later.

	== Application Identifiers ==		== Application Identifiers ==

Steven Solie: /* Pop-up Notifications (Ringhio Messages) */

2014-06-04T18:37:22Z

Pop-up Notifications (Ringhio Messages)

← Older revision		Revision as of 18:37, 4 June 2014
Line 547:		Line 547:
	= Pop-up Notifications (Ringhio Messages) =		= Pop-up Notifications (Ringhio Messages) =

	As from the introduction of the Ringhio server in AmigaOS 4.1 Update 1, registered applications can inform the user via notifications displayed in a small pop-up box. These are sometimes called ''Ringhio messages'' because the server provides means through which the messages are communicated visually (in other words, Ringhio handles the actual display of messages sent by the Application Library). [[File:RinghioNotification.png\|frame\|Ringhio notification example]] The pop-ups function similarly to [[Intuition Requesters ~~and Alerts~~\|requesters]] in that they show a text message; but unlike requesters, Ringhio messages do not require user interaction or acknowledgement. They just show up briefly and disappear – which makes them great for informing about less significant, matter-of-fact events such as that a certain task has been completed (this is especially helpful if the application is hidden or runs on a different screen, as the user is kept informed about something that is currently beyond his/her visual control).		As from the introduction of the Ringhio server in AmigaOS 4.1 Update 1, registered applications can inform the user via notifications displayed in a small pop-up box. These are sometimes called ''Ringhio messages'' because the server provides means through which the messages are communicated visually (in other words, Ringhio handles the actual display of messages sent by the Application Library). [[File:RinghioNotification.png\|frame\|Ringhio notification example]] The pop-ups function similarly to [[Intuition Requesters\|requesters]] in that they show a text message; but unlike requesters, Ringhio messages do not require user interaction or acknowledgement. They just show up briefly and disappear – which makes them great for informing about less significant, matter-of-fact events such as that a certain task has been completed (this is especially helpful if the application is hidden or runs on a different screen, as the user is kept informed about something that is currently beyond his/her visual control).

	Of all the types of Application Library messages, pop-up notifications are surely the easiest to program. They don’t require any setup or event handling; all it takes is a single function call:		Of all the types of Application Library messages, pop-up notifications are surely the easiest to program. They don’t require any setup or event handling; all it takes is a single function call:
Line 599:		Line 599:
	* Do not use pop-up messages to report errors. An error is usually a serious situation, and as such it cannot be dismissed by simply displaying an automatic message (which can easily get missed or overlooked).		* Do not use pop-up messages to report errors. An error is usually a serious situation, and as such it cannot be dismissed by simply displaying an automatic message (which can easily get missed or overlooked).
	* Use the pop-up message facility with moderation. Displaying the messages too frequently might hamper the workflow, and would most probably annoy the user.		* Use the pop-up message facility with moderation. Displaying the messages too frequently might hamper the workflow, and would most probably annoy the user.


	= PrefsObjects =		= PrefsObjects =

Steven Solie: /* Library Opening Chores */

2014-04-11T14:28:55Z

Library Opening Chores

← Older revision		Revision as of 14:28, 11 April 2014
Line 57:		Line 57:

	= Library Opening Chores =		= Library Opening Chores =

			{{Note\|title=Notice\|text=Starting with AmigaOS SDK 53.24, both Application Library interfaces (application and prefsobjects) must be at version 2. This is due to changes in the Application Library API which had broken standard tag support until version 2 interfaces were introduced.}}

	Just like other AmigaOS libraries, the Application Library must be opened before it is used. Further, at least one of its interfaces must be obtained, depending on the functionality you require. The Application Library has two interfaces, called “application” and “prefsobjects”. You always need to obtain the “application” interface because it provides access to most library functions including application registration. You’ll only need to open the “prefsobjects” interface if you intend to make use of the PrefsObjects preferences system.		Just like other AmigaOS libraries, the Application Library must be opened before it is used. Further, at least one of its interfaces must be obtained, depending on the functionality you require. The Application Library has two interfaces, called “application” and “prefsobjects”. You always need to obtain the “application” interface because it provides access to most library functions including application registration. You’ll only need to open the “prefsobjects” interface if you intend to make use of the PrefsObjects preferences system.

Steven Solie: /* Reference Counting */

2014-03-19T16:50:47Z

Reference Counting

← Older revision		Revision as of 16:50, 19 March 2014
Line 751:		Line 751:
	</syntaxhighlight>		</syntaxhighlight>

	The second one allows to ~~explicetly~~ increase the count by 1. This can be needed for several reasons the main one being transfer of ownership.		The second one allows to explicitly increase the count by 1. This can be needed for several reasons the main one being transfer of ownership.

	== Automation ==		== Automation ==