PxPlus User Forum

Twitter Twitter Twitter

Recent Posts

Pages: 1 ... 8 9 [10]
91
Programming / Re: Error 114 recovery
« Last post by Devon Austen on January 16, 2024, 12:42:36 PM »
Did you also try the filxvlr2 program?
92
Programming / Re: Error 114 recovery
« Last post by michaelgreer on January 16, 2024, 12:29:43 PM »
Devon,

Already reviewed that.  Unfortunately I cannot open the file (throws error 114) so I cannot use KEYED LOAD.
93
Programming / Re: Error 114 recovery
« Last post by Devon Austen on January 16, 2024, 12:05:05 PM »
Check out this forum post form Tips and Tricks: https://forum1.pvxplus.com/index.php?topic=39.0

It details the best way to try to recover keyed files.
94
Programming / Error 114 recovery
« Last post by michaelgreer on January 16, 2024, 11:48:32 AM »
I have files which are showing error 114.  When I attempt to use *UFAR it complains about error 114 and won't proceed (I can check the file successfully).  Any insight on how to recover the data or fix the file is appreciated.
95
Language / Switching an existing extended ASCII based system to UTF8
« Last post by Arno de Greef on January 14, 2024, 09:51:37 AM »
Hello,

I'm new at UTF8 encoding.

My company uses an existing extended ASCII based system written in PxPlus. For the most part the system is still character based. The system is running on Linux and users logon using a terminal emulator. A smaler part of the system are Nomads panels running through WinDx. Our system does not have the 'U8' parameter set.

Up until now in the character based screens users have only been able to use the characters in the extended ASCII set. In the WinDx screens users can enter UTF8 characters, but all progams handle data as extended ASCII only. On a few occasions this results in unwanted results, but we have come to accept that. Now our users would like to be able to use a few more characters in a limited number of Nomads screens. We are not planning on UTF8 encoded data being used in character based screens. All in all I'm reading up on my UTF8.

On the internet I found articles explaining the US ASCII characters (ASCII 000 through to 127) remain the same in UTF8 however the extended ASCII characters and all other are encoded differently. From the PxPlus manual I understand when using UTF8 the 'U8' parameter should be set system wide. Switching the parameter on and off where needed will probably have unwanted results. This makes me wonder what the impact of switching this parameter on system wide will have on existing programs and data.

For a test I set the 'U8' paramater to include returning an error in case of incorrect UTF8 data (value 2). After that test I ran the *UPB utility (string search and replace), resulting in quite a few errors. Something similar happened when interpreting the value of a FID function.

As another test I ran this bit of code :
a$=$C38AC38A$
for b$ from a$
print b$
next b$
With the 'U8' parameter set I expected the program to interpret the value of a$ as UTF8 and use $C38A$ as the separator returning two empty lines. The porgram however used $8A$ as separator returning a repesentation of $C3$ twice. This tells me non US ASCII characters will no longer be suitable separators in strings where UTF8 characters might appear.

These examples got me a bit worried we might me missing something.
For example :
- do we need to convert all data in our database to UTF8 ?
- could input statements start returning extended ASCII characters encoded differently than before ?
- will existing programs struggle finding extended ASCII characters in strings if they by mistake turn out to contain UTF8 content ? (return the position of that character if it's part of an UTF8 character)

All thoughts are very welcome !

Cheers,
Arno de Greef
96
Language / Re: Error 17
« Last post by Jeffrey Ferreira on January 11, 2024, 09:29:39 AM »
Hi Again,
sorry - i misread licensing.
they dont have multi image support activated.
jeff
97
Language / Re: Error 17
« Last post by Jeffrey Ferreira on January 11, 2024, 07:48:34 AM »
Hi James,
i have not tried it yet.i thought with the multiple image format extension i could use the other formats. but i will give that a try.
thanks
jeff
98
Language / Re: Error 17
« Last post by James Zukowski on January 10, 2024, 05:56:19 PM »
Have you tried a BMP?
99
Language / Error 17
« Last post by Jeffrey Ferreira on January 10, 2024, 03:07:10 PM »
Hi List,

we have a grid that displays images for the different options a customer can pickup.
i'm trying to set the 'bitmap$ option and i'm getting an error 17
it is an older version of pxplus (15.##)
does anyone know what would cause this
i tried a jpg and a png file and i get same error

jeff
100
Programming / Re: From It run program - debug window too short
« Last post by Mike King on January 09, 2024, 11:56:05 AM »
When you run a program from within IT using F7, the menu Debug >> Debug current program, or the menu option Run >> PxPlus the system will spawn a new instance of PxPlus using the default window size.  The default consists of an 80x25 window inside a window frame container whose dimensions is set in your INI file in the [WindowFrame] section.

Generally I suggest that you override these by providing a START_UP program that sets whatever you want as a minimum window size by calling *cmd/system/wdw and passing the size desired as WWxHH (e.g. "100x30").  This will create the base window the size desired, however you will still need to adjust the outer frame size to suit your needs.

You could also try adding the following commands to your START_UP:

CALL "*cmd/system/wdw", "100x30"  ! Or whatever your desired minimum cols/lines might be
CALL "*cmd/system/wdw", "zoom auto"


This will tell the system to create a 100x30 window then adjust the font size so you end up with the desired window size (in terms of columns/lines) within the frame and to tweak the frame size to match the window size.  The auto option enables tracking any frame size adjustments made by the user and have the system adjust the font accordingly.
Pages: 1 ... 8 9 [10]