[archive] Grid Corruption

[Migrated content. Thread originally posted on 01 December 2009]

We must be doing something wrong, so please help if you can.

We're using AcuBench, but we're not using it to generate code. The logic of the program is totally in our hands. We use AcuBench to generate screens etc, but not code.

Our basic screen handling logic is like this:-
           DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE.
     
           MOVE 99 TO PF-KEY.

           PERFORM UNTIL PF-KEY = 16
               ACCEPT SS01
                   ON EXCEPTION CONTINUE
               END-ACCEPT
               EVALUATE PF-KEY
               WHEN....
                      .... DO STUFF
               END-EVALUATE
               DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE
           END-PERFORM.

The problem we seem to be wrestling with is damage to grids when the second DISPLAY statement is executed.

We often see damage such as grid headings being overwritten with data, or the last row of the grid being initialized.

Does anyone have some sure-fire tricks or tips for using grids?

Thanks,

Ian

The grid is pretty much event driven, do you have an event paragraph that processes grid events, modify that grid, inquire or other things?
Does your grid have a before procedure that is loading data? When the second display comes along, a before procedure will get processed, if your data is not initialized like it is on the first display you will get different data on the second display.

[Migrated content. Thread originally posted on 01 December 2009]

We must be doing something wrong, so please help if you can.

We're using AcuBench, but we're not using it to generate code. The logic of the program is totally in our hands. We use AcuBench to generate screens etc, but not code.

Our basic screen handling logic is like this:-
           DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE.
     
           MOVE 99 TO PF-KEY.

           PERFORM UNTIL PF-KEY = 16
               ACCEPT SS01
                   ON EXCEPTION CONTINUE
               END-ACCEPT
               EVALUATE PF-KEY
               WHEN....
                      .... DO STUFF
               END-EVALUATE
               DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE
           END-PERFORM.

The problem we seem to be wrestling with is damage to grids when the second DISPLAY statement is executed.

We often see damage such as grid headings being overwritten with data, or the last row of the grid being initialized.

Does anyone have some sure-fire tricks or tips for using grids?

Thanks,

Ian

Looking back at my OP, it was a bit short on details.

1. We are using AcuConnect thin client with a Linux server. We've experienced the same problems with 7.2 and 8.1.
2. Our grid has an event procedure, but no before or after events. When I debug the issue, the event procedure isn't being called (my breakpoint at the start of the event procedure is not triggered).
3. This problem mainly occurs when we put grids on tabs.
4. We use modify statements to load the grid after the screen has been created (displayed), and it looks perfect when complete. If we then change tabs and then come back to the tab with the grid on it (the second display is called here) the grid is broken again.
5. Our grids usually carry significant amounts of hidden data - sometimes more than 1k per grid row spread between several grid cells.

Dilbert, reading your comment about the grid not being initialized like it is on the first display, I find this difficult to confirm or deny. My belief is that the grid is not changing, but how can I monitor it in debug to make sure?

Thanks,

Ian

[Migrated content. Thread originally posted on 01 December 2009]

We must be doing something wrong, so please help if you can.

We're using AcuBench, but we're not using it to generate code. The logic of the program is totally in our hands. We use AcuBench to generate screens etc, but not code.

Our basic screen handling logic is like this:-
           DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE.
     
           MOVE 99 TO PF-KEY.

           PERFORM UNTIL PF-KEY = 16
               ACCEPT SS01
                   ON EXCEPTION CONTINUE
               END-ACCEPT
               EVALUATE PF-KEY
               WHEN....
                      .... DO STUFF
               END-EVALUATE
               DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE
           END-PERFORM.

The problem we seem to be wrestling with is damage to grids when the second DISPLAY statement is executed.

We often see damage such as grid headings being overwritten with data, or the last row of the grid being initialized.

Does anyone have some sure-fire tricks or tips for using grids?

Thanks,

Ian

Looking back at my OP, it was a bit short on details.

1. We are using AcuConnect thin client with a Linux server. We've experienced the same problems with 7.2 and 8.1.
2. Our grid has an event procedure, but no before or after events. When I debug the issue, the event procedure isn't being called (my breakpoint at the start of the event procedure is not triggered).
3. This problem mainly occurs when we put grids on tabs.
4. We use modify statements to load the grid after the screen has been created (displayed), and it looks perfect when complete. If we then change tabs and then come back to the tab with the grid on it (the second display is called here) the grid is broken again.
5. Our grids usually carry significant amounts of hidden data - sometimes more than 1k per grid row spread between several grid cells.

Dilbert, reading your comment about the grid not being initialized like it is on the first display, I find this difficult to confirm or deny. My belief is that the grid is not changing, but how can I monitor it in debug to make sure?

Thanks,

Ian

[Migrated content. Thread originally posted on 01 December 2009]

We must be doing something wrong, so please help if you can.

