1. John Fauss
  2. PowerBuilder
  3. Thursday, 16 February 2023 04:16 AM UTC

Are there any documented restrictions or limitations on the use of global functions used in DataWindow expressions, where the global functions utilize non-visual objects (NVO's) and a DataStore?

Background:

I'm experimenting with global functions that analyze and encode string data to produce a variety of one-dimensional barcode styles (such as a UPC barcode) in a DataWindow, using TrueType barcode fonts. My goal is to be able to directly produce these barcodes in DataWindows utilizing these global functions in an expression contained within a computed field DWObject, eliminating the need to perform the necessary data encoding in a separate step in the application.

For most barcode styles, the data encoding steps are relatively simple. The steps can be coded in PowerScript within one or two global functions, and the computed field expressions work flawlessly to produce a barcode. However, GS1-128 barcodes are a different animal.

The GS1-128 barcode specification supports fields/records (called Application Identifiers, or AI's) within a single barcode. Each AI begins with a numeric prefix, followed by additional character and/or digit sequence(s). There are over 200 defined AI's, each with its own layout, so the parsing, validation, and encoding of GS1-128 data is considerably more complex than what is needed for other 1D-barcodes. I've created a DataStore for the AI definitions that has self-contained data (no data retrieval is needed) that is used in the data parsing and validation steps.

Problem:

Whenever a DataWindow expression that uses these GS1-128 barcode global functions is evaluated, PowerBuilder briefly hesitates, then goes POOF and terminates without any error messages. I suspect the DataWindow expression evaluator is blowing a gasket due to the creation and/or use of the pre-loaded DataStore, or the creation of the NVO's that contain the parsing, validation, and encoding logic, but at this stage that's only a guess on my part.

Question:

I realize these conditions are fairly unique. Has anyone ever successfully utilized a DataStore or other manually-instantiated non-visual objects in a global function that is referenced in a DataWindow expression? Any tips, suggestions or experiences are welcomed and appreciated.

John

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 16 February 2023 12:58 PM UTC
  2. PowerBuilder
  3. # 1

Hi John;

   GF's are typically not a problem when used in a DWO implementation. Even if they are called 100's of times. However, once you start adding instantiating various NVO objects, DWO result set handling, SDK calls, etc - this process can bog the App down for sure when repeatedly called as everything the GF does then gets destroyed upon exiting. 

   I've built lots of similar apps that use GF's for these type of intricate ) heavy processing needs. What I did to mitigate the GF's overhead was ...

  • Instantiate NVUO's using my STD Framework's "controller" as it stays memory resident all the time. Therefore, so does anything the Controller instantiates.
  • Create an "interface" method on the Controller that "brokers" access from the GF to the instantiated NVUO's that do the actual processing.
  • In the NVUO's (now that they became memory resident), I also handle DataStore (s) in the same memory resident way.
  • Where possible, I try to "cache" the DS's data to avoid repeated Retrieves.
  • In extreme processing cases, I also utilized PB's multi-threading features via the SharedIbjectXxxx commands. The NVUO's attached to the Controller were refactored to "broker" thread processing.

All in all, this architecture approach implemented very well for the apps that I built   HTH

Regards ... Chris 

Comment
  1. John Fauss
  2. Friday, 17 February 2023 03:06 AM UTC
Thank you for sharing your experiences and suggestions, Chris.

The app I've been toying with is eventually destined for CodeXchange - It's primary purpose is to illustrate how 1D-barcodes can be generated by using a TrueType font and some PowerScript code to perform the data encoding and checksum calculations for a healthy variety of common barcode styles, so I'm not anticipating there will be 1000's of barcodes being created and the potential performance issue(s) that could arise from that. Adding multitasking and a brokering interface is overkill in this particular instance, but I can see where that might be a solid approach for heavy-duty, "real-world" types of applications.

Given that PB currently goes kablooey (that's a highly technical software engineering term, by the way) with the current implementation, I'll refactor the GS1-128 barcode support and perform the data encoding from a window and then pass the encoded data and human-readable-text for each barcode into the DataWindow. On the plus side, this will show an alternative way to encode and display a 1D-barcode from the other barcode styles that have already been implemented.

I really appreciate you taking the time to share your suggestions... Thank you!
  1. Helpful 1
  1. Chris Pollach @Appeon
  2. Friday, 17 February 2023 03:27 AM UTC
Hi John;

That is sounds like a very "Kool" project App! All the best of luck with it. We'll be interested to see it in action. ;-)

Regards ... Chris
  1. Helpful
  1. Andreas Mykonios
  2. Friday, 17 February 2023 07:10 AM UTC
Hi John.

One thing that I like with your posts - comments it's that it isn't just about programming. :-)

Andreas.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.