Hi Ward,

 I did some testing in Extra! X-treme v9.6 SP1 and found that there is a problem where the “Paste” operation becomes disabled, but it doesn’t seem to be related to screen history but is related to which VT Page memory the terminal is displaying.

I’ve found that the “Paste” operation is disabled when the VT terminal is displaying any VT page of memory other than Page 1.  By default, it is always on VT Page 1, but your host application could be displaying a different page of memory (i.e. Page 2 to 6).  Note: Page memory is different than screen history.

To see which page of memory the terminal is displaying, look at the VT status line. 

The first number shows which Page of memory the VT cursor is on (which is normally always “1” unless your application is showing a different page).  The other numbers are which row and column the cursor is on.   If the status line is showing any number other than “1” for the Page memory, then you will encounter this problem.

I tested Extra! v9.6 and found the problem doesn’t occur.  I didn’t test v9.2, so don’t know it behaves exactly like v9.6, but this is definitely a change in behavior between v9.6 and v9.6 SP1 so will report it to Development.  I could not find a workaround to the problem—other than using v9.6 without the Service Pack.

If this doesn’t seem to be the problem you are experiencing, please contact OpenText Technical Support so we can troubleshoot further.

Regards,

Dawn

Hi Ward,

 I did some testing in Extra! X-treme v9.6 SP1 and found that there is a problem where the “Paste” operation becomes disabled, but it doesn’t seem to be related to screen history but is related to which VT Page memory the terminal is displaying.

I’ve found that the “Paste” operation is disabled when the VT terminal is displaying any VT page of memory other than Page 1.  By default, it is always on VT Page 1, but your host application could be displaying a different page of memory (i.e. Page 2 to 6).  Note: Page memory is different than screen history.

To see which page of memory the terminal is displaying, look at the VT status line. 

The first number shows which Page of memory the VT cursor is on (which is normally always “1” unless your application is showing a different page).  The other numbers are which row and column the cursor is on.   If the status line is showing any number other than “1” for the Page memory, then you will encounter this problem.

I tested Extra! v9.6 and found the problem doesn’t occur.  I didn’t test v9.2, so don’t know it behaves exactly like v9.6, but this is definitely a change in behavior between v9.6 and v9.6 SP1 so will report it to Development.  I could not find a workaround to the problem—other than using v9.6 without the Service Pack.

If this doesn’t seem to be the problem you are experiencing, please contact OpenText Technical Support so we can troubleshoot further.

Regards,

Dawn

Hi Dawn,

I appreciate you taking the time to research this, as it was a productivity killer. My findings are not the same as yours, however.  VT page in memory stayed as 1 at all times when "paste" became disabled.  I created the scenario every time by simply listing a directory containing a very large number files.  On version 9.3 it had no issue.  On version 9.6 SP it had an issue every time, strictly related to amount of screen I/O, possibly involving history.

I just became aware that the new version 9.7 became available in May 2023, so I downloaded that and tested it yesterday.  I am happy to report that since upgrading to version 9.7, the problem has been resolved.

Thanks again for your help