In the early days of EDDL technology adoption, EDDL hosts tended to have method interpreters that went to a new line on the screen after each step of the method was executed. The screen was not erased between steps. Examples of that operation can still be seen today in the NI Configurator, or in the FF DD-IDE when a method is executed. Early hand-held hosts worked in a similar manner.
The display_message built-in, and the cross-block version display_message2 works fine in that circumstance.
In modern hosts, after each method built-in is executed, the host will clear the screen contents and show the next step of the method in the same dialog box.
Since the display_message and display_message2 built-ins merely tell the host to display a message, and then the built-in is finished, the screen in a modern host will typically erase the message immediately after it is displayed in order to move on to the next step in the method. In such a case, the message will not be shown long enough to be read, or it may not show up at all, depending upon the speed at which the method interpreter is able to run on that particular host.
Existing DD4 and DD5 EDDs that include this method built-in will therefore have problems when the message of the method is to be displayed. This is unfortunate, but since the EDDL specifications do not define this built-in to be displayed for any specific length of time, and there is no mechanism to acknowledge the message, this means the use of this method built-in should be considered to be deprecated for modern EDDL projects.
One solution available to a developer is to use the delayfor built-in instead. This built-in provides a way to tell the host the number of seconds to keep the message on the screen before continuing to the next step in the method.