next »

[Judy S.]

Hello,

Has anyone developed a solution to force the synchronization to the front end, especially for the 4gl ERROR statements?

We have too many programs that were written many years ago, that use ERROR messages to display information during a non-dialog mode, such as while posting data/batch-processing/printing to a report.

We have been trying to modify our code to add the "call ui.interface.refresh()" statement to each and every place that has an "ERROR" statement, but it is not possible to do this because there are too many places.

We need a quick solution that will behave the same as doing an explicit "call ui.interface.refresh()" everywhere we have ERROR statements, without having to explicitly add it to all our code.

Thank you.

[Reuben B.]

I typically suggest creating a function (or series of functions) to contain the ERROR statement, and then run a script over your code to replace ERROR x, with CALL your_error_function(x)

My first migration 10+ years ago, this function was something like ...

FUNCTION display_error(error_text)
DEFINE error_text STRING
    ERROR error_text ATTRIBUTES(RED)
    CALL ui.Interface.Refresh()
END FUNCTION

... so that we had ui.Interface.refresh so that error text was displayed in the window the error was generated from, and also the attribute to display the error text in red

Over the years, variants would include ...

- inside the function, testing if FGLGUI=0 and write to ERRORLOG instead of doing an ERROR
- remove ATTRIBUTES(RED) and use styles when they were added for ERROR and MESSAGE. 
- add a parameter that indicates user acknowledgement is required of the error and use FGL_WINMESSAGE("Error", text, "stop") if that parameter is true
- if text is blank, don't display anything. 

Once you have the ERROR inside a function, it is then easier to make global changes.



Reuben

[Judy S.]

Hi Reuben,

Thank you for your suggestion. However, if I were to do what you suggest, I would still have to find every place in our thousands of 4gl files, that have ERROR statements, and change every single place. Our programs were first developed in the mid 1980's, so you can imagine how many programs we have now, and how many lines of code I would have to change. It would keep be busy for at least the next 3 months just do to this one task.

That is why I was hoping that someone came up with a solution that would work without needing to change very single place that uses ERROR statements.

Some abstract ideas I had:
- is there some 4gl command that could be placed at the start of every program, which would instruct the program to always synch the display to the front end?
- is there a way to write an OVERLOADED FUNCTION version of the ERROR statement? In other words, if I write a function named ERROR, and it is linked into the program, could my version of ERROR get called instead of the built-in version?
- is there a way to change *only* the style presentation for ERROR within a program? In other words, I want our generic styles file to get loaded (default.4st) as usual at the start of every program (which already happens now), but then the program can dynamically change this style for just the ERROR presentation style to a pop-up  type? Our default.4st file has the ERROR style defined to be displayed on the status bar, so this would remain the default behavior, but the program can dynamically change that to pop-up based upon certain conditions.
- is there a way to test if there is an active dialog? What I would like to do is determine if the ERROR's presentation style should be the status bar, or if it should be a pop-up, based upon the result of this test. So from the 4gl program, it would try to do this:
     if (user-interactive dialog is active)  -- HOW DO WE TEST IF THERE IS AN ACTIVE DIALOG OR NOT???
      -- i.e. user is in a dialog where they can use their mouse, keyboard, etc during input or display, etc.
     then
        call change_ERROR_style("pop")  -- call a function which will dynamically change the style for ERROR to pop-up
     else
        call change_ERROR_style("status_bar")  -- call a function which will dynamically change the style for ERROR to status bar
     end if

[Judy S.]

One more question:
- is there a way to test if a screen is even attached? i.e. if a program was launched in some type of background mode, for example run non-interactively by a cron job in the middle of the night, then there is no screen attached, but the program was run with input redirected from a plain text file that contains a line with a value corresponding to the program's input fields. We do this when a client wants to run some program with the same answers every time, and they want it to run automatically. So we set it up as a cron job that has input redirected from a text file. In this situation, we would NOT want ERRORs to pop-up waiting for a user to press a button/key because there will be no user, as the program is running in a non-interactive background mode.

Thank you.

[Reuben B.]

Thank you for your suggestion. However, if I were to do what you suggest, I would still have to find every place in our thousands of 4gl files, that have ERROR statements, and change every single place. Our programs were first developed in the mid 1980's, so you can imagine how many programs we have now, and how many lines of code I would have to change. It would keep be busy for at least the next 3 months just do to this one task.

I'd expect it to be a task that can be measured in hours.  This is assuming A) you use Source Control B) Have the ability to check-out your entire code base, run a script over the sources, check the source back in.

A script could easily convert the cases of ERROR "string", ERROR variable, ERROR function-call(), it would then depend how complex you would want to make your script to handle the more complex cases e.g. ERROR "File not found:", l_filename etc.  For complex cases I would normally add a comment or token in the code so that I know where to go back to and make a manual change, and depending on the volume of complex cases would determine how much energy I spent catering for the complex case in a script ( I say script but these days I tend to write a small 4gl program to do this sort of thing)

is there a way to test if there is an active dialog?

ui.Dialog.getCurrent() https://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_ClassDialog_getCurrent.html

is there a way to test if a screen is even attached? i.e. if a program was launched in some type of background mode, for example run non-interactively by a cron job in the middle of the night, then there is no screen attached, but the program was run with input redirected from a plain text file that contains a line with a value corresponding to the program's input fields. We do this when a client wants to run some program with the same answers every time, and they want it to run automatically. So we set it up as a cron job that has input redirected from a text file. In this situation, we would NOT want ERRORs to pop-up waiting for a user to press a button/key because there will be no user, as the program is running in a non-interactive background mode.

Choose from ...

command line argument - set a command line argument when running in background, then check if command line argument passed
environment variables - Set FGLGUI to 0 for programs with no UI, then check value of FGLGUI in program
ui.Window.getCurrent() - https://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_ClassWindow_getCurrent.html, check value returned
 ui.Interface.getFrontEndName() - https://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_ClassInterface_getFrontEndName.html, check value returned.


Reuben

[Judy S.]

Hi Reuben,

Thank you so much for all of your suggestions. I was almost thinking of writing an awk script to change all the code to add in a "call u.interface.refresh()" but I was hoping for a more sophisticated solution, and besides I would have to brush off all the cob-webs and dust from my brain; it has been a long time since I have used that type of shell scripting ;-)

[Nuno G.]

I don't know if it helps, but have you considered to use a style ?
 <Style name="Message:error">
      <StyleAttribute name="position" value="popup"/>
  </Style>
this will force the opening of a popuo dialog window with your error and therefore force a UI refresh. Same is appliable to messages.
HIH

[Judy S.]

Thank you, Nuno. Yes, I have thought about using style pop-up, and it is a good suggestion, however, I realized that there are times when I wouldn't want these messages to be pop-up, such as when the program is being run in back-ground mode and there is no user who can press the OK button, to allow the program to continue execution.

So based upon the programming 4gl-commands available in Genero, I think the only safest thing I can would be to write a shell script to insert a call to ui.interface.refresh() following each and every "error" statement. That is not a great solution.

Not having the error messages shown to the user is causing much more harm, than the worry about too much network traffic. I am having many complaints by our customers who are not seeing messages in Genero GUI; they are switching from the old BDS GUI and which did not have this problem and always showed the error messages. Not one customer is complaining about network traffic. Genero decided to not have error messages displayed if there is no active dialog because of fear of network traffic. In our case, that has caused more damage than not showing the error messages.

Thanks again.