Generally internal errors being reported by objects or subprograms should be cascaded back to the user application.

I suspect that the json object is making some form of internal call that itself is returning an error that is not being properly cascaded back to your application.  This means if the 'NE' system parameter is set your application will fail with an error inside the object.

Normally when creating an object for which you anticipate returning an error from, if you need to invoke another method, object or subprogram that can return an error, you should explicitly provide an error trap that itself invokes an EXIT ERR.  This should allow the error condition to be passed back to your application regardless of the setting of 'NE'.

For Example:

Method1:
  ENTER A$,B$
  X$=_obj'SubMethod(A$, ERR=CascadeErr)
  ...
CascadeErr:
  EXIT ERR

Hi Martin,

The error 11 was meant to be a hard error, but you can use something like a try-catch to handle values not being found. Alternatively, you may have better use with the no_validation flag, since you can just compare the return value.

DOM=*next is meant for use with indexed data, but with associative arrays, and hence JSON, we store data as key-value pairs, which are not indexable. There are JSON Object functions that actually allow you to index it, but it should be avoided.

Like Mike mentioned; depending on what you are doing you could alternatively disable the 'NE' parameter.

Do you enable the 'NE' system parameter? 

The problem you are having sounds a lot like the error is being generated in the object and it may be assuming that the error will be cascaded back up the stack which it would be if the 'NE' parameter is not enabled.

Issue resolved. Ignore post.

I have just started receiving error 100 when I attempt to run certain programs. The error appears when the program attempts to 'Process' a panel.

Some of the programs work perfectly while others fail. This just started today. The failing programs have been around for a number of years with no issues.

Side note: I moved PvxPlus to a new Windows machine last Tuesday and everything seemed fine until today.  Also, all panels are contained in the same source file.

Any help would be greatly appreciated.

Tom Anderson

I'm still genuinely concerned about this using the GET_STR$(X$)  and it erroring within pvx code (json.pvc) if the string is not found unless I use GET_STR$(X$,1) vs just GET_STR$(X$) ?

PxPlus 2025 Update 1 (v22.10) is now available.  This update includes a number of enhancements and minor corrections.

The full list of enhancements can be viewed at https://home.pvxplus.com/release-info.htm

Product downloads available at https://home.pvxplus.com/downloads.htm

i everyone,

I wanted to reach out to see if my background might be a good fit for any ongoing or upcoming projects. I have 20+ years of experience in ProvideX (PxPlus) development, legacy system maintenance, and building tools that improve workflow efficiency and decision-making.

I'm comfortable working across development, debugging, QA, and support — and I enjoy helping teams modernize existing systems while keeping the business logic intact.

If you're looking for someone with deep ProvideX/PxPlus experience — or know someone who is — feel free to connect with me:
📧 osh@phxrsng.net

🔗 linkedin.com/in/odell-hathaway-4a6232b

There is a property called SCALE=

It is mentioned in the documentation here: https://manual.pvxplus.com?directives/winprt_setup.htm

So if you want to set the property you could do something like

winprt_setup read properties P$
P$+="; SCALE=65"
winprt_setup write properties P$

This will read the current properties and add SCALE=65 where the 65 is 65%.

Hello everybody,
I want to scale a printout to 65%. The winprt_setup reap prop$ instruction doesn't show a property that allow this. Does anyone have an idea on how to achieve this? Thanks a lot!