Also check if there is supposed to be a space between "Basic" and the rest of it.

Taking a closer look, it seems like you're mixing header and detail information in the package contents.

I've been using the PxPlus Web Request process (see https://manual.pvxplus.com/PXPLUS/Web%20Services/Overview.htm[color=var(--body-txt-color)]) for these types of things:[/color]

CALL "*plus/web/request",SiteURL$,RequestData$,Resp$,RespHdr$,MimeType$,"",ExtraHdr$
where: SiteURL$ would be your URL$, RequestData$ would probably just be the Gift_Card_Number and CVV, ExtraHdr$ would contain the Accept and Authorization (without quotes), and MimeType$ would be the Content_Type (application/json). You may also want to include "Accept: application/json" in the ExtraHdr$ to identify the return format. I let PxPlus determine the method.

After the call, the returned package would be in Resp$, and any header info would be in RespHdr$.

Good luck!

Seems to me that it's something the host service doesn't like. I'd suggest checking with the provider and their documentation to see what they have to say.

Unless someone else has a better idea...

Is the auth code supposed to be Base64, or should it be plain text?
Is this a 'constant' or is it returned from a prior call (OAuth2, etc.)?

Is there a way to get something like the old singular "Unread Posts" button? With this new format, it seems I get to check the Alerts as well as the Updated Tops and Unread Posts under my avatar if I want to get all of the updates since the last time I checked.

As a possibility, you could enable it before the load and disable it immediately after. That would minimize the potential crash time.

Not sure if this would apply... Have you checked out the 'RI' and 'RN' parameters?

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

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

This also seems to cause a problem with descenders, too. In the latest example, is that "Hague" or "Haque"?

Does anyone know if this is PxPlus or Windows behavior? Is there some setting I'm not setting?

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!

And to make things easier for the user, you could include a "Copy" button with each data field which will put it on the clipboard. They could then just click in the field and paste it.

Have you tried separating the OPEN from the LOCK?

If you're use PROCESS to work the panel, then all variables should be cleared when you exit the panel. Alternatively, when you initialize the panel, before you load the listbox, be sure to clear all of the field variables.

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.

Another observation: Tabbing from field to field also takes a LOT of time, even on the test server, which has VERY few users. The server utilization theory fails there...