Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - James Zukowski

General Announcements / Re: Forum Upgrade
July 11, 2024, 03:04:52 PM
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?
Programming / Re: Spawning a session
April 19, 2024, 11:56:58 AM
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?
Language / EXTRACT not locking?
April 18, 2024, 02:32:03 PM
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.

Programming / Re: Spawning a session
April 18, 2024, 08:58:00 AM
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.
Programming / Re: strange error 61
April 16, 2024, 12:53:18 PM
Have you tried separating the OPEN from the LOCK?
Programming / Re: Help with Initial Value Load Error
April 12, 2024, 04:08:30 PM
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.
Nomads / Re: Panel Startup Timing
April 09, 2024, 02:19:19 PM
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.
Nomads / Re: Panel Startup Timing
April 05, 2024, 04:33:22 PM
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...
Nomads / Re: Panel Startup Timing
April 05, 2024, 03:14:03 PM
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.
Nomads / Re: Panel Startup Timing
April 05, 2024, 01:51:37 PM
(Un)Fortunately, there are only about 30-40 left to remove the SPAWNing from, and we're developing all new panels without it; they're directly PROCESSed. They also seem to take a fair amount of launch time.

Is there anything I could look into?
Nomads / Panel Startup Timing
April 05, 2024, 11:19:45 AM
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!
(Added un-accented listbox snip for comparison)