PERFORM NEW-SCREEN

, , , ,
1

Does anybody work with some construct-models?

One of the “features” of our model is: The use of REINPUT is forbidden. You have to use the following syntax:


MOVE 9991 TO MSG-INFO.##MSG-NR     
MOVE 'Error-Text' TO MSG-INFO.##MSG-DATA(1)
PERFORM NEW-SCREEN

My question is: Why?

2

Hi Matthias,

Here is some information which may help to clarify:

The Reinput clause goes back to the last input that was seen. This became some what limiting because the last input could have been the 2nd input panel but the error that needs to be pointed out is on the first input panel; or the last input could have been a popup help window but again, this is not the screen where the error is that we want to highlight.

Historically, the reinput also did not allow values on the screen to be changed from the way they were the last time the user saw the screen (e.g. derived values wouldn’t be derived if a REINPUT was hit, but if an INPUT was re executed derived values could show up correctly); this limitation, however, has been gone for a while.

Regards,
Mark Barnard
R&D Construct/Spectrum
Software AG

3

I saw one time, that REINPUT in such a contruct module causes an error. But I don’t remember the Error number. The solution was to substitute the REINPUT for a PERFORM NEW-SCREEN.

From my point of view this is an ugly solution. I’m forced to address a field like the following:

MOVE 9991 TO MSG-INFO.##MSG-NR
MOVE 'Error-Text' TO MSG-INFO.##MSG-DATA(1)
MOVE 14 TO MSG-INFO.##ERROR-FIELD-INDEX3
PERFORM NEW-SCREEN

It would be better to address the wanted field with *FIELD-NAME. So it would be much easier to put a new field on the map. But using CONSTRUCT means to substitute all field-positions in that case.

4

Hi Matthias,

While this code seems a little cumbersome, it is done for maximum flexibility. I assume you are using the OBJECT-MAINT-DIALOG model but I’m not sure since you didn’t say.

The reasons to generate this flexible code are:

• If the error field is on a different panel (screens that can scroll left and right - PF11 and PF12) then we want to navigate to the correct panel to mark the correct field. See the REINPUT-SCREEN subroutine that is generated. A good example to look at is NCOMENT in the NCSTDEMO library.
• If you have scrolling regions on your input then you may want to adjust the visible occurrences to point out the correct error field.
• There may be initializations in the NEW-SCREEN repeat that you may want to do again when re-displaying the screen. You may also have derived fields that you need to deal with as well.

One of the issues with using *FIELDNAME in the REINPUT statement is that it can’t be a variable. So Construct would have to generate REINPUT statements for every single field. Because of the scrolling issue, Construct generates the POS statements instead.

Also, in the code that you mentioned, there are some extra statements because you are using message numbers instead of message text. This would be needed anyway to lookup the error message.

Finally, regardless of all this, using a REINPUT statement with *FIELDNAME still doesn’t help with the positioning of scrolling panels if the field is not on the current input screen.

Hope this helps,

Mark Barnard
R&D Construct/Spectrum
Software AG

5

Yes, we are using OBJECT-MAINT-DIALOG but there are more models with the same method of positioning.

Thanks for answering! I was not sure if there is way to address a field with *FIELD-NAME within a constuct-model. But if I understand you correctly the only way is to use the POSITION of the field.