Template changes 9 to 11 - Process Template and new local var LRecordStatus?

1

I’m quasi-killing time migrating from 9.1 to 11.1. I’ve made my handful of template/inc modifications and mostly comparing generated code to see if I’ve missed something.

In the process, I’ve seen some changes in the base templates. Most seem to be changing the order of the generated code a bit. A few corrections. Regression with the description comment for a dropdown queue is now missing. Nothing concerning so far.

But then I see a change that makes no sense and wonder why. :slight_smile: Here’s the generated validate record code for an ABC process template:

ThisProcess.ValidateRecord PROCEDURE
ReturnValue          BYTE,AUTO
lRecordStatus        BYTE,AUTO
  CODE
  ReturnValue = PARENT.ValidateRecord()
       CASE CLIP(vw_13:SSN)
          OF '' OROF '0' OROF '111111111' OROF '555555555'
           RETURN Record:Filtered
       END
  lRecordStatus = ReturnValue
  RETURN ReturnValue

Here’s a plain one with the embeditor junk:

ThisProcess.ValidateRecord PROCEDURE
ReturnValue          BYTE,AUTO
! Start of "Process Method Data Section"
! [Priority 3500]
lRecordStatus        BYTE,AUTO
! [Priority 8500]
! End of "Process Method Data Section"
CODE
! Start of “Process Method Executable Code Section”
! [Priority 2500]

! Parent Call
ReturnValue = PARENT.ValidateRecord()
! [Priority 5050]

lRecordStatus = ReturnValue
IF lRecordStatus NOT=Record:OK THEN RETURN lRecordStatus.
! [Priority 6600]

ReturnValue = lRecordStatus
! [Priority 9000]

! End of “Process Method Executable Code Section”
RETURN ReturnValue

The lRecordStatus local variable was added after 9.1 and serves no useful purpose from what I can tell.

I don’t see any comments in the templates. I’d like to go back to the cleaner code but would prefer to not break some weird edge case that needs two local vars. :slight_smile:

Any ideas on what is going on here?

3

I guess I see why they might do it to keep the original ReturnValue unmolested, but I’ve never run into a situation over all the years that needed it. And if it did, I’d just manually save it. IDK.

4

One of the fun things about writing template code is that you are putting together code which has to be flexible enough to handle multiple use cases.

For example, any developer can write any code (fair enough) and equally any other template can inject any code here. The injected code can be generic, not necessarily targeted at a specific procedure type. And of course that code is often targeted at both legacy and abc.

I don’t know what situation triggered this change, but presumably theres another template that generates code which can corrupt ReturnValue.

You are of course free to revert the change, and if you ever fall foul of the combination you can let us know.

Personally I’m pretty sure it was done to solve a specific issue, and I’m happy if the templates avoid the issue for me. But if your curiosity exceeds mine then revert, and wait for a bug report when your process (or report?) fails. (Presumably by excluding some records you were expecting to be included.)

1 Like
5

Fortunately, I’m not writing templates for general use by a number of users with wildly different needs/apps. :slight_smile:

After digging into it further, I think they were making the ABC process’s ValidateRecord “work” the same as the ABC browse’s ValidateRecord. Too bad they didn’t use the same naming convention. I didn’t look at the ABC report template since I use a third-party report.