We will take this under consideration, however please see reply number 2 in this topic as to how you can do this currently.
https://forum1.pvxplus.com/index.php?topic=125.msg292#msg292

The issue with changing the background is that we would have to define a special color for every theme since a red background might result in a line of text that would not be very readable due to different text colors.

If you do want the errors to stand out more give the Chaos theme a try. It highlights the line number column instead of just using the red cross.

BTW: The themes are fully editable.  Their definition is controlled by the theme-xxxxxx.js files found in *plus/inomads/add-ons/editors/ace/src-noconflict.  We provide the standard themes but if desired you can add your own custom one. 

---

Note: The ACE editor has changed the way these files are used in their latest release.  We are considering updating to the new version of ACE in the future however the basic layout will remain the same.

Lawrence, a good wide-area network should still have a fairly respectable packet exchange time.  For example we have an Amazon server in Oregon and when we time how long a FIN request takes we get an response of less than a 1/10th of a second for the packets to go between Toronto and Oregon (basically coast to coast plus an international gateway -- routing over 24 points according to tracert )

Here is what we ran:

-;list
0001 LET x=TMR(0)
0010 FOR i=1 TO 100
0020 LET x$=FIN(0)
0030 NEXT i
0031 PRINT TMR(0)
-;run
 8.609
(so 100 requests in 8.6 seconds or 0.086 seconds per request)

So given that most users could not distinguish anything below about 1/2 a second, you should be able to run a handful of FIN requests in your logic without any noticeable delay.

However going back to the original question you have not answered; Did you try a simple INPUT statement to see how it performed and how does all of this relate to program load times???

Have you tried a simple program such as:

10 INPUT "Enter your name:",x$
20 PRINT "Hello ",x$

Does this also exhibit the slow down?

Also your post title is "Slow Program LOAD".  I'm not certain how a slow program load is related to terminal input.  Slow program loads generally has to do with system loading or perhaps the number of directories being searched to find the program.

Lastly, with regards to the FIN/FIB functions, while these provide information about the terminal state, on WindX they also include information only know to the workstation such as X/Y screen co-ordinates which the user can change at any time.  Accessing the FIB requires a packet exchange with the workstation thus can slow down input processing. (This additional information is not applicable/available when using text terminal emulators). 

You should make sure you minimize the number of calls to this function to improve performance when using WindX.

Mind you a packet exchange with WindX on most networks only takes a few hundredths of a second (if that) so unless you have a very slow network or are doing an excessive number of requests your performance should not be visibly impacted by a couple of FIN/FIB requests.

What do you have the terminal type set to?
For WindX it should be set to 'ansi' or 'winterm'.

What Server OS and version of the software.

Also is this just simple input or are you running your input through some form of input handling routine? 

We have seen instances where an input handler attempts to get information from the workstation in each keyboard input.  Basically reading a character at a time then asking for the FIB/FIN/FID or other information that has to be requested from the workstation.  This can slow down performance since when using WindX we forward the request to the workstation for the information whereas with text mode terminals we simply use information held on the server and just assume that things like cursor position are correct.

If the problem persists we suggest you open a helpdesk ticket so we can provide further assistance.

What do you mean by "Text Emulator"? 
Are you referring to a terminal emulator such as Putty?

When you are running WindX -- how are you connecting?  SSH, Telnet, Simple CS, NTHost/Slave, App Server?
Also when you say you LOAD a program into memory do mean issuing a LOAD "xxxxx" command at command line and if so what is the pathname of the program?

We have this under review however the challenge is that the original design permitted only 1000 controls for a panel and these were split into 200 for the main panel and 200 each for up to four concurrent panels.

What we are considering is allowing the main panel to have more but reducing the number of concurrent panels.

In the interim what might work for you is to maximize the main window and create four concurrent panels on top of the main window.  Set the concurrent windows as frame-less and synchro-lock.  This would get you up to 800 controls (1000 if you put some controls on the main window).

Other options to get beyond 200 items on the screen are:

• Use Radio buttons for Buttons and in the select logic use the ID to determine which actual button was pressed and then reset that button so it looks normal.  This will get you 255 buttons per radio button. With a little effort you can replace up to 255 buttons, check_boxes or radio_buttons with a single control.  (We use this technique in the Bitmap selector for the Nomads designer)
• Use a GRID where possible and hide the grid lines and column/row headers while setting the background to the same as your screen.  This can get you input fields, drop down lists, buttons, and check-boxes along with variable text.

When running PxPlus on Linux/AIX or similar systems, the system will load the SSL libraries when the first reference is made to any component within the libraries is required.  The fact that the SSL libraries are not directly linked into the EXE allows these libraries to be independently updated.  The same is true for Windows however there we actually ship current SSL libraries with the product as opposed to relying on the OS supplying them.

Not all applications will need the SSL libraries, but the following PxPlus functions do require them to be present:

• Any access to SSL/TLS communications (TCP, HTTPS, etc connections)
• Use of the HSH functions other than the basic hashing algorithm (hash type 0)

Over time the SSL libraries on your system may need to be updated to address problems and deficiencies that may be discovered and corrected by the makers of openssl.   On Linux and most Unix based systems, these updates can be obtained using the OS supplied software update utilities.  For PxPlus for Windows, these can be extracted from newer versions of PxPlus and applied as needed.

Because security is so important we kept these libraries external from PxPlus so they may be updated as needed without having to replace/updated the whole PxPlus installation.