That's an interesting twist. Haven't tried that before.

How about defining the panel as a Child Dialogue (maybe with Synchro-Lock)?

We encountered an interesting situation and could use some clarity and/or confirmation.

Using a Linux server (RHEL 7.9) with PxPlus v15.1 via WindX we open a test file and EXTRACT a record. In another session, open the same file and READ the record. No Error 0.

Upon closer examination, we noticed the Linux file permissions were "-rw-r--r--" and the file was "owned" by a different username. When we changed the permissions to "-rw-rw-rw-", the EXTRACT/READ above worked as expected.

So, it seems that an EXTRACT on a file where a WRITE cannot actually happen is treated as a READ, even though everything, including FIN(ch,"Extract"), suggests the EXTRACT really happened. Except it didn't.

Is this proper? Or is there something missing along the way?

Any guidance would be greatly appreciated.

Thanks!

Have you tried separating the OPEN from the LOCK?

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.