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.
16
Programming / Re: Create an Excel file in Linux environment
« on: August 10, 2023, 08:00:34 PM »
Mike, that's interesting! I didn't know about this ZIP read/write, and that could be very useful for my XLSX routine. Currently, I need to create each XML file, then use a Linux utility to zip the directory and subdirectories. But, that relies on an external Linux zip app, and some clients don't have a zip app installed, so the creation fails. Using a PXPlus internal zip utility would resolve that issue!
Thanks for this info, Mike :-)
Thanks for this info, Mike :-)
17
Programming / Re: Create an Excel file in Linux environment
« on: August 10, 2023, 08:59:41 AM »
I've done exactly what you ask, using PXPlus only, on a Linux server, because we wanted a solution with no external dependencies. It was quite a bit of work, but definitely possible if you're familiar with using XML in PXPlus. The 'ah-ha' moment for me was when I discovered that an XLSX file is actually just a ZIP file - You can just change the extension to .ZIP, then unzip it to see all of the included files and directory structure. Once you see the structure of the zip file, you'll realize that it's just a matter of building all of the individual directories/files and the links between them. The routine I have does a fairly basic XLSX file for outputting reports to Excel, so it will set the cell type (numeric, text, date, image, etc.), cell width, font, bold, include images, and a few other minor things that I've long since forgotten. It's possible to add other features like formulas, but our clients don't really have a need for that - they just want to be able to see the reports in a true XLSX format, and then they can massage the data however they choose using a full-featured Excel editor. The spec that I used is a PDF document named "c061750_ISO_IEC_29500-1_2012.pdf", which you can find on the Web by searching for that filename. That's an older version based on Office 2008, I believe, but we are still using it extensively and our clients love it. There are newer versions of the spec, but there aren't significant changes for the basic stuff that we are using, so I haven't updated our routines. If you can't find a copy of the spec, let me know and I can email it to you. The spec includes all office documents (Word files, Excel files, etc), and Excel documents are referred to as "SpreadsheetML". The documentation is huge, but necessary for some pre-defined values (like the values necessary to define a cell type). But, most of the coding I did in PXPlus was done by opening the various files/directories in the ZIP file and re-creating their structure using PXPlus programs.
18
Language / Re: ** DISEGARD ** -> Mixed Case in Keys
« on: August 03, 2023, 12:21:51 PM »
You could probably use I/O logic on the data file to read using uppercase. Then, you wouldn't need to change all of the reads in various programs.
19
Nomads / Re: Unexpected Preinput on Panel Exit
« on: May 08, 2023, 05:18:17 PM »
Ah-ha! Glad you found it. It all makes perfect sense now :-)
20
Nomads / Re: Unexpected Preinput on Panel Exit
« on: May 08, 2023, 03:32:46 PM »
Try changing the hot key to another letter (like "E") and see if the behavior changes. Also try assigning the ALT-X hotkey to a different button, and see if the problem persists. That should tell you if it's a problem with the specific control or something else. It's a long shopt, but possibly someone defined a $CTL function to that hot-key combination somehow.
21
Language / Re: Detecting Multi-Segment Split File
« on: January 27, 2023, 06:34:53 PM »
You can get the number of segments from the file header, as long as it's not an EFF file.
OPEN INPUT(1,ISZ=1)"MY_FILE";READ RECORD(1,SIZ=256)R$;CLOSE(1)
SEGMENTS=DEC($00$+MID(R$,249,1))
PRINT SEGMENTS
OPEN INPUT(1,ISZ=1)"MY_FILE";READ RECORD(1,SIZ=256)R$;CLOSE(1)
SEGMENTS=DEC($00$+MID(R$,249,1))
PRINT SEGMENTS
22
Programming / Re: Anyone using webhooks?
« on: January 12, 2023, 09:57:28 AM »
No, we haven't done anything with this yet. It's simple enough to write a webhook receiver in PXP, but managing the firewall is generally outside of our purview for most of our clients, so it becomes more of a hassle than it is worth. We do have more clients wanting to use webhooks, though, so I might just need to sit down and create a receiver one of these days.
23
Programming / Re: Max variables in a program
« on: November 10, 2022, 10:07:29 AM »
There's a limit of 32000 bytes to the variable space. Refer to this thread: https://forum1.pvxplus.com/index.php?topic=887.msg2983#msg2983
Here's how I check it:
LOAD “My_Program”
OPEN INPUT (UNT,ISZ=-1)PGN; READ RECORD (LFO,SIZ=256)r$; CLOSE (LFO); PRINT DEC(MID(r$,101,4))-DEC(MID(r$,105,4))
Here's how I check it:
LOAD “My_Program”
OPEN INPUT (UNT,ISZ=-1)PGN; READ RECORD (LFO,SIZ=256)r$; CLOSE (LFO); PRINT DEC(MID(r$,101,4))-DEC(MID(r$,105,4))
24
Nomads / Re: Message/Status Bar Updates
« on: November 03, 2022, 01:47:05 AM »
James,
Maybe try just using a segmented status bar. That's an often forgotten feature that actually works very well, and has a nice appearance also. The message from the panel definition will always be in segment 1, and you can put your message in segment 2. You can re-define the status bar while your routine is running, then reset it when the routine is complete. Doing this would allow your routine to display a status message without requiring you to modify all of your controls that have a message.
For example, assume you have a panel with a width of 40. This will define 2 segments (each with a width of 20) in the status bar, and print your message in the second segment. At the end, it resets the status bar to a single segment. Note that the second argument of the 'MESSAGE' mnemonic specifies the segment where the message should be printed.
PRINT 'MESSAGE'(DEF 20,20),; WAIT 0
FOR i=1 TO 10; PRINT 'MESSAGE'("this is test "+STR(i),2); WAIT 1; NEXT
PRINT 'MESSAGE'(DEF 0)
https://manual.pvxplus.com/PXPLUS/mnemonics/message.htm
Maybe try just using a segmented status bar. That's an often forgotten feature that actually works very well, and has a nice appearance also. The message from the panel definition will always be in segment 1, and you can put your message in segment 2. You can re-define the status bar while your routine is running, then reset it when the routine is complete. Doing this would allow your routine to display a status message without requiring you to modify all of your controls that have a message.
For example, assume you have a panel with a width of 40. This will define 2 segments (each with a width of 20) in the status bar, and print your message in the second segment. At the end, it resets the status bar to a single segment. Note that the second argument of the 'MESSAGE' mnemonic specifies the segment where the message should be printed.
PRINT 'MESSAGE'(DEF 20,20),; WAIT 0
FOR i=1 TO 10; PRINT 'MESSAGE'("this is test "+STR(i),2); WAIT 1; NEXT
PRINT 'MESSAGE'(DEF 0)
https://manual.pvxplus.com/PXPLUS/mnemonics/message.htm
25
Nomads / Re: Message/Status Bar Updates
« on: November 02, 2022, 04:34:08 PM »
Try moving the focus off of the button 'Export to Excel' button while the process is running (just pressing 'tab' should move the focus elsewhere). I've seen this in some of my panels where the messagebar just keeps holding the message that is setup on the User Aid tab.
Also, try adding a WAIT 0 after you set the message to be displayed. That forces the system to do any screen updates that might be waiting out there.
Also, try adding a WAIT 0 after you set the message to be displayed. That forces the system to do any screen updates that might be waiting out there.
26
Programming / Anyone using webhooks?
« on: October 21, 2022, 02:50:29 PM »
With so many web services using webhooks now, it's getting harder to work with some services without being able to receive the webhooks. Our PXPlus application servers are behind firewalls, and we don't really want to open up ports to receive the webhooks, or manage an entire Apache server outside the firewall instance just to receive the webhook files. We don't need to send webhooks - we just need to receive and store them. I thought about writing a simple receiver (based on the nthost processor) or using EZWeb, but either option probably wouldn't handle the volume of some web API's, and we'd still need to open up ports in the firewall. I started looking into other services to handle this, and have found several apps that will just act as a webhook receiver (for example, Hookdeck).
Anyone out there have any experience/ideas/suggestions for receiving webhooks? I'd appreciate any info you can share before I'm forced to re-invent the wheel!
Anyone out there have any experience/ideas/suggestions for receiving webhooks? I'd appreciate any info you can share before I'm forced to re-invent the wheel!
27
Programming / Re: Critical/Reproduceable crash specific to PXP version 16.2 when creating JSON
« on: September 24, 2022, 10:10:44 PM »
It's several different OS versions. I just tested 4 clients again, and checked their system-release file, and they were all different.
CentOS release 6.8 (Final)
Red Hat Enterprise Linux Server release 6.10 (Santiago)
CentOS release 6.3 (Final)
CentOS Linux release 7.9.2009 (Core)
CentOS release 6.8 (Final)
Red Hat Enterprise Linux Server release 6.10 (Santiago)
CentOS release 6.3 (Final)
CentOS Linux release 7.9.2009 (Core)
28
Programming / Re: Critical/Reproduceable crash specific to PXP version 16.2 when creating JSON
« on: September 24, 2022, 02:21:31 PM »
Thanks for testing this, Mike!
I just tried it on four other clients using 16.2, and all had the same issue, so there's apparently something wrong with our installation package. We may need to rebuild our install package with the latest download of 16.2, but upgrading to a newer version is a lot simpler.
I just tried it on four other clients using 16.2, and all had the same issue, so there's apparently something wrong with our installation package. We may need to rebuild our install package with the latest download of 16.2, but upgrading to a newer version is a lot simpler.
29
Programming / Critical/Reproduceable crash specific to PXP version 16.2 when creating JSON
« on: September 23, 2022, 08:49:47 PM »
The following code will instantly crash (end the session) on all of our installations of PXP version 16.2. The session will die at line 20.
We use similar logic extensively on every other version of PXP, from version 11 through 17. The code even works correctly on PXP Version 16.1. The problem is specific to version 16.2, and is somehow related to the "WITH NUM" functionality. (Removing the WITH NUM functionality allows the code to execute successfully).
We're looking into upgrading our clients that are currently using PXP 16.2, since JSON is used extensively with our web integrations. However, if there is an easier solution, I'd love to hear it!
Also, I'd be curious if anyone with access to an installation of PXP 16.2 could test this code, so that we can determine if it's something specific to our installation routines. Our installations are all on Linux servers, generally Centos or RedHat.
Thanks in advance for any suggestions or feedback!
Code: [Select]
0010 LET ja$["id"]="123",withnum$="id"
0020 LET json$=DIM(LIST EDIT ja${ALL} WITH NUM(withnum$))
We use similar logic extensively on every other version of PXP, from version 11 through 17. The code even works correctly on PXP Version 16.1. The problem is specific to version 16.2, and is somehow related to the "WITH NUM" functionality. (Removing the WITH NUM functionality allows the code to execute successfully).
We're looking into upgrading our clients that are currently using PXP 16.2, since JSON is used extensively with our web integrations. However, if there is an easier solution, I'd love to hear it!
Also, I'd be curious if anyone with access to an installation of PXP 16.2 could test this code, so that we can determine if it's something specific to our installation routines. Our installations are all on Linux servers, generally Centos or RedHat.
Thanks in advance for any suggestions or feedback!
30
Programming / Re: Transform pdf to base 64
« on: August 24, 2022, 02:04:28 PM »
Try removing all of the line feeds from the Base64 string before adding it to the JSON, so that the base64 data is nothing but one long string of data. Some newer languages JSON parsers don't really care if the base64 is broken up into short lines. Since you're sending it via JSON, I'm assuming the receiving end is using some sort of modern parser that may not need the line feeds.