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.
871
Programming / Re: Automatically email a report from Report Writer
« on: September 27, 2018, 12:30:42 PM »
Documentation for *web/email like the report writer and other PxPlus utilities can be found at https://manual.pvxplus.com
The specific link for *web/email is https://manual.pvxplus.com/page/Web%20Utilities/Email%20Utility/Overview.htm
The specific link for *web/email is https://manual.pvxplus.com/page/Web%20Utilities/Email%20Utility/Overview.htm
872
Programming / Re: Automatically email a report from Report Writer
« on: September 27, 2018, 11:58:56 AM »
How do you want the report presented as HTML or PDF?
Regardless of which you use the easiest solution would be to create the report using a call to *rpt/runreport;Run_Call to create the PDF or HTML file then call *web/email to send the file as an attachment.
Regardless of which you use the easiest solution would be to create the report using a call to *rpt/runreport;Run_Call to create the PDF or HTML file then call *web/email to send the file as an attachment.
873
Language / Re: Outdated documentation *web/cookie
« on: September 21, 2018, 05:34:50 PM »
Thank you for bringing this to our attention.
We will have the documentation updated and the program adjusted to make the secure parameter optional in the next update.
We will have the documentation updated and the program adjusted to make the secure parameter optional in the next update.
874
Programming / Re: client time
« on: September 20, 2018, 12:38:48 PM »
A quick scan of the internet turned up the following link which may be of help to you:
https://serverfault.com/questions/634260/set-user-time-zone-by-gpo-on-windows-server-2012
It looks like you can configure the server to logically change the time for the session running on the host to that of the workstation (or at least that is how I interpreted this).
Of course now the problem may be for you to get the time zone of the host
https://serverfault.com/questions/634260/set-user-time-zone-by-gpo-on-windows-server-2012
It looks like you can configure the server to logically change the time for the session running on the host to that of the workstation (or at least that is how I interpreted this).
Of course now the problem may be for you to get the time zone of the host
875
Programming / Re: client time
« on: September 20, 2018, 09:18:59 AM »
Since you are using RDP and not WindX I don't know of anyway to find the users true workstation time zone. When you connect using RDP the processes all run on your server and all the workstation does is handle display/input. There is no real way to run anything locally to determine the time zone.
Now there may be an Windows API you could call in the windows WTS library ( https://docs.microsoft.com/en-us/windows/desktop/api/Wtsapi32/ ) but I did a quick look and couldn't see anything that would provide you what you are looking for.
Now there may be an Windows API you could call in the windows WTS library ( https://docs.microsoft.com/en-us/windows/desktop/api/Wtsapi32/ ) but I did a quick look and couldn't see anything that would provide you what you are looking for.
876
Programming / Re: *web/email is very slow
« on: September 20, 2018, 09:09:35 AM »
What I might suggest is try passing an smtp server an invalid userid/password and time how long it takes for the error to be returned. This will allow you to get a feel as to if the system is taking a long time generate your email for sending or if the smtp server is taking a long to process it.
Generally a bad userid/password should disconnect quickly so if this time is fast but with a valid userid/password it likely the mail server itself is slow.
Also if you have a different mail server (perhaps a gmail account or your own in-house server) I would try that as a test to see if that is faster so you determine where the issue may be.
Generally a bad userid/password should disconnect quickly so if this time is fast but with a valid userid/password it likely the mail server itself is slow.
Also if you have a different mail server (perhaps a gmail account or your own in-house server) I would try that as a test to see if that is faster so you determine where the issue may be.
877
Programming / Re: Windx cannot find Server
« on: September 20, 2018, 09:03:30 AM »
How is the user connecting to the Linux server (Simple CS, SSH, Telnet, App Server, NtSlave)?
This error indicates the user started WindX but did not successfully run PxPlus within the first few minutes in order to obtain the license. If they are using Telnet or SSH this can happen if once they connect they take their time starting PxPlus. It can also happen also when using SSH or Telnet on very slow machines or connections if once the terminal type is set to ANSI.
Generally for WindX you should set the terminal type to "winterm" however we do have logic in the Ansi terminal driver to try and detect if the workstation really is WindX. This is done by sending a message to the terminal to which only WindX will respond. If the expected response is not received then we assume the terminal is truly and ANSI terminal.
This error indicates the user started WindX but did not successfully run PxPlus within the first few minutes in order to obtain the license. If they are using Telnet or SSH this can happen if once they connect they take their time starting PxPlus. It can also happen also when using SSH or Telnet on very slow machines or connections if once the terminal type is set to ANSI.
Generally for WindX you should set the terminal type to "winterm" however we do have logic in the Ansi terminal driver to try and detect if the workstation really is WindX. This is done by sending a message to the terminal to which only WindX will respond. If the expected response is not received then we assume the terminal is truly and ANSI terminal.
878
Thin Client/WindX / Re: Remote Process Control
« on: September 19, 2018, 01:51:42 PM »
On Windows you could install it as a service then the user can use the standard windows service manager to control it.
For Linux/Unix you could use INITTAB to start the process.
BTW: In general if you just want to run a program on the remote machine you could use Apache or *EZWEB and the CALL "[http:...]" capabilities of PxPlus. This will provide similar functionality while also allowing you to have Web access to the remote machine.
For Linux/Unix you could use INITTAB to start the process.
BTW: In general if you just want to run a program on the remote machine you could use Apache or *EZWEB and the CALL "[http:...]" capabilities of PxPlus. This will provide similar functionality while also allowing you to have Web access to the remote machine.
879
Programming / Re: *web/email is very slow
« on: September 19, 2018, 09:04:05 AM »
While it might be *web/email, this program has been out for years and this is the first report of anybody encountering slowness.
Perhaps its related to the email/smtp server you are connecting to?
Often web sites do what is called 'Tarpitting' which is they intentionally slow down email submission to help reduce spam. If a mail server ran at full speed a spammer could send hundred of thousands of emails a minute, whereas if each email waits 1-2 second before acceptance then the most you send is 30-60 per minute with minimal impact to the end-users,
Another thing that may slow up email is if the email server is checking the in/outbound addresses. I know our mail server does -- that is both sender and receiver email addresses are pre-validated to see if the server can determine if they exist. It also does a spam check both on the inbound server (to see if its blacklisted) and runs the email contents through a spam/anti-virus filter. These checks all take time -- more for larger emails.
Perhaps its related to the email/smtp server you are connecting to?
Often web sites do what is called 'Tarpitting' which is they intentionally slow down email submission to help reduce spam. If a mail server ran at full speed a spammer could send hundred of thousands of emails a minute, whereas if each email waits 1-2 second before acceptance then the most you send is 30-60 per minute with minimal impact to the end-users,
Another thing that may slow up email is if the email server is checking the in/outbound addresses. I know our mail server does -- that is both sender and receiver email addresses are pre-validated to see if the server can determine if they exist. It also does a spam check both on the inbound server (to see if its blacklisted) and runs the email contents through a spam/anti-virus filter. These checks all take time -- more for larger emails.
880
Wish List / Re: Non-Wildcard Search in Documentation
« on: September 18, 2018, 10:37:22 AM »
Unfortunately no -- not for a web site search, at least not that we have found.
The search we provide (FreeFind), Google, Bing, Yahoo, Ask, even DuckDuckGo don't have any means to search for a string containing an asterisk within a web-site.
The search we provide (FreeFind), Google, Bing, Yahoo, Ask, even DuckDuckGo don't have any means to search for a string containing an asterisk within a web-site.
881
Wish List / Re: Non-Wildcard Search in Documentation
« on: September 17, 2018, 07:05:52 PM »
Unfortunately there is no web search engine that will do this. Generally search engines read web sites and pull out individual words and save these. Special characters, and in particular the asterisk, are generally not considered or maintained in the search results.
We have not found any Web Search tool that allows for the searching of an asterisk.
We have not found any Web Search tool that allows for the searching of an asterisk.
882
Wish List / Re: Designing panels using pixels as measurement
« on: September 17, 2018, 09:38:41 AM »
While its possible to use pixels when defining controls and thus would be possible to draw screen based on pixels, the original design of Nomads and in fact of PxPlus/ProvideX for graphical controls was to use a logical mapping of lines/columns to pixels.
When the product was first developed there was no scaling option with Windows. We recognized this fact and thus provided a means to scale panels simply by choosing a different text plane font size. This allows PxPlus applications to run on devices with different screen sizes and resolutions with the users simply having to select a different text plane font. This scaling mechanism works not only within the Windows environment but is used within iNomads to allow you adapt to different browser platforms and templates.
Another thing to consider is that generally application designers want their application to use the same font as Windows does for consistency. This causes problems when you use pixel addressing when Windows changes its core fonts which they have done a few times (MS Sans Serif, Tahoma, Segoe,...)
Currently you can draw/place controls with pixel resolution however these get saved as line and column coordinates (turn off the Nomads grid alignment and when placing using arrow keys hold the shift button down). Assuming the user selects the same text plane font the rendering should be consistent.
In theory we could redesign Nomads to store all positions/sizes by pixels but this would require new panel libraries and new tools/utilities and you would lose the core scaling functionality within PxPlus for both Windows and iNomads rendering.
NOTE: Designing screens and expecting to be able to control by Pixel long term is going to prove challenging should you plan to run on the Internet. Different browsers/platforms have different fonts and even different ways to display controls such as buttons and drop boxes resulting in different sized controls and text. You should try to avoid designing screens where pixel level accuracy is critical as these will often be problematic should you migrate your application to the Internet. (This is one reason you often see a lot of white/empty space on Web based application screen designs)
When the product was first developed there was no scaling option with Windows. We recognized this fact and thus provided a means to scale panels simply by choosing a different text plane font size. This allows PxPlus applications to run on devices with different screen sizes and resolutions with the users simply having to select a different text plane font. This scaling mechanism works not only within the Windows environment but is used within iNomads to allow you adapt to different browser platforms and templates.
Another thing to consider is that generally application designers want their application to use the same font as Windows does for consistency. This causes problems when you use pixel addressing when Windows changes its core fonts which they have done a few times (MS Sans Serif, Tahoma, Segoe,...)
Currently you can draw/place controls with pixel resolution however these get saved as line and column coordinates (turn off the Nomads grid alignment and when placing using arrow keys hold the shift button down). Assuming the user selects the same text plane font the rendering should be consistent.
In theory we could redesign Nomads to store all positions/sizes by pixels but this would require new panel libraries and new tools/utilities and you would lose the core scaling functionality within PxPlus for both Windows and iNomads rendering.
NOTE: Designing screens and expecting to be able to control by Pixel long term is going to prove challenging should you plan to run on the Internet. Different browsers/platforms have different fonts and even different ways to display controls such as buttons and drop boxes resulting in different sized controls and text. You should try to avoid designing screens where pixel level accuracy is critical as these will often be problematic should you migrate your application to the Internet. (This is one reason you often see a lot of white/empty space on Web based application screen designs)
883
Language / Re: PxPlus version for Server 2019
« on: September 14, 2018, 05:44:43 PM »
As is the case with all versions of PxPlus, we only test/validate the current version of PxPlus on current OS releases. We do not go back to change older releases of PxPlus to run on version of operating systems that come out AFTER the release of PxPlus.
About the only exception to this rule would be if a new OS release came out shortly after a release of PxPlus and it was causing problems on the then current release. If this was to happen we would consider releasing an update to the current version of PxPlus to deal with the newer OS version. The decision to do this would depend on the severity of the problem and the significance of the OS (number of users/clients using it -- Windows more likely than some obscure Linux version).
In recent memory I can only remember once where a new OS version caused us to update the then current release of PxPlus. That was with Windows Server 2016 and changes that were made to the permissions it assigned to the install directory. To resolve this issue we changed our installation routines and added some warning to the registration process -- but we ONLY made these change to the current release of PxPlus.
So to answer your question -- given Windows Server 2019 is due for release Q3-Q4 this year, we will test it with PxPlus 2019. The current schedule will allow us a few months to test PxPlus on it prior our release scheduled for May 2019.
Unless there is a MAJOR reason clients must update their system to Windows 2019 and a MAJOR issue running PxPlus 2018 on it, we don't have plans to test until then.
About the only exception to this rule would be if a new OS release came out shortly after a release of PxPlus and it was causing problems on the then current release. If this was to happen we would consider releasing an update to the current version of PxPlus to deal with the newer OS version. The decision to do this would depend on the severity of the problem and the significance of the OS (number of users/clients using it -- Windows more likely than some obscure Linux version).
In recent memory I can only remember once where a new OS version caused us to update the then current release of PxPlus. That was with Windows Server 2016 and changes that were made to the permissions it assigned to the install directory. To resolve this issue we changed our installation routines and added some warning to the registration process -- but we ONLY made these change to the current release of PxPlus.
So to answer your question -- given Windows Server 2019 is due for release Q3-Q4 this year, we will test it with PxPlus 2019. The current schedule will allow us a few months to test PxPlus on it prior our release scheduled for May 2019.
Unless there is a MAJOR reason clients must update their system to Windows 2019 and a MAJOR issue running PxPlus 2018 on it, we don't have plans to test until then.
884
Programming / Re: rpc dropping connection after dedicated point-to-point replaced.
« on: September 14, 2018, 12:09:22 PM »
The issue is likely your network is configured to drop connections after a period of no activity.
You may be able to resolve this by adding the option "KEEPALIVE" to the TCP definition on the PROCESS SERVER command used to connect.
You may be able to resolve this by adding the option "KEEPALIVE" to the TCP definition on the PROCESS SERVER command used to connect.
885
Programming / Re: Error 99 in *openlib on line 46
« on: September 14, 2018, 09:50:12 AM »
This type of error should be reported on our Help desk, however the problem is likely that the system does have the PxPlus extensions enabled.
Normally if PxPlus extensions are enabled you will see the following in the PKG output:
***** Separately Activated Packages *****
7587 PxPlus Enabled Expiry Date=none
Your output does not show this as enabled thus you don't have access to PxPlus extended capabilities.
Normally if PxPlus extensions are enabled you will see the following in the PKG output:
***** Separately Activated Packages *****
7587 PxPlus Enabled Expiry Date=none
Your output does not show this as enabled thus you don't have access to PxPlus extended capabilities.