PxPlus User Forum

Twitter Twitter Twitter

Recent Posts

Pages: [1] 2 3 ... 10
Language / Re: Error handler Object handling.
« Last post by Mike King on January 16, 2021, 08:49:59 PM »
The FOR PROGRAM lasts until the current program level (CALL, PERFORM, etc...) exits.  The Object does remain through lower levels so if the current level itself issues a CALL, PERFORM or executes a method call, the object will remain.  Basically the object remains until the current level issues an EXIT or END (or RETURN to a higher level - -not a GOSUB return)
Language / Re: Error handler Object handling.
« Last post by Peter.Higgins on January 15, 2021, 11:57:00 AM »
Thanks Mike,

Cannot believe something this important has been around for 15+ years and I am just now learning it even after taking 3 dedicated months to learn what I missed after going down the Sage & Infor fork rabbit holes.

"For Windows" is perfect for regular nomads programs.
"For Program" says "the current program level is exited." Does this mean the object only persists while on one level, or through higher level calls/methods?
Language / Re: Event handling
« Last post by Gilles on January 15, 2021, 10:40:56 AM »
Sure that helps
Thank you St├ęphane
Language / Re: Event handling
« Last post by St├ęphane Devouard on January 15, 2021, 03:35:21 AM »

You can find some additional information here :

Basically :
- You define an event to be generated using the PROCESS EVENT directive, assigning a name and a list of arguments that will be passed to the event handler logic
- You assign an event handler using the ON PROCESS EVENT, specifying the name of the event to be handled and the name of a handler routine to CALL or PERFORM (there is an enhancement planned to be able to use also an object's method but it's not yet available)
- Whenever the event is triggered (the PROCESS EVENT is executed), the associated event handler is called/performed and passed the defined arguments as parameters

You would usually define the event handlers somewhere in the initialization logic of your application
You insert the event triggers in strategic locations in your application logic

This simplifies how you handle critical logic in your app with software changes as well as software customization.

No need to do search and replaces of critical CALLs throughout your application when your rename and rework them, just change the assigned event handler in one place.

Also, it makes easier to customize certain aspects of your app. Imagine you have created a special invoice printing program for a few clients instead of the standard one.
In your app logic you just have a
PROCESS EVENT "PrintInvoice",invoice_num$
Wherever an invoice is supposed to be printed.

In your initialisation logic you'll have
ON PROCESS EVENT "PrintInvoice" CALL "invoice.pxp;print_std" for all clients
ON PROCESS EVENT "PrintInvoice" CALL "invoice.pxp;print_special" for a few clients
The program name could even be stored in some parameter file, or whatever solution you see fit

Hope that helps.
Language / Re: Error handler Object handling.
« Last post by Mike King on January 14, 2021, 08:22:20 PM »
Not certain exactly what you are looking for but have you considered just using the FOR clause on the NEW function when creating objects?

For Example:

myObj = NEW("object_name" FOR PROGRAM) ! Will drop object when program exits/end
myObj = NEW("object_name" FOR WINDOW) ! Will drop object when window closed
myObj = NEW("object_name" FOR FILE nnn) ! Will drop object when file nnn closed
myObj = NEW("object_name" FOR OBJECT nnn) ! Will drop object when secondary object nnn is dropped

Saves a lot of work remembering when to drop objects.
Language / Error handler Object handling.
« Last post by Peter.Higgins on January 14, 2021, 02:53:54 PM »
Looking to add an object manager to programs and the error handler so it can drop them.

At first I thought *master might work, but not in *nix from the results I get. 

I also was thinking there was a newish object manager utility to keep object references in, but all I can find that is useful is the *obj/collection.pvc which leaves a lot of coding to implement everywhere else.

Am I missing one somewhere?
Programming / Re: grid help fill up
« Last post by Peter.Higgins on January 14, 2021, 02:41:55 PM »

Grid are difficult, but a few concepts really help reduce the information overload.

The cell clicked on is not the row/column that will be updated.  row/column must changed to that location.

Row properties are numeric, but columns can be the column number, or the variable name. Variable names are more better as columns can be rearranged easily. 

Each grid method in windx goes out to the client and then back.  Get to know the "Pseudo Multi-Properties" or "Multi-Property Access" techniques to do as many of the changes in one shot.  These are usually pretty common so I use a grid utility object to process the majority of these.

Treat each line as a record rather than dealing with cells individually.  This is much simpler, just like we don't deal with just fields in file records.  See Load/Access by Row Grid Properties.  When the columns are rearranged, this keeps your head from exploding.

Grid Formats can be both set and obtained in the program so one grid can work with any file.  This is how I do logging displays.  I use the dictionary objects to build format strings, but the IOLists can be parsed, or Format strings for each put in the program, etc.  I would encourage you to learn this over using the nomads entry. It makes programs with grids much easier to reuse.   If a column should be hidden, set the width to zero so the format and record iolist remains constant.

The grid commands simplify most of the work.  Putting the records into one string and then a grid write of the whole list is quick and easy. 

To compare original records to grid changes, use a memory file to copy the records to first, then compare memory record to row record for real changes.

Do formatting and colors after loading data.  It is much more efficient.
Thin Client/WindX / Re: Client-side FID(0)
« Last post by James Zukowski on January 13, 2021, 11:08:29 AM »
It turns out this discussion may be moot. I've been trying to get the id from the task process list to change according to the fid(0) of the workstation connecting with SimpleCS. It finally 'clicked' that that's the id for the host, not the client.

Other options now under consideration. Thanks to all for the different insights.
Thin Client/WindX / Re: Client-side FID(0)
« Last post by James Zukowski on January 13, 2021, 10:00:56 AM »
If we were using a command-line shortcut, that would work fine. We're using .windx files, and it doesn't seem to fit in anywhere.  :(
Thin Client/WindX / Re: Client-side FID(0)
« Last post by Mike King on January 13, 2021, 09:33:15 AM »
Actually if you want to control FID(0) based on the workstation shortcut simply add -ID=XXX to the command line.

Pages: [1] 2 3 ... 10