Multi-Line Edit Oddities

Hiya,

Today I helped a colleague (a very talented one at that) with a small issue around a PMTRCD and usage of multi-line edit for oversized fields.  Something he hadn't seen before.

He was confused as to why his data entry field was showing on the device design and not showing when executed.

Figure 1 shows a mock up of his device design looking pretty standard.

Figure 2 shows the same screen at run-time.  Note the cursor has positioned to the field acting strangely but the underline is not showing.

If you want to recreate this issue I created a file as follows (See Figure 3 and 4) :-

 

Additionally, in the device design we set the long field to multi-line Y and set it to 4 rows and 50 wide.

To resolve the issue was a case of applying a (clearly little known) trick of moving the multi-line field over by one byte.  (Figure 5) 

 

This then allows the run-time screen to paint properly. (Figure 6)

My assumption is that the screen attributes are being corrupted by the multi-line although comparing the source for the DDS didn't highlight anything untoward so I am guessing it is a 5250 issue.  (I also recommend aligning the rest of the fields on the screen.)

Any takers on providing the technical explanation? as a compare source doens't seem to highlight a clear and present danger. (Figure 7)

I've always nudged these over by an extra byte for years and years but I guess some tips and tricks get lost.

Thanks for reading.
Lee.

2e Development Standards - Screen Functions (Part I)

I guess the last couple of months have been a bit quite on the site. This was due to some holidays on my part and the visit of relative from overseas for 5 weeks. As you may know I live in New Zealand and the Christmas and New Year period is a time of relaxation and recouperation as well as a period of mass and I mean mass national holiday. Many businesses shut down for a compulsory two weeks.

I am now refreshed and ready to finish off those blog posts that I promised at the back end of last year.

Today I want to continue the 2e (Synon) development standards theme. I really want this site to be an extension to your technical libraries. So without further procrastination, I will get on with development standards, tips and gotcha's for 2E screen functions.

Today will shall concentrate on the single record function type PMTRCD. Future posts will cover the remaining single record function types as well as multiple record function types like DSPFIL etc.

If used as designed and thats a big 'IF', then this function should have fields on the screen that are prompts for the user to input some values which are then passed to another function for action. These would typically be a report or a processing program of some description.

But, like everything in 2e, the original design intention and actual use is only limited to the users creativeness. I have used these screen types for edit and display screens, prompts, information windows and even restricted subfiles. They are powerful for a number of reasons but for me the ability to DROP the relations and code a screen from a blank canvas is very satisfactory indeed.

General Pointers

A PMTRCD will typically be used in situations where an EDTRCD or DSPRCD is not applicable or too complex, or will have too much of a processing overhead or the traditional methods highlighted above.

For performance reasons any fields or file-to-file relations not needed should be DROPPED from the device design.

After USER:User Defined Action there is no check for any outstanding errors during the User Defined Action processing. If the function option Repeat=No then function may just exit and any errors will not be reported back to the user. Therefore it is a good idea to do a *Quit if PGM.*Return Code is not *Normal, or *Quit if *PGMERR.

Tip

If the function requires a complex set of fields or file to file relations which is not present on any existing file then consider creating an array with fields set to MAP for the PMTRCD. This is often easier and simpler than basing the function on an existing model file, then using lots of function fields and adding procedural based action diagram checking.

Gotcha's

If the function option Repeat=Yes is set then the PMTRCD just loops back to redisplay the detail screen. It does not execute USER:Load Screen. To make the function execute this user point again call user source 2E Force PMTRCD Reload






A PMTRCD behaves slightly different to an EDTRCD. During the validation cycle there is a *Quit if *PGMERR after USER:Validate Fields.

If the primary key relation check has not been turned off then an automatic prompt is generated to a SELRCD over the based upon file. But unlike other file to file relations there is no opportunity to choose which SELRCD is to be called. This I need to validate as I was unable to replicate at the time of writing.

Hope this helps?

Thanks for reading.
Lee.