Mike:
The timed trace was a great insight. It looks like each WindX transaction averages about 0.045 seconds on our network. So if I'm grabbing a property from 2 controls in 1 LET statement, or get one and set another, for example, that's 2 transactions, or about .09 seconds. MSE and obj(0) seem to be 0.09 each, etc.

The old panels had been set up as Resizable/Auto-Size. This caused multiple transactions per control once they were first drawn to see if they needed to be changed (which they didn't).

I reset these to Resizable/Custom and set appropriate anchor points for each control. This took a launch time of about 6.5 seconds down to less than 1.5.

Thanks for the help! GREATLY appreciated.

P.S.: We didn't do anything with Turbo Mode. If NOMADS did, then that's another story.

P.P.S.: Still haven't figured out why SPAWNing always worked so fast. There are bigger fish to fry at this point, and they'll all eventually go away, so it will be a moot point soon.

I thought SPAWNing would take more time, too. I ran a brief test on our test server, and the first time I ran the panel, it came up in about 2 seconds. Exiting back to the menu and starting again took about 8 seconds, which remained consistent in subsequent runs. So...why would the first run launch so quickly and the others not? It doesn't make sense to me.

If we scrapped the show(-1) method, what would be the 'best' method to hide the menu? Move it WAAY off the screen, and move it back later? Something else? It seems like with Win 11 (or earlier), we've lost the ability to right-click an icon on the taskbar and move the window with the arrow keys, so shifting off-screen is a concern.

Until I started here a couple of years ago, the NOMADS panels that were being used were being SPAWNed as separate processes off our menus. Since that would allow for multiple 'sessions' using the same FID(0), it also led to occasional file conflict problems. We've been working to remove the SPAWNing part of the sequence and just have the menu PROCESS the panel directly after hiding itself ['show'(-1)]. With a little work to undo some of the added 'hooks' for the SPAWNing, this works pretty well.
The problem we're running into is timing. When the panel was SPAWNed, it loaded and displayed VERY quickly. However, directly PROCESSing the panel generally takes quite a bit longer, sometimes 6-8 seconds or more compared to the 0-2 seconds previously. And it doesn't necessarily correlate with the number of controls on the panel. Perhaps it can sometimes be chalked up to server utilization, but it seems to be a pretty consistent differential.
We're running RHEL 7.9 (64-bit) with PxPlus v15.1 and WindX via VPN. Most of the client PCs have been upgraded from Win 10 to Win 11.
After the latest wave of updates, we're starting to get some clear complaints about this. Any suggestions would be greatly appreciated.
Thanks, all!

We have a Report View listbox with 4 text lines per entry. When we include accented characters as part of a line, it breaks the line and we now have 5 text lines (see attached). If I translate the accented characters into un-accented characters, it's back to being a 4-line entry.

Is there an option I'm missing somewhere? Is this something with Windows or PxPlus and listboxes?

Suggestions welcome.

Done as prescribed, my results:
-;setesc on
-;run
 1 2 3CAT
Try to break out:
 4 5 6DOG
Try to break out:
 7 8 9PIG
Try to break out: That was easy.
-;
-;
-;setesc off
-;run
 1 2 3CAT
Try to break out:
 4 5 6DOG
Try to break out:
 7 8 9PIG
Try to break out: Try to break out: Try to break out: Try to break out: Try to b
reak out:

This is using the standard keyboard definition, unmodified.

Running v15.1 on Linux through WindX with Win 10 client.

We're starting to get new people using our application, and instead of using the F-keys we display, they'll use then ESCape key. Normally, we wouldn't expect any problems, but it seems that PxPlus maps then ESCape key to ctl=4 (F4 key) by default. Is this correct? Or was there a change a while back? Or am I missing a parameter setting?

I've changed 'my' keyboard configuration to have ESC return $1B$ and it works as expected.

BTW, the example program for 'Format 3' on the SETESC page does not work exactly as described in the table.

This may have something to do with the file being built as an EFF file.
See EFF vs VLR File Formats for further details.