In the ABL2DB testing, we have run across a statement:
DEFINE INPUT PARAMETER ip-CtpApplicationMeaningType LIKE INPUT ICMAS.ChargeType.CtpApplicationMeaningType NO-UNDO.
From what I see in the manual, that second LIKE should be making the compiler upset, but it doesn't seem to be. Is this a case of the compiler just being generous or is there some actual meaning which this indicates?
DEFINE INPUT PARAMETER ip-CtpApplicationMeaningType LIKE INPUT ICMAS.ChargeType.CtpApplicationMeaningType NO-UNDO.
When you display a variable, there are two memory locations associated with it, namely the variable itself and the screen buffer.
To access the variable, you use its name, to access the screen buffer, you prefix the variable name with INPUT or INPUT FRAME framename.
So given that the above compiles, I suspected that the parameter, variable, temp-table (or work-table) field that is defined as LIKE, could take its attributes (e.g. FORMAT and LABEL) from an instance on a frame rather than from the original definition.
So I tested it with the following code, expecting to see:
My Data: 123456789012 Long Data: 12345678901234567890
Interestingly enough, it does not. What is more interesting, is that it keeps compiling and working the same as before, even when you remove the definition of frame fDataFrame completely.
It appears that the compiler knows that "INPUT [ FRAME framename ] field" is a reference to "field" and simply ignore the "noise" caused by input, causing you to end up with legal syntax, i. e. "LIKE field", as the output is always:
My Data: 123456789012
My Data: 123456789012
The test code looks like this: (Is it just me, or is OpenEdge now missing from the syntaxhighligter tool?)
DEFINE VARIABLE cData AS CHARACTER FORMAT "X(12)" LABEL "My Data" NO-UNDO. DEFINE FRAME fDataFrame cData FORMAT "x(20)" LABEL "Long Data" VIEW-AS COMBO-BOX WITH SIDE-LABELS. DEFINE VARIABLE cNewData LIKE INPUT FRAME fDataFrame cData NO-UNDO. DEFINE FRAME fNewFrame cData cNewData WITH 1 COL. ASSIGN cData = "12345678901234567890" cNewData = "12345678901234567890" . DISPLAY cData cNewData WITH FRAME fNewFrame.
Quite an interesting peculiarity you found here...
Right, in my test program there is no frame defined, which makes the INPUT nonsense ... but it compiles!
The code below is more like my example and running it seems to suggest that the result of the two styles is the same. So I'm guessing it's just ignored.
procedure test:
DEFINE INPUT PARAMETER ip-Input LIKE INPUT ChargeType.CtpApplicationMeaningType NO-UNDO.
DEFINE INPUT PARAMETER ip-Normal LIKE ChargeType.CtpApplicationMeaningType NO-UNDO.
message ip-Input skip ip-Normal view-as alert-box.
end.
run test("Test1","Test2").