Screen classes - Revision history

JAL: RKTools replaces UL/SPF

2015-10-23T20:51:18Z

RKTools replaces UL/SPF

← Older revision		Revision as of 20:51, 23 October 2015
Line 5:		Line 5:
	With <var>Screen</var> objects, screen definition takes place during <var class="product">User Language</var> request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing <var class="product">User Language</var> code or resorting to special $functions to manipulate a traditional screen layout.		With <var>Screen</var> objects, screen definition takes place during <var class="product">User Language</var> request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing <var class="product">User Language</var> code or resorting to special $functions to manipulate a traditional screen layout.

	[[Screen object sample code]] and [[Screen class using object-oriented syntax]] contain coding examples. If you are a <var class="product">[[~~ULSPF\|UL/SPF~~]]</var> customer, you can also find screen object coding examples in the SIRIUS file.		[[Screen object sample code]] and [[Screen class using object-oriented syntax]] contain coding examples. If you are a <var class="product">[[RKTools]]</var> customer, you can also find screen object coding examples in the <code>SIRIUS</code> file.

	==Screens and ScreenFields==		==Screens and ScreenFields==

JAL at 21:22, 30 June 2014

2014-06-30T21:22:16Z

← Older revision		Revision as of 21:22, 30 June 2014
Line 5:		Line 5:
	With <var>Screen</var> objects, screen definition takes place during <var class="product">User Language</var> request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing <var class="product">User Language</var> code or resorting to special $functions to manipulate a traditional screen layout.		With <var>Screen</var> objects, screen definition takes place during <var class="product">User Language</var> request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing <var class="product">User Language</var> code or resorting to special $functions to manipulate a traditional screen layout.

	[[Screen object sample code~~\|"Screen object sample code"~~]] and [[Screen class using object-oriented syntax~~\|"Screen class using object-oriented syntax"~~]] contain coding examples. If you are a <var class="product">[[ULSPF\|UL/SPF]]</var> customer, you can also find screen object coding examples in the SIRIUS file.		[[Screen object sample code]] and [[Screen class using object-oriented syntax]] contain coding examples. If you are a <var class="product">[[ULSPF\|UL/SPF]]</var> customer, you can also find screen object coding examples in the SIRIUS file.

	==Screens and ScreenFields==		==Screens and ScreenFields==
	The <var>Screen</var> class provides an object-oriented equivalent of the <var class="product">Model 204</var> full-screen feature. An instance of a <var>Screen</var> object is equivalent to a screen you might define with the ~~<var class="product">User Language</var>~~ full-screen feature. The <var>Screen</var> methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.		The <var>Screen</var> class provides an object-oriented (OO) equivalent of the <var class="product">Model 204</var> full-screen feature. An instance of a <var>Screen</var> object is equivalent to a screen you might define with the [[SOUL]] OO full-screen feature. The <var>Screen</var> methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.

	<var>Screen</var> objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the <var>Screenfield</var> class. In this document, <var>ScreenField</var> objects are sometimes referred to as “fields” and sometimes as “screenfields.”		<var>Screen</var> objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the <var>Screenfield</var> class. In this document, <var>ScreenField</var> objects are sometimes referred to as “fields” and sometimes as “screenfields.”

	==System space for Screen objects==		==System space for Screen objects==
	Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. ~~Since~~ screen objects ~~are part of <var class="product">Janus SOAP</var>, the design~~ must fit within ~~this existing~~ object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.		Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. But screen objects must fit within the object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.

	Because the entire screen image must be in contiguous storage, any instance of a screen object must allocate the maximum allowable STBL space, even if some of this space may not be used by a particular application. You use the <var>[[SCRNSTBL parameter\|SCRNSTBL]]</var> user parameter, which specifies the maximum size per screen, to prevent unnecessary waste of STBL space and to limit an application to a reasonable amount of space to prevent STBL exhaustion.		Because the entire screen image must be in contiguous storage, any instance of a screen object must allocate the maximum allowable STBL space, even if some of this space may not be used by a particular application. You use the <var>[[SCRNSTBL parameter\|SCRNSTBL]]</var> user parameter, which specifies the maximum size per screen, to prevent unnecessary waste of STBL space and to limit an application to a reasonable amount of space to prevent STBL exhaustion.

	A good starting value for <var>SCRNSTBL</var> is 6144 ~~(this is the default as of <var class="product">Sirius Mods</var> 7.3 and maintenance to earlier versions)~~. Scrolling applications and applications designed for large screens with many fields may require two or more times this storage. An application that exceeds its screen STBL allocation is canceled.		A good starting value for <var>SCRNSTBL</var> is 6144. Scrolling applications and applications designed for large screens with many fields may require two or more times this storage. An application that exceeds its screen STBL allocation is canceled.

	==Useful enumerations==		==Useful enumerations==
