Screen class using object-oriented syntax - Revision history

JAL: RKTools replaces UL/SPF

2015-10-23T22:17:19Z

RKTools replaces UL/SPF

← Older revision		Revision as of 22:17, 23 October 2015
Line 5:		Line 5:
	This is an example of how the <var class="product">SOUL</var> base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.		This is an example of how the <var class="product">SOUL</var> base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.

	Note the use of the <var>[[!DUPEXIT]]</var> directive at the top of this procedure. <var>!DUPEXIT</var> tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <code>SirScreen</code> class included in an optional module, but also need it in a routine that may or may not include the optional module. <var>!DUPEXIT</var> allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the <var class="product">~~UL/SPF~~</var> code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.		Note the use of the <var>[[!DUPEXIT]]</var> directive at the top of this procedure. <var>!DUPEXIT</var> tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <code>SirScreen</code> class included in an optional module, but also need it in a routine that may or may not include the optional module. <var>!DUPEXIT</var> allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the <var class="product">RKTools</var> code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.

JAL: RKTools replaces UL/SPF

2015-10-23T21:01:17Z

RKTools replaces UL/SPF

← Older revision		Revision as of 21:01, 23 October 2015
Line 1:		Line 1:
	The following example shows how the [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.		The following example shows how the [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.

	In this example (which is used in the <var class="product">[[~~UL/SPF~~]]</var> family of products), the locally defined <code>SirScreen</code> class ''extends'' the system <var>Screen</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the <var>Screen</var> class provides generic support for screen and screenfield generation, the <code>SirScreen</code> class that extends it exerts full control over the title, command-line, PF key definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.		In this example (which is used in the <var class="product">[[RKTools]]</var> family of products), the locally defined <code>SirScreen</code> class ''extends'' the system <var>Screen</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the <var>Screen</var> class provides generic support for screen and screenfield generation, the <code>SirScreen</code> class that extends it exerts full control over the title, command-line, PF key definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.

	This is an example of how the <var class="product">SOUL</var> base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.		This is an example of how the <var class="product">SOUL</var> base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.

JAL at 16:09, 17 October 2013

2013-10-17T16:09:34Z

← Older revision		Revision as of 16:09, 17 October 2013
Line 1:		Line 1:
	The following example shows how the ~~Sirius~~ [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.		The following example shows how the [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.

	In this example (which is used in the <var class="product">[[UL/SPF]]</var> family of products) the locally defined SirScreen class ''extends'' the ~~Sirius-provided~~ <var>Screen</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the <var>Screen</var> class provides generic support for screen and screenfield generation, the <~~var~~>SirScreen</~~var~~> class that extends it exerts full control over the title, command-line, PF key definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.		In this example (which is used in the <var class="product">[[UL/SPF]]</var> family of products), the locally defined <code>SirScreen</code> class ''extends'' the system <var>Screen</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the <var>Screen</var> class provides generic support for screen and screenfield generation, the <code>SirScreen</code> class that extends it exerts full control over the title, command-line, PF key definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.

	This is an example of how the ~~Sirius~~ base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.		This is an example of how the <var class="product">SOUL</var> base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.

	Note the use of the <var>[[!DUPEXIT]]</var> directive at the top of this procedure. <var>!DUPEXIT</var> tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <~~var~~>SirScreen</~~var~~> class included in an optional module, but also need it in a routine that may or may not include the optional module. <var>!DUPEXIT</var> allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the ~~Sirius~~ code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.		Note the use of the <var>[[!DUPEXIT]]</var> directive at the top of this procedure. <var>!DUPEXIT</var> tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <code>SirScreen</code> class included in an optional module, but also need it in a routine that may or may not include the optional module. <var>!DUPEXIT</var> allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the <var class="product">UL/SPF</var> code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.


Line 313:		Line 313:
	==See also==		==See also==
	<ul>		<ul>
	<li>The [[~~Janus SOAP User Language Interface~~]]		<li>The [[Object oriented programming in SOUL]]

	<li>[[Screen object sample code]]		<li>[[Screen object sample code]]
Line 319:		Line 319:
	<li>How to use [[Terminal MODEL 6 support\|Model 6]], or dynamically sized screens, in <var class="product">Model 204</var>		<li>How to use [[Terminal MODEL 6 support\|Model 6]], or dynamically sized screens, in <var class="product">Model 204</var>

	<li>[[Notation conventions for methods\|Notation conventions]] used in <var class="product">~~Janus SOAP~~</var> documentation		<li>[[Notation conventions for methods\|Notation conventions]] used in <var class="product">SOUL</var> class method documentation
	</ul>		</ul>

JAL: /* See also */

2012-11-19T20:20:47Z

JAL at 18:46, 19 November 2012

2012-11-19T18:46:28Z

← Older revision		Revision as of 18:46, 19 November 2012
Line 5:		Line 5:
	This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.		This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.

	Note the use of the ~~'''~~!DUPEXIT~~'''~~ directive at the top of this procedure. <var>!DUPEXIT</var> tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <var>SirScreen</var> class included in an optional module, but also need it in a routine that may or may not include the optional module. <var>!DUPEXIT</var> allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the Sirius code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.		Note the use of the <var>[[!DUPEXIT]]</var> directive at the top of this procedure. <var>!DUPEXIT</var> tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <var>SirScreen</var> class included in an optional module, but also need it in a routine that may or may not include the optional module. <var>!DUPEXIT</var> allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the Sirius code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.

JAL at 17:26, 19 November 2012

2012-11-19T17:26:15Z

← Older revision		Revision as of 17:26, 19 November 2012
Line 1:		Line 1:
	The following example shows how the Sirius [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.		The following example shows how the Sirius [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.

	In this example (which is used in the <var class="product">[[UL/SPF]]</var> family of products) the locally defined SirScreen class ''extends'' the Sirius-provided <var>[[Screen ~~classes\|Screen]]~~</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the <var>Screen</var> class provides generic support for screen and screenfield generation, the <var>SirScreen</var> class that extends it exerts full control over the title, command-line, ~~pfKey~~ definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.		In this example (which is used in the <var class="product">[[UL/SPF]]</var> family of products) the locally defined SirScreen class ''extends'' the Sirius-provided <var>Screen</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the <var>Screen</var> class provides generic support for screen and screenfield generation, the <var>SirScreen</var> class that extends it exerts full control over the title, command-line, PF key definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.

	This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.		This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.

	Note the use of the '''!DUPEXIT''' directive at the top of this procedure. !DUPEXIT tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <var>SirScreen</var> class included in an optional module, but also need it in a routine that may or may not include the optional module. !DUPEXIT allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the Sirius code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.		Note the use of the '''!DUPEXIT''' directive at the top of this procedure. <var>!DUPEXIT</var> tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <var>SirScreen</var> class included in an optional module, but also need it in a routine that may or may not include the optional module. <var>!DUPEXIT</var> allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the Sirius code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.

JAL at 17:16, 19 November 2012

2012-11-19T17:16:38Z

← Older revision		Revision as of 17:16, 19 November 2012
Line 1:		Line 1:
	The following example shows how the Sirius [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.		The following example shows how the Sirius [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.

	In this example (which is used in the [[~~ULSPF~~]] family of products) the locally defined SirScreen class ''extends'' the Sirius-provided <var>[[Screen classes\|Screen]]</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the Screen class provides generic support for screen and screenfield generation, the SirScreen class that extends it exerts full control over the title, command-line, pfKey definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.		In this example (which is used in the <var class="product">[[UL/SPF]]</var> family of products) the locally defined SirScreen class ''extends'' the Sirius-provided <var>[[Screen classes\|Screen]]</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the <var>Screen</var> class provides generic support for screen and screenfield generation, the <var>SirScreen</var> class that extends it exerts full control over the title, command-line, pfKey definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.

	This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.		This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.

	Note the use of the '''!DUPEXIT''' directive at the top of this procedure. !DUPEXIT tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the SirScreen class included in an optional module, but also need it in a routine that may or may not include the optional module. !DUPEXIT allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the Sirius code, for instance, the SirScreen procedure is used in the common "help" routines, which are included in most 3270 code. By using the !DUPEXIT directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.		Note the use of the '''!DUPEXIT''' directive at the top of this procedure. !DUPEXIT tells the compiler that, no matter how many times this routine is included, it should only be compiled into the executable once. This is useful if you need the <var>SirScreen</var> class included in an optional module, but also need it in a routine that may or may not include the optional module. !DUPEXIT allows the inclusion of the routine anywhere it is needed, without the danger that the compiler will fail when it sees it more than once in a single routine. In the Sirius code, for instance, the <var>SirScreen</var> procedure is used in the common "help" routines, which are included in most 3270 code. By using the <var>!DUPEXIT</var> directive, the calling program can include the same routine for other screens without worrying about whether or not the help routine is included as well.


Line 311:		Line 311:
	End Class		End Class

	==~~References~~==		==See also==
	<ul>		<ul>
	<li>The Janus SOAP ~~manual in PDF format: http://sirius-software.com/maint/download/jansoapr.pdf~~		<li>The [[Janus SOAP User Language Interface]]

	~~<li>The [[Screen classes~~]] ~~page~~

	<li>[[Screen object sample code]]		<li>[[Screen object sample code]]

JAL2: moved Screen class using OO Syntax to Screen class using object-oriented syntax

2011-06-27T22:46:45Z

moved Screen class using OO Syntax to Screen class using object-oriented syntax

← Older revision	Revision as of 22:46, 27 June 2011
(No difference)

JAL2: /* References */

2011-06-27T22:40:06Z

References

← Older revision		Revision as of 22:40, 27 June 2011
Line 323:		Line 323:
	<li>[[Notation conventions for methods\|Notation conventions]] used in <var class="product">Janus SOAP</var> documentation		<li>[[Notation conventions for methods\|Notation conventions]] used in <var class="product">Janus SOAP</var> documentation
	</ul>		</ul>

	~~[[Category:Screen methods]]~~
	~~[[Category:Screenfield methods]]~~

JAL2 at 22:34, 27 June 2011

2011-06-27T22:34:25Z

← Older revision		Revision as of 22:34, 27 June 2011
Line 1:		Line 1:
	The following example shows how the Sirius [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.		The following example shows how the Sirius [[Screen classes]] can be used to create your own locally-defined screen class using object-oriented syntax.

	In this example (which is used in the [[ULSPF]] family of products) the locally defined SirScreen class ''extends'' the Sirius-provided Screen class -- meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the Screen class provides generic support for screen and screenfield generation, the SirScreen class that extends it exerts full control over the title, command-line, pfKey definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.		In this example (which is used in the [[ULSPF]] family of products) the locally defined SirScreen class ''extends'' the Sirius-provided <var>[[Screen classes\|Screen]]</var> class — meaning that all the features of the base class are available for use, but more features can be (and are) being added. Where the Screen class provides generic support for screen and screenfield generation, the SirScreen class that extends it exerts full control over the title, command-line, pfKey definitions, message-handling and error highlighting, as well as controlling whether a scale is turned on or off, and how an optional header is formatted.

	This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.		This is an example of how the Sirius base classes are extended to provide centralized control on the look-and-feel of an application, while leaving the body of the page open for the application programmer to add business-function specific code.

← Older revision		Revision as of 20:20, 19 November 2012
Line 317:		Line 317:
	<li>[[Screen object sample code]]		<li>[[Screen object sample code]]

	<li>How to use [[~~Mod6 Screen~~\|Model 6]], or ~~[[Mod6 Screens\|Dynamically Sized~~ screens]] in <var class="product">Model 204</var>		<li>How to use [[Terminal MODEL 6 support\|Model 6]], or dynamically sized screens, in <var class="product">Model 204</var>

	<li>[[Notation conventions for methods\|Notation conventions]] used in <var class="product">Janus SOAP</var> documentation		<li>[[Notation conventions for methods\|Notation conventions]] used in <var class="product">Janus SOAP</var> documentation
	</ul>		</ul>