PxPlus User Forum
Main Board => Discussions => Nomads => Topic started by: bbssupport on August 20, 2021, 02:17:10 AM
-
Hi All,
Has anyone that uses Nomads heavily started upgrading their user base to the new version 18 yet?
We have slowly started rolling out to our users and have noticed a couple of minor problems.
The first we can work around, but I thought i'd note it down here in case it was a bug that PxPlus wasn't aware of. The _QLST_DEF$[X,0] variables are now no longer populated with the original list box format when a panel is drawn (although the array is still defined). We were using this variable where a list box format is defined in nomads but then logic in our program alters the list box logic to add/remove/shrink/grow columns as required. We are working around this by setting the variable when the panel is first opened, or by reading the format out of the nomads library file. Not ideal but we can work around it.
The second is a strange issue that is seemingly randomly occurring since updating users to V18. We appear to have the word 'BLACK' being placed in string variables we are using to hold prices. These string variables and linked to multi lines on our nomads panels. I know prices should probably be stored in numeric variables but the string variables allow us to format the price as we see fit, allow our users to enter formulas etc in the pricing fields, and we just convert string variables to numeric variables when we need to perform calculations. We obviously have traps to ensure users can't enter letters in these sorts of fields, and yet somehow 'BLACK' is appearing in those variables and causing an error 26 in calculations. It is either the variable that is getting corrupt, or the multi line that is being populated with the value which is updating the variable but without triggering the on change logic (as if it was, the variable would be set back to "" and would return the user to the field to 'try again'.)
It's occurred three times this week in two different version 18 installations.
Error dump of error #1:
COST$="BLACK"+$00$+"0"
Error dump of error #2:
PRICE$="BLACK"
And the same for #3:
PRICE$="BLACK"
I can assure you that our code is not setting the word 'BLACK' anywhere! So far, I've yet to be able to replicate the issue on demand which makes it really hard to trace.
A couple of things to note.
1. We do use visual classes on all our controls, not sure if the problem is coming from there given that black is the default text colour.
2. All our cost and price fields are validated and formatted by a global function. (see below)
PROCESS_PRICE:
LET PRICE$=FN%PRCENT$(PRICE$,TAXRATE,%SELLPMASK$); IF PRICE$="ERR" THEN LET PRICE$="",NEXT_ID=PRICE.CTL; RETURN
RETURN
Our global functions haven't changed between versions 16 and 18 of PxPLus but maybe its possible that somehow the data being passed back from the function is getting corrupt?
Anyone else having any issues like this with the new version?
Chris
-
Chris
With regards to the two items you have mentioned:
- Using undocumented variables is never advisable as they are subject to change between releases. Internal variables, like _QLST_DEF$, are for internal use only. If we wanted to let you change these variables we would have documented them and provided consistency in their use between releases.
We constantly develop and enhance our products and that means we often need to change the usage of internal variables. Generally we try to keep these changes to a minimum, but changes do occur and for undocumented internal variables you need to be aware that they can change.
In particular it should be noted that with PxPlus 2021 we enhanced Nomads to allow more than 200 controls on a panel. To accomplish this we slightly modified the way the internal tables are handled since they were indexed by window number and control number. This is no longer the case when more than 200 controls exist on a panel.
As opposed to updating _QLST_DEF$ we would suggest you adjust the 'FMT$ property of the list in your post display logic.
- We have not had any reports of the wrong values being placed in variables with PxPlus 2021. We have, however, seen in the past where variable within a record get mapped incorrectly from the data record contents to the fields defined in an IOLIST when the field separator character is found within the actual contents of a field.
For example if you have say a product file where the product description occurs before the COST$ field; if the product description contains the field separator character then whatever field occurs before the COST$ field will end up in COST$.
This can happen if the data a user entered into the description contains the field separator character. For example if you make the description multiple lines high and the user enters a Line-feed and you are using $0a$ as you field separator, you will have this problem. The same would occur if you use the default $8A$ separator and the user enters a Š (which is fairly unlikely).
PxPlus default field separator is $8A$ which was used in the original implementation of Business Basic and while not ideal it has remained this way for compatibility purposes. Some other implementations of Business Basic over the year have switched to $0A$ or $0D$. While $8A$ is unlikely to occur in user text, it can happen. If we were starting from scratch today we probably wouldn't have selected $8A$ but rather a character in the $1C$ thru $1F$ range.
We would suggest you run scan you data file from where you get the COST$ variable to make sure the fields are in alignment and that no field separators are present within any text fields.
-
Hi Mike,
Thank you for the detailed reply.
1. Understood regarding using undocumented variables. We will keep this in mind in future. As I said, we have found a work around for this so it is no big deal.
2. I only wish it was that simple. We have been burned in the past with field separator character $8A$ sneaking its way into fields and now have internal procedures to ensure this doesn't happen (such as a routine that checks all multi lines in our nomads libraries that are more than 1 line high to ensure the line separator is not set to standard).
The first thing I checked when the errors started to occur was the product database records. All look correct, no fields out of alignment. Also, the user can process the same transaction again immediately after being broken out of the error and it goes through fine. This indicates that the problem isn't the data source.
We will continue to monitor the issue to see if we can find any other common denominators between occurrences.
Please let me know if any other users come across this issue when upgrading to V18 and we can possibly work together to find out where the problem lies.
Chris
-
Hi Mike,
We are now able to reproduce the issue under very specific circumstances within our software package.
We have a call program to print PDF files. In a specific module of ours, when this is called, the variable holding the name of a batch file (BAT$) to execute is being replaced with the word 'BLACK' when we execute "INVOKE HIDE BAT$"
If i place an ESCAPE above this line and ?BAT$ it returns the correct value. Typing RUN then allows the process to continue correctly. If I place MSGBOX BAT$ above the INVOKE HIDE line, it also reports the correct value and the process continues correctly. Without the ESCAPE or MSGBOX, it tries to INVOKE HIDE "BLACK" and we receive the attached message from Windows.
If we ESCAPE into the program at an earlier level, and issue a RELEASE to close the session, we receive a memory access violation message followed by an APPCRASH (also both attached). We have the crashdump if that is of use to you?
If I disable our visual themes by removing LET %NOMADS_THEME$="DEFAULT" from our startup program, the issue doesn't occur, indicating something to do with the memory management of themes...
There is definately memory management issues in the new version under certain circumstances which means we cannot roll it out to users until this is addressed. Who knows where else this issue could be occurring causing values to be displayed or written to the database incorrectly.
We also had strange issues occurring on version 16 after we enabled visual themes (not sure if you recall) where we ended up changing one of the programs where the issue occurred to a text program file instead of a compiled program file which seemed to get around that issue. It could be that these issues go back further that V18 but are now just more apparent in the new version.
Can you please advise what the next steps are to get this debugged and fixed?
Chris
-
Problems like this should be forwarded to our help desk so our support people can properly respond and track the issue.
They also will have details regarding the version of PxPlus, OS, and options enabled for your license which will assist in resolving this issue.
Lastly, the support department can make arrangements to supply you with a debug version of PxPlus that will allow us too better research the issue you are having.
-
Thanks Mike - My dealer has raised a support ticket on my behalf regarding the issue.