Line 30:		Line 30:
	<var>ActionKey</var> is used by the <var>[[ActionKey (Screen function)\|ActionKey]]</var> and <var>[[Read (Screen function)\|Read]]</var> methods to specify the keyboard key that activated the last screen read. Valid values are <var>Enter</var> and <var>Pf1</var>, <var>Pf2</var>, and so on through <var>Pf24</var>. The value that is set initially is <var>Enter</var>.		<var>ActionKey</var> is used by the <var>[[ActionKey (Screen function)\|ActionKey]]</var> and <var>[[Read (Screen function)\|Read]]</var> methods to specify the keyboard key that activated the last screen read. Valid values are <var>Enter</var> and <var>Pf1</var>, <var>Pf2</var>, and so on through <var>Pf24</var>. The value that is set initially is <var>Enter</var>.

	As with all enumerations, the <var>ToString</var> method implicitly converts an <var>ActionKey</var> value to a character string whose value is the name of the enumeration value. Other methods available to all enumerations are described in [[Enumerations#Common enumeration methods\|"Common enumeration methods"]]. Besides these common methods, the		As with all enumerations, the <var>ToString</var> method implicitly converts an <var>ActionKey</var> value to a character string whose value is the name of the enumeration value. Other methods available to all enumerations are described in [[Enumerations#Common enumeration methods\|Common enumeration methods]]. Besides these common methods, the
	<var>ActionKey</var> enumeration has an additional method available (<var>ToNumber</var>), as		<var>ActionKey</var> enumeration has an additional method available (<var>ToNumber</var>), as
	described in the following section.		described in the following section.
Line 36:		Line 36:
	====ToNumber function====		====ToNumber function====
	This function converts <var>ActionKey</var> enumeration values to a numeric value: the integer that remains after the key name is stripped of its "PF" prefix. For <var>Enter</var>, the numeric value is 0. These values are useful in a value-testing loop in conjunction with the <var class="product">User Language</var> <var>Jump</var> statement.		This function converts <var>ActionKey</var> enumeration values to a numeric value: the integer that remains after the key name is stripped of its "PF" prefix. For <var>Enter</var>, the numeric value is 0. These values are useful in a value-testing loop in conjunction with the <var class="product">User Language</var> <var>Jump</var> statement.

	====ToNumber syntax====		====ToNumber syntax====
	<p class="syntax"> <span class="term">%num</span> <span class="literal">= </span><span class="term">key</span><span class="literal">:ToNumber</span>		<p class="syntax"> <span class="term">%num</span> <span class="literal">= </span><span class="term">key</span><span class="literal">:ToNumber</span>
Line 52:		Line 53:
	<var>FieldColor</var> is used by the and <var>[[AddField (Screen function)\|AddField]]</var>, <var>[[Color (ScreenField property)\|Color]]</var>, <var>[[ProtectedColor (Screen property)\|ProtectedColor]]</var>, and <var>[[UnprotectedColor (Screen property)\|UnprotectedColor]]</var> methods. The valid values (case unimportant) of this enumeration are <var>turquoise</var>, <var>green</var>, <var>blue</var>, <var>red</var>, <var>white</var>, <var>yellow</var> and <var>pink</var>. The default is <var>blue</var>.		<var>FieldColor</var> is used by the and <var>[[AddField (Screen function)\|AddField]]</var>, <var>[[Color (ScreenField property)\|Color]]</var>, <var>[[ProtectedColor (Screen property)\|ProtectedColor]]</var>, and <var>[[UnprotectedColor (Screen property)\|UnprotectedColor]]</var> methods. The valid values (case unimportant) of this enumeration are <var>turquoise</var>, <var>green</var>, <var>blue</var>, <var>red</var>, <var>white</var>, <var>yellow</var> and <var>pink</var>. The default is <var>blue</var>.

	'''Note:''' As with all enumerations, the <var>ToString</var> method implicitly converts a <var>FieldColor</var> value to a character string whose value is the name of the enumeration value. For more information about methods available to all enumerations, see [[Enumerations#Common enumeration methods\|"Common enumeration methods"]].		<p class="note">'''Note:''' As with all enumerations, the <var>ToString</var> method implicitly converts a <var>FieldColor</var> value to a character string whose value is the name of the enumeration value. For more information about methods available to all enumerations, see [[Enumerations#Common enumeration methods\|Common enumeration methods]]. </p>

	===Highlight enumeration===		===Highlight enumeration===
Line 58:		Line 59:

	==Lists of Screen and ScreenField methods==		==Lists of Screen and ScreenField methods==
	The [[List of Screen methods~~\|"List of Screen methods"~~]] and the [[List of ScreenField methods~~\|"List of ScreenField methods"~~]] contain complete lists of the methods in these classes, and they are combined in [[List of Screen API methods~~\|"List of Screen API methods"~~]].		The [[List of Screen methods]] and the [[List of ScreenField methods]] contain complete lists of the methods in these classes, and they are combined in [[List of Screen API methods]].

	==See also==		==See also==
	<ul>		<ul>
	<li>[[Screen object sample code~~\|"Screen object sample code"~~]] and [[Screen class using object-oriented syntax~~\|"Screen class using object-oriented syntax"~~]]		<li>[[Screen object sample code]] and [[Screen class using object-oriented syntax]]
	<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>
	</ul>		</ul>

	[[Category:System classes]]		[[Category:System classes]]

JAL at 20:46, 20 November 2012

2012-11-20T20:46:26Z

← Older revision		Revision as of 20:46, 20 November 2012
Line 8:		Line 8:

	==Screens and ScreenFields==		==Screens and ScreenFields==
	The <var>Screen</var> class provides an object-oriented equivalent of the <var class="product">Model 204</var> full-screen feature. An instance of a Screen object is equivalent to a screen you might define with the <var class="product">User Language</var> full-screen feature. The Screen methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.		The <var>Screen</var> class provides an object-oriented equivalent of the <var class="product">Model 204</var> full-screen feature. An instance of a <var>Screen</var> object is equivalent to a screen you might define with the <var class="product">User Language</var> full-screen feature. The <var>Screen</var> methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.

	Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”		<var>Screen</var> objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the <var>Screenfield</var> class. In this document, <var>ScreenField</var> objects are sometimes referred to as “fields” and sometimes as “screenfields.”

	==System space for Screen objects==		==System space for Screen objects==
	Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.		Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of <var class="product">Janus SOAP</var>, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.

	Because the entire screen image must be in contiguous storage, any instance of a screen object must allocate the maximum allowable STBL space, even if some of this space may not be used by a particular application. You use the SCRNSTBL user parameter, which specifies the maximum size per screen, to prevent unnecessary waste of STBL space and to limit an application to a reasonable amount of space to prevent STBL exhaustion.		Because the entire screen image must be in contiguous storage, any instance of a screen object must allocate the maximum allowable STBL space, even if some of this space may not be used by a particular application. You use the <var>[[SCRNSTBL parameter\|SCRNSTBL]]</var> user parameter, which specifies the maximum size per screen, to prevent unnecessary waste of STBL space and to limit an application to a reasonable amount of space to prevent STBL exhaustion.

	A good starting value for SCRNSTBL is 6144 (this is the default as of Sirius Mods 7.3 and maintenance to earlier versions). Scrolling applications and applications designed for large screens with many fields may require two or more times this storage. An application that exceeds its screen STBL allocation is canceled.		A good starting value for <var>SCRNSTBL</var> is 6144 (this is the default as of <var class="product">Sirius Mods</var> 7.3 and maintenance to earlier versions). Scrolling applications and applications designed for large screens with many fields may require two or more times this storage. An application that exceeds its screen STBL allocation is canceled.

	==Useful enumerations==		==Useful enumerations==

JAL at 20:38, 20 November 2012

2012-11-20T20:38:35Z

← Older revision		Revision as of 20:38, 20 November 2012
Line 8:		Line 8:

	==Screens and ScreenFields==		==Screens and ScreenFields==
			The <var>Screen</var> class provides an object-oriented equivalent of the <var class="product">Model 204</var> full-screen feature. An instance of a Screen object is equivalent to a screen you might define with the <var class="product">User Language</var> full-screen feature. The Screen methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.
	The Screen class provides an object-oriented equivalent of the Model 204 full-screen feature. An instance of a Screen object is equivalent to a screen you might define with the <var class="product">User Language</var> full-screen feature. The Screen methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.

	Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”		Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”

JAL: /* System space for Screen objects */

2012-11-20T20:35:53Z

System space for Screen objects

← Older revision		Revision as of 20:35, 20 November 2012
Line 13:		Line 13:
	Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”		Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”

	==System space for ~~<var>~~Screen~~</var>~~ objects==		==System space for Screen objects==

	Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.		Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.

JALWiccan: 1 revision

2012-11-20T20:35:05Z

1 revision

← Older revision	Revision as of 20:35, 20 November 2012
(No difference)

JALWiccan: 1 revision

2012-11-20T20:35:04Z

1 revision

← Older revision		Revision as of 20:35, 20 November 2012
Line 3:		Line 3:
	Most modern 3270 emulators allow flexible definitions of 3270 screen sizes beyond the standard Models 2, 3, 4, and 5. Traditional <var class="product">User Language</var> screen definitions define a fixed layout for a screen and so must be designed to be display correctly on even the smallest screen. This is usually the 3278 Model 2, which contains a none-too-generous 24 rows by 80 columns. Though a screen designed for a 24x80 layout will usually display correctly on other models, screens designed for other models may display misaligned data on a smaller screen, often rendering the application unusable on these screen types. This leaves the application programmer little choice but to design for the lowest common denominator — Model 2 — wasting precious screen space on larger screens.		Most modern 3270 emulators allow flexible definitions of 3270 screen sizes beyond the standard Models 2, 3, 4, and 5. Traditional <var class="product">User Language</var> screen definitions define a fixed layout for a screen and so must be designed to be display correctly on even the smallest screen. This is usually the 3278 Model 2, which contains a none-too-generous 24 rows by 80 columns. Though a screen designed for a 24x80 layout will usually display correctly on other models, screens designed for other models may display misaligned data on a smaller screen, often rendering the application unusable on these screen types. This leaves the application programmer little choice but to design for the lowest common denominator — Model 2 — wasting precious screen space on larger screens.

	With Screen objects, screen definition takes place during <var class="product">User Language</var> request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing <var class="product">User Language</var> code or resorting to special $functions to manipulate a traditional screen layout.		With <var>Screen</var> objects, screen definition takes place during <var class="product">User Language</var> request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing <var class="product">User Language</var> code or resorting to special $functions to manipulate a traditional screen layout.

	[[Screen object sample code\|"Screen object sample code"]] and [[Screen class using object-oriented syntax\|"Screen class using object-oriented syntax"]] contain coding examples. If you are a <var class="product">[[ULSPF\|UL/SPF]]</var> customer, you can also find screen object coding examples in the SIRIUS file.		[[Screen object sample code\|"Screen object sample code"]] and [[Screen class using object-oriented syntax\|"Screen class using object-oriented syntax"]] contain coding examples. If you are a <var class="product">[[ULSPF\|UL/SPF]]</var> customer, you can also find screen object coding examples in the SIRIUS file.
Line 13:		Line 13:
	Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”		Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”

	==System space for Screen objects==		==System space for <var>Screen</var> objects==

	Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.		Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.

JALWiccan: 1 revision

2012-11-20T20:32:58Z

1 revision

← Older revision	Revision as of 20:32, 20 November 2012
(No difference)

JAL at 20:32, 20 November 2012

2012-11-20T20:32:57Z

← Older revision		Revision as of 20:32, 20 November 2012
Line 1:		Line 1:
	[[File:ScreenObject.png\|thumb\|300px\|Screen object code can dynamically resize the application to use whatever space is available in the user's chosen 3270 configuration.]] Introduced in version 7.1 of the <var class="product">[[Sirius Mods]]</var>, '''Screen objects''' are designed to make writing and maintaining User Language full-screen applications easier. They also let you take advantage of dynamic 3270 screen sizes in your applications.		[[File:ScreenObject.png\|thumb\|300px\|Screen object code can dynamically resize the application to use whatever space is available in the user's chosen 3270 configuration.]] Introduced in version 7.1 of the <var class="product">[[Sirius Mods]]</var>, '''Screen objects''' are designed to make writing and maintaining <var class="product">User Language</var> full-screen applications easier. They also let you take advantage of dynamic 3270 screen sizes in your applications.

	Most modern 3270 emulators allow flexible definitions of 3270 screen sizes beyond the standard Models 2, 3, 4, and 5. Traditional User Language screen definitions define a fixed layout for a screen and so must be designed to be display correctly on even the smallest screen. This is usually the 3278 Model 2, which contains a none-too-generous 24 rows by 80 columns. Though a screen designed for a 24x80 layout will usually display correctly on other models, screens designed for other models may display misaligned data on a smaller screen, often rendering the application unusable on these screen types. This leaves the application programmer little choice but to design for the lowest common denominator — Model 2 — wasting precious screen space on larger screens.		Most modern 3270 emulators allow flexible definitions of 3270 screen sizes beyond the standard Models 2, 3, 4, and 5. Traditional <var class="product">User Language</var> screen definitions define a fixed layout for a screen and so must be designed to be display correctly on even the smallest screen. This is usually the 3278 Model 2, which contains a none-too-generous 24 rows by 80 columns. Though a screen designed for a 24x80 layout will usually display correctly on other models, screens designed for other models may display misaligned data on a smaller screen, often rendering the application unusable on these screen types. This leaves the application programmer little choice but to design for the lowest common denominator — Model 2 — wasting precious screen space on larger screens.

	With Screen objects, screen definition takes place during User Language request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing User Language code or resorting to special $functions to manipulate a traditional screen layout.		With Screen objects, screen definition takes place during <var class="product">User Language</var> request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing <var class="product">User Language</var> code or resorting to special $functions to manipulate a traditional screen layout.

	[[Screen object sample code\|"Screen object sample code"]] and [[Screen class using object-oriented syntax\|"Screen class using object-oriented syntax"]] contain coding examples. If you are a <var class="product">[[ULSPF\|UL/SPF]]</var> customer, you can also find screen object coding examples in the SIRIUS file.		[[Screen object sample code\|"Screen object sample code"]] and [[Screen class using object-oriented syntax\|"Screen class using object-oriented syntax"]] contain coding examples. If you are a <var class="product">[[ULSPF\|UL/SPF]]</var> customer, you can also find screen object coding examples in the SIRIUS file.
Line 9:		Line 9:
	==Screens and ScreenFields==		==Screens and ScreenFields==

	The Screen class provides an object-oriented equivalent of the Model 204 full-screen feature. An instance of a Screen object is equivalent to a screen you might define with the User Language full-screen feature. The Screen methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.		The Screen class provides an object-oriented equivalent of the Model 204 full-screen feature. An instance of a Screen object is equivalent to a screen you might define with the <var class="product">User Language</var> full-screen feature. The Screen methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.

	Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”		Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”
Line 15:		Line 15:
	==System space for Screen objects==		==System space for Screen objects==

	Traditional User Language full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.		Traditional <var class="product">User Language</var> full-screen applications use FSCB (Full Screen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.

	Because the entire screen image must be in contiguous storage, any instance of a screen object must allocate the maximum allowable STBL space, even if some of this space may not be used by a particular application. You use the SCRNSTBL user parameter, which specifies the maximum size per screen, to prevent unnecessary waste of STBL space and to limit an application to a reasonable amount of space to prevent STBL exhaustion.		Because the entire screen image must be in contiguous storage, any instance of a screen object must allocate the maximum allowable STBL space, even if some of this space may not be used by a particular application. You use the SCRNSTBL user parameter, which specifies the maximum size per screen, to prevent unnecessary waste of STBL space and to limit an application to a reasonable amount of space to prevent STBL exhaustion.

JAL at 20:32, 20 November 2012

2012-11-20T20:32:18Z

← Older revision		Revision as of 20:32, 20 November 2012
Line 1:		Line 1:
	[[File:ScreenObject.png\|thumb\|300px\|Screen object code can dynamically resize the application to use whatever space is available in the user's chosen 3270 configuration.]]Introduced in version 7.1 of the <var class="product">[[Sirius Mods]]</var>, '''Screen objects''' are designed to make writing and maintaining User Language full-screen applications easier. They also let you take advantage of dynamic 3270 screen sizes in your applications.		[[File:ScreenObject.png\|thumb\|300px\|Screen object code can dynamically resize the application to use whatever space is available in the user's chosen 3270 configuration.]] Introduced in version 7.1 of the <var class="product">[[Sirius Mods]]</var>, '''Screen objects''' are designed to make writing and maintaining User Language full-screen applications easier. They also let you take advantage of dynamic 3270 screen sizes in your applications.

	Most modern 3270 emulators allow flexible definitions of 3270 screen sizes beyond the standard Models 2, 3, 4, and 5. Traditional User Language screen definitions define a fixed layout for a screen and so must be designed to be display correctly on even the smallest screen. This is usually the 3278 Model 2, which contains a none-too-generous 24 rows by 80 columns. Though a screen designed for a 24x80 layout will usually display correctly on other models, screens designed for other models may display misaligned data on a smaller screen, often rendering the application unusable on these screen types. This leaves the application programmer little choice but to design for the lowest common denominator — Model 2 — wasting precious screen space on larger screens.		Most modern 3270 emulators allow flexible definitions of 3270 screen sizes beyond the standard Models 2, 3, 4, and 5. Traditional User Language screen definitions define a fixed layout for a screen and so must be designed to be display correctly on even the smallest screen. This is usually the 3278 Model 2, which contains a none-too-generous 24 rows by 80 columns. Though a screen designed for a 24x80 layout will usually display correctly on other models, screens designed for other models may display misaligned data on a smaller screen, often rendering the application unusable on these screen types. This leaves the application programmer little choice but to design for the lowest common denominator — Model 2 — wasting precious screen space on larger screens.