C
Chris Koster
Guest
I have noticed a behavior inconsistency with regards to buffer availability and FINALLY blocks. I made sure that I executed the exact same code in the different environments. Here is the simplified program to demonstrate: DEFINE TEMP-TABLE ttTest NO-UNDO FIELD cField AS CHARACTER INITIAL "123". DEFINE BUFFER bufTest FOR ttTest. CREATE bufTest. MESSAGE "SESSION
ISPLAY-TYPE:" SESSIONISPLAY-TYPE SKIP "SESSION:CLIENT-TYPE:" SESSION:CLIENT-TYPE SKIP "PROVERSION(1):" PROVERSION(1) SKIP "AVAILABLE bufTest:" AVAILABLE bufTest VIEW-AS ALERT-BOX INFO BUTTONS OK. FINALLY: MESSAGE "AVAILABLE bufTest:" AVAILABLE bufTest VIEW-AS ALERT-BOX INFO BUTTONS OK. END FINALLY. In an Windows AppBuilder, these are the messages I get: First message SESSIONISPLAY-TYPE: GUI SESSION:CLIENT-TYPE: 4GLCLIENT PROVERSION(1): 11.7.5.0.1811 AVAILABLE bufTest: yes Second message AVAILABLE bufTest: no In an Linux mpro editor, these are the messages I get: First message SESSIONISPLAY-TYPE: TTY SESSION:CLIENT-TYPE: 4GLCLIENT PROVERSION(1): 11.7.5.0.1811 AVAILABLE bufTest: yes Second message AVAILABLE bufTest: no In a Classic WebSpeed environment, these are the messages I get: First message SESSIONISPLAY-TYPE: TTY SESSION:CLIENT-TYPE: WEBSPEED PROVERSION(1): 11.7.5.0.1811 AVAILABLE bufTest: yes Second message AVAILABLE bufTest: yes Notice that the message in the FINALLY block on Classic WebSpeed is yes , while the others are no . What is interesting, is that the Classic WebSpeed and Linux mpro editor messages are from the same machine. The problem is that we have existing code that works according to the Classic WebSpeed behavior. I noticed the inconsistency when some of our programs stopped working when I evaluated PASOE on OE 12.0 and OE 12.1 - which also reports no in the FINALLY block. Question is, what is the correct behavior? For us, it is a change in behavior, and it might be difficult to identify other pieces of code in the system that follows the same pattern.
Continue reading...
ISPLAY-TYPE:" SESSIONISPLAY-TYPE SKIP "SESSION:CLIENT-TYPE:" SESSION:CLIENT-TYPE SKIP "PROVERSION(1):" PROVERSION(1) SKIP "AVAILABLE bufTest:" AVAILABLE bufTest VIEW-AS ALERT-BOX INFO BUTTONS OK. FINALLY: MESSAGE "AVAILABLE bufTest:" AVAILABLE bufTest VIEW-AS ALERT-BOX INFO BUTTONS OK. END FINALLY. In an Windows AppBuilder, these are the messages I get: First message SESSIONISPLAY-TYPE: GUI SESSION:CLIENT-TYPE: 4GLCLIENT PROVERSION(1): 11.7.5.0.1811 AVAILABLE bufTest: yes Second message AVAILABLE bufTest: no In an Linux mpro editor, these are the messages I get: First message SESSIONISPLAY-TYPE: TTY SESSION:CLIENT-TYPE: 4GLCLIENT PROVERSION(1): 11.7.5.0.1811 AVAILABLE bufTest: yes Second message AVAILABLE bufTest: no In a Classic WebSpeed environment, these are the messages I get: First message SESSIONISPLAY-TYPE: TTY SESSION:CLIENT-TYPE: WEBSPEED PROVERSION(1): 11.7.5.0.1811 AVAILABLE bufTest: yes Second message AVAILABLE bufTest: yes Notice that the message in the FINALLY block on Classic WebSpeed is yes , while the others are no . What is interesting, is that the Classic WebSpeed and Linux mpro editor messages are from the same machine. The problem is that we have existing code that works according to the Classic WebSpeed behavior. I noticed the inconsistency when some of our programs stopped working when I evaluated PASOE on OE 12.0 and OE 12.1 - which also reports no in the FINALLY block. Question is, what is the correct behavior? For us, it is a change in behavior, and it might be difficult to identify other pieces of code in the system that follows the same pattern.Continue reading...