If you are using PxPlus 2014 or higher you can use "*tools/makeqrcode"


CALL "*tools/makeqrcode","https://home.pvxplus.com","output.png"


If you know that you are updating a record and not inserting a new one you can use the UPDATE directive instead of the WRITE. This would be more efficient as well as PxPlus would not have to try and do an insert fail and then do an update.

Hi Ben,

Check out the pxpsqlsvr.conf.sample file that came with the installation for an example and a description.

You can also read the documentation about the new catalog setup for the server here https://manual.pvxplus.com/?odbc/configuration_procedures/server_settings_unix_linux.htm

Also for clarity here is an example from one of my pxpsqlsvr.conf files


catalogs:
default=*[/myapp/data][][]


In this example I defined a catalog named default which pointed to the data dictionary located at /myapp/data and it does not have an INI file or prefixes

In you ODBC client DSN under the server tab you would then specify default as the catalog name to connect to data from the /myapp/data dictionary.

This is so a server could define multiple catalogs and so that clients do not have to know anything about the server or where the data is on the server.

Generally a MSGBOX call just results in a system call to Windows to display a message box. Unless you set your system up to use custom message boxes.

Is your 'MX' system parameter ON? If so are you using the default custom message box (*ext/system/msgbox.gui) or are you using a user-defined message box (*ext/msgbox.gui)?

My Windows is also 64-bit.

I tried PxPlus 2017 (V14) and I still do not see a delay.

Are you using WindX? If so what OS is the server running on?

I would suspect something to do with your setup as I am not seeing this issue here.

I just tested here with PxPlus 2018 (V15.00.0002) and all message boxes come up instantly. I can see no difference if there is a title or a default title.

I'm on Windows 10 Pro Version 1803.

The WindX Auto Download I mentioned is actually two features: one is what you already tried the dynamic download, the other is static download. I think static download is more helpful in your case as you could have all your images in a directory and in the sync.conf file specify you want that directory synced. Thus a client system would always have that directory downloaded the first time it connects. If you ever update any of the images or add new images all the clients will get updated the next time they connect.

If you still want to go the DLL route you have to be aware of how PxPlus deal with resource DLLs. oldimages.dll is an internal use DLL you can't open it up and add your own images to it. You would need to create your own DLL with your images and name it PLUSLIB.DLL and put it in the same directory as the pxplus.exe. PxPlus requires that the first resource DLL must be named PLUSLIB.DLL. You can have a second resource DLL and name it what you want but then you have to tell PxPlus about it via the INI file or the 'OPTION' mnemonic. This is documented here https://manual.pvxplus.com/?pluslib1/sect1.1/c.htm

The PNG image format is a compressed image format. This means it is already compressed and putting it in a zip file will give you very little extra compression. I just did a test here and a 349kb png zipped to a 329kb.

Your best option is probably to take advantage of the WindX auto download feature have the the system automatically copy the images to the client system for you and not worry about compression as the images are already compressed.

Details on the auto download feature can be found here https://manual.pvxplus.com/?windx/autoload.htm

A new feature introduced in a Windows 10 update is Windows Subsystem for Linux (WSL). WSL lets users run a Linux environment directly on Windows without the need of a virtual machine. A few different Linux distributions are currently supported: Ubuntu, Debian, openSUSE, SUSE Enterprise, and Kali.

PxPlus will install on WSL but it will not function 100% correctly. The problem is that WSL is not a complete Linux environment and does not support all of the necessary OS functions needed by PxPlus (https://github.com/MicrosoftDocs/WSL/blob/live/LTP_Results/15014/Syscalls.txt). In particular, PxPlus is not able to do file or record locking when running under WSL. That being said, it is possible to run PxPlus on WSL if you are only trying to do some basic testing with a single user.

According to Microsoft, the WSL is designed with the purpose of running Linux command line tools directly on Windows. It was not designed to be a full Linux environment and run all Linux applications or any production applications (https://docs.microsoft.com/en-us/windows/wsl/faq#can-i-run-all-linux-apps-in-wsl).

I missed that you were not using Windx but RDP. What I suggested would only work if you are using WindX.

Mike is right that there is no easy way to get the client time when everything is running on the server except the RDP client.

I would check the Windows firewall on that machine.

I would also look into the antivirus/internet security software that machine is running.

I hope that helps.

Have you tried:

EXECUTE "[WDX]dte(0:"%hz:%mz %P")"

or if the code also needs to run not on windx

EXECUTE "[LCL]dte(0:"%hz:%mz %P")"

If you are not getting an error and the eraseit argument is 1 then it should delete the files from the Outbox/new directory.

It erases the file here when I do a test with PxPlus 2018. Maybe there is something off with how you are calling *web/email. Can you include your line of code that does the call. Make sure to redact the username password for your smtp2go account. Also include what the value of any variables are.

Can you also try to copy the *web/email and *web/smtp programs from PxPlus 2018 to make sure it is not an issue that was already fixed, or a issue caused by in in-place upgrade, or an issue caused by custom changes.

All it does is after sending the end of message to the server it waits for a status response. If the status response is not an error and eraseit = 1 then it will delete the message.

I assume your call is not returning an error and errormesg$ does not contain an error message after the call.

I haven't tried this and don't know if it will work but have you tried specifying ftps:// and the port when using *web/ftp.

CALL "*web/ftp;receive", "ftps://vendorServer:990", user$, password$, 0, "someFile.ext", download_dir$, case$, result$

FTPS is just FTP+SSL and behind the scenes we use curl which supports FTPS so it may be as a simple as that. If that doesn't work likely we would need to update the utility to try to support it. In which case I recommend creating a wish list forum post so we can gauge interest.