You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I thought this might be an interesting thing to write about. For those that aren't aware, NetRPG is a .NET runtime (JIT) for free-format RPGLE applications. The latest thing that I have been working on is display file support.
This post does not indicate that display files are fully supported - because they are not and there is still a bit of work to do. The progress is good, though.
There are currently two steps to the runtime.
Parse into bytecode
Run bytecode in VM
Display files are interesting when it comes to the runtime because as of when this post is being written, the display file also gets parsed during runtime as well (when the display file is defined.)
Example display file
A R NEWFMT
A NAME 20 O 7 46
A EMAIL 20 O 8 46
A ID 10D B 5 46
A COLOR(WHT)
A 20 25'F3=Exit'
A COLOR(BLU)
A 20 9'Enter=Continue'
A COLOR(BLU)
A 2 62SYSNAME
A COLOR(BLU)
A 5 23'ID:'
A 7 21'Name:'
A 8 20'Email:'
A 2 33'User Entry'
A COLOR(WHT)
This is a very simple display file. It has a single record format and three fields. It also has a lot of static text with colours and also the use of the SYSNAME keyword.
When this program is executed under NetRPG, the compiler will open ex3 (our display file) and get all of the fields out of the record formats and put them into their respected data structures. For example, a structure called NEWFMT would be created with three subfields: NAME, EMAIL and ID. It does not care about the keywords of the display file fields at this point.
It would look something like this in RPGLE:
Dcl-Ds NEWFMT;
NAME Char(20);
EMAIL Char(20);
ID Zoned(10);
End-Ds;
This means we can then reference our three subfields in our program which is then used when the display file is rendered.
Executing the program
When the program is executed (e.g. it's executing the bytecode generated from the compiler) it will re-parse the display file again so the keywords can be used to format the display. NetRPG uses gui.cs under the covers to create a 'green screen' and NetRPG will create different Views for different types for fields.
Here is a snippet of code from the display renderer:
I thought this might be an interesting thing to write about. For those that aren't aware, NetRPG is a .NET runtime (JIT) for free-format RPGLE applications. The latest thing that I have been working on is display file support.
This post does not indicate that display files are fully supported - because they are not and there is still a bit of work to do. The progress is good, though.
There are currently two steps to the runtime.
Display files are interesting when it comes to the runtime because as of when this post is being written, the display file also gets parsed during runtime as well (when the display file is defined.)
Example display file
This is a very simple display file. It has a single record format and three fields. It also has a lot of static text with colours and also the use of the
SYSNAME
keyword.Compiling our program
Here is our RPG program:
When this program is executed under NetRPG, the compiler will open
ex3
(our display file) and get all of the fields out of the record formats and put them into their respected data structures. For example, a structure calledNEWFMT
would be created with three subfields:NAME
,EMAIL
andID
. It does not care about the keywords of the display file fields at this point.It would look something like this in RPGLE:
This means we can then reference our three subfields in our program which is then used when the display file is rendered.
Executing the program
When the program is executed (e.g. it's executing the bytecode generated from the compiler) it will re-parse the display file again so the keywords can be used to format the display. NetRPG uses gui.cs under the covers to create a 'green screen' and NetRPG will create different
View
s for different types for fields.Here is a snippet of code from the display renderer:
Then after it's determined what type of field it is, it then handles the keywords (like
SYSNAME
orCOLOR
):And the result is it creating display files:
The text was updated successfully, but these errors were encountered: