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.
31
Thin Client/WindX / Re: winproc.rsz performance - increasing speed
« on: December 21, 2020, 12:33:27 PM »
Thanks Mike, for commenting. We are using the 'TU' turbo mode and I tried the new '+W' compression.
PS. I could prepare a video comparing the two performances if it would be of value.
PS. I could prepare a video comparing the two performances if it would be of value.
32
Thin Client/WindX / winproc.rsz performance - increasing speed
« on: December 21, 2020, 10:18:47 AM »
Hi, I am still noticing significant performance issues with the *winproc.rsz screen and *winproc. I've seen this issue in all the PVX routines since version 5 and it's never been addressed. In fact the performance is getting slower and slower as more features get added, which is both understandable but also concerning.
This is mostly due to having a panel that is resized on start up with the *winpnl functionality and an automatically 'maximized' window. (There are a few other routines in *winproc that can help as well)
Removing the GOSUB CHECK_MANUAL_MANIPULATION almost doubles the speed right away which is a great improvement (if you do not need that functionality)
If you are testing this on a local network you will not experience this as bad however its slightly visible.
On an internet connection it is very apparent (even a fast low latency connection).
With my panel example (Folder panel, automatically maximized via *winpnl)
Currently: pxplus has an 8 second delay.
Currently: pxplus with check_manual_manipulation removed: 4 seconds
Older PVX5.14: My screens at a snappy 2 second delay.
This is easily reproduced on the simple client server.
Thinking forward, perhaps I can eliminate the maximize feature and redraw the screen at a higher resolution however it would be nice if the response/packets could be improved. It's been many years and the problem is still there.
Thanks for your time.
This is mostly due to having a panel that is resized on start up with the *winpnl functionality and an automatically 'maximized' window. (There are a few other routines in *winproc that can help as well)
Removing the GOSUB CHECK_MANUAL_MANIPULATION almost doubles the speed right away which is a great improvement (if you do not need that functionality)
If you are testing this on a local network you will not experience this as bad however its slightly visible.
On an internet connection it is very apparent (even a fast low latency connection).
With my panel example (Folder panel, automatically maximized via *winpnl)
Currently: pxplus has an 8 second delay.
Currently: pxplus with check_manual_manipulation removed: 4 seconds
Older PVX5.14: My screens at a snappy 2 second delay.
This is easily reproduced on the simple client server.
Thinking forward, perhaps I can eliminate the maximize feature and redraw the screen at a higher resolution however it would be nice if the response/packets could be improved. It's been many years and the problem is still there.
Thanks for your time.
33
Programming / Re: Can't close window/dialogue (double clicking top-left box)
« on: December 14, 2020, 01:25:10 PM »
Thanks Devon!
34
Programming / Re: Can't close window/dialogue (double clicking top-left box)
« on: December 14, 2020, 09:34:34 AM »
Devon, Thanks for responding however, that was not the answer I was expecting. I've been using pvx for over 20 years. Sometimes I close the window that way. Please show me one windows application that cannot be closed in such a way?
Regarding efficiency, if my mouse is already on that side of the screen, then moving the mouse to the opposite side of the screen is less efficient.
Regarding efficiency, if my mouse is already on that side of the screen, then moving the mouse to the opposite side of the screen is less efficient.
35
Programming / Can't close window/dialogue (double clicking top-left box)
« on: December 13, 2020, 10:48:46 PM »
Hello, I'm testing pxplus 2020 v17.10 and I am seeing strange behaviour that was not in my older versions. Double clicking the top-LEFT box on the windows do not close the dialogue/window.
Works sometimes, most often not.
Simple example:
0010 BEGIN
0020 PRINT 'DIALOGUE'(1,1,20,10,"Test"),
0030 INPUT *
Tested both windows/linux, same behaviour with local and Simple client server. PC windows: win 10 pro - build 20H2
Thanks,
Martin
Works sometimes, most often not.
Simple example:
0010 BEGIN
0020 PRINT 'DIALOGUE'(1,1,20,10,"Test"),
0030 INPUT *
Tested both windows/linux, same behaviour with local and Simple client server. PC windows: win 10 pro - build 20H2
Thanks,
Martin
36
Programming / Am I the only one still using PVX 5.14? :)
« on: November 08, 2018, 09:36:32 AM »
Hey everyone! Am I the only one still using PVX 5.14? 
We do have one pvxplus license that we use as a web server but our main software still runs off 5.14... This version was so rock solid that it's still going strong after all these years..
I've been able to call into the pvxplus web server for PDF printing and we use ODBC for any SQL interfaces and haven't needed to upgrade after all this time.
We did not go the iNomads route but chose to develop straight HTML for the web client access, but our back-end still using pvx5.14
Anyone else on this platform?
We do have one pvxplus license that we use as a web server but our main software still runs off 5.14... This version was so rock solid that it's still going strong after all these years..
I've been able to call into the pvxplus web server for PDF printing and we use ODBC for any SQL interfaces and haven't needed to upgrade after all this time.
We did not go the iNomads route but chose to develop straight HTML for the web client access, but our back-end still using pvx5.14
Anyone else on this platform?
37
Off Topic / Re: Hi there!
« on: June 25, 2018, 10:53:39 AM »
What a great idea, thanks for setting this up!