We're using AcuBench, but we're not using it to generate code. The logic of the program is totally in our hands. We use AcuBench to generate screens etc, but not code.

Our basic screen handling logic is like this:-
           DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE.
     
           MOVE 99 TO PF-KEY.

           PERFORM UNTIL PF-KEY = 16
               ACCEPT SS01
                   ON EXCEPTION CONTINUE
               END-ACCEPT
               EVALUATE PF-KEY
               WHEN....
                      .... DO STUFF
               END-EVALUATE
               DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE
           END-PERFORM.

The problem we seem to be wrestling with is damage to grids when the second DISPLAY statement is executed.

We often see damage such as grid headings being overwritten with data, or the last row of the grid being initialized.

Does anyone have some sure-fire tricks or tips for using grids?

Thanks,

Ian

I'd say the issue is with the tabs and not the grid. I know that you are using your own code, for tabs you "really" have to watch the visible variable setting. If you miss a visibile variable, you may get bleed through, data ontab3 is bleeding through and showing on tab1

[Migrated content. Thread originally posted on 01 December 2009]

We must be doing something wrong, so please help if you can.

We're using AcuBench, but we're not using it to generate code. The logic of the program is totally in our hands. We use AcuBench to generate screens etc, but not code.

Our basic screen handling logic is like this:-
           DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE.
     
           MOVE 99 TO PF-KEY.

           PERFORM UNTIL PF-KEY = 16
               ACCEPT SS01
                   ON EXCEPTION CONTINUE
               END-ACCEPT
               EVALUATE PF-KEY
               WHEN....
                      .... DO STUFF
               END-EVALUATE
               DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE
           END-PERFORM.

The problem we seem to be wrestling with is damage to grids when the second DISPLAY statement is executed.

We often see damage such as grid headings being overwritten with data, or the last row of the grid being initialized.

Does anyone have some sure-fire tricks or tips for using grids?

Thanks,

Ian

I'd say the issue is with the tabs and not the grid. I know that you are using your own code, for tabs you "really" have to watch the visible variable setting. If you miss a visibile variable, you may get bleed through, data ontab3 is bleeding through and showing on tab1

[Migrated content. Thread originally posted on 01 December 2009]

We must be doing something wrong, so please help if you can.

We're using AcuBench, but we're not using it to generate code. The logic of the program is totally in our hands. We use AcuBench to generate screens etc, but not code.

Our basic screen handling logic is like this:-
           DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE.
     
           MOVE 99 TO PF-KEY.

           PERFORM UNTIL PF-KEY = 16
               ACCEPT SS01
                   ON EXCEPTION CONTINUE
               END-ACCEPT
               EVALUATE PF-KEY
               WHEN....
                      .... DO STUFF
               END-EVALUATE
               DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE
           END-PERFORM.

The problem we seem to be wrestling with is damage to grids when the second DISPLAY statement is executed.

We often see damage such as grid headings being overwritten with data, or the last row of the grid being initialized.

Does anyone have some sure-fire tricks or tips for using grids?

Thanks,

Ian

I'd say the issue is with the tabs and not the grid. I know that you are using your own code, for tabs you "really" have to watch the visible variable setting. If you miss a visibile variable, you may get bleed through, data ontab3 is bleeding through and showing on tab1

[Migrated content. Thread originally posted on 01 December 2009]

We must be doing something wrong, so please help if you can.

We're using AcuBench, but we're not using it to generate code. The logic of the program is totally in our hands. We use AcuBench to generate screens etc, but not code.

Our basic screen handling logic is like this:-
           DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE.
     
           MOVE 99 TO PF-KEY.

           PERFORM UNTIL PF-KEY = 16
               ACCEPT SS01
                   ON EXCEPTION CONTINUE
               END-ACCEPT
               EVALUATE PF-KEY
               WHEN....
                      .... DO STUFF
               END-EVALUATE
               DISPLAY SS01 UPON WSSVI-WINDOW-HANDLE
           END-PERFORM.

The problem we seem to be wrestling with is damage to grids when the second DISPLAY statement is executed.

We often see damage such as grid headings being overwritten with data, or the last row of the grid being initialized.

Does anyone have some sure-fire tricks or tips for using grids?

Thanks,

Ian

It seems we've found the problem. Our record-data wasn't being initialized to spaces and we weren't really aware of the effect the DISPLAY has on the last record of the grid.

In section 12.2 of Book 2, it states (with regard to list-boxes):-

Question:

When the runtime is putting data into a standard list box or combo box defined in the Screen Section, the last data item gets repeated. How do I prevent this?
Answer:

You need to move spaces to your ITEM-TO-ADD data item after you have finished filling the list box or combo box. Otherwise, the last data item it contains will be added to the box every time you DISPLAY that Screen Section box, or any of its parent group items.

This seems to hold true for grids as well.

Thanks for taking the time to help :)

Ian