PxPlus User Forum

Twitter Twitter Twitter

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bbssupport

Pages: [1] 2 3
Nomads / Re: Multi Line - On Double Click Event
« on: September 17, 2022, 12:44:00 AM »
Hi Mike,

PKG revealed that my license was still running at activation level 18.

Running *plus/reg/net appears to have upgraded the activation to level 19 and now i can see the OnDoubleClick property.

Thanks and sorry to waste your time!


Nomads / Re: Multi Line - On Double Click Event
« on: September 16, 2022, 12:45:27 AM »
HI Mike,

Thanks for that. I've downloaded v19.1 and cannot seem to get the OnDoubleClick property to accept a value for either manually created controls or controls created in nomads.

0020 MULTI_LINE MY_MULTILINE,@(50,5,10,1)

Results in an Err #88.

Image attached.

Have I missed something?

Nomads / Re: Multi Line - On Double Click Event
« on: September 08, 2022, 09:15:17 PM »
Wow Mike, that is amazing news.

Thank you heaps!

I'll keep a look out for Update 1!

Nomads / Re: Multi Line - On Double Click Event
« on: September 07, 2022, 12:31:34 AM »
Hi Mike,

I'm thinking about changing some of my multilines to behave like hotlinks currently do in list boxes.

For example, a locked multi-line that displays a customer code and name. The user can currently click and highlight to copy the text, and i was hoping to implement logic so if they double click it will take them to view more details about the customer (ie open a customer enquiry). This saves me having buttons everywhere for users to navigate to different areas when looking at a transaction.

Understand if it isn't possible with the options currently available, but thought i'd ask since you can acheive this in VB.

Nomads / Multi Line - On Double Click Event
« on: September 06, 2022, 07:33:41 PM »
Hi All,

Simple question that I think the answer is No but thought I'd ask.

Is there a way to set the attributes in such a way to fire the focus or on-change event when a multi-line control is double-clicked on?

I've tried IF POS($020D$:_EOM$)<>0  then MSGBOX "Test" in the on focus logic but it only executes when focus is first given to the control. On change doesn't appear to fire on a double click even when Auto and Signal on Exit are enabled.


Nomads / Spell Check TinyMCE
« on: October 21, 2021, 06:14:32 PM »
Hi All,

I cannot seem to get the TinyMCE spell check functionality working on v18.1 in nomads using the provided control. I'm using the standard built-in extended layout. Any ideas?

See attached.


Nomads / Re: Version 18 / 2021 Nomads
« on: August 25, 2021, 06:06:27 PM »
Thanks Mike - My dealer has raised a support ticket on my behalf regarding the issue.

Nomads / Re: Version 18 / 2021 Nomads
« on: August 24, 2021, 10:36:39 PM »
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?


Nomads / Re: Version 18 / 2021 Nomads
« on: August 20, 2021, 05:20:42 PM »
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.


Nomads / Version 18 / 2021 Nomads
« 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:

Error dump of error #2:

And the same for #3:

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)

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?


Language / Re: Error 49 in call program
« on: May 17, 2021, 09:18:30 PM »
Hi Mike,

Thanks for the reply.

We aren't using the external cache manager, only the system parameter 'PC'=100.

I doubt it is our Anti-Virus as it only appears to affect our Azure infrastructure and not other customers that use the same managed AV (Webroot).

I also don't beleive i'm calling any DLL's - especially not from the program in question.

Perhaps we just need to chalk this one up to computers being computers....

Language / Re: Error 49 in call program
« on: May 16, 2021, 11:10:48 PM »
For those of you playing at home - the issue seems to be resolved for the program in question by saving it as an ASCII program rather than a compiled program file.

Language / Error 49 in call program
« on: May 06, 2021, 08:32:28 PM »
Hi All,

Since implementing visual classes and themes across our application, we have been experiencing seemingly random error 49s in call programs. These happen a few times a day for users across our Server 2012 R2 Azure VMs running either PxPlus v16.2 or v17.0. Most commonly, the error occurs in a single program with the odd few errors occurring in other programs.

The main program in question would be executed tens of thousands of times a day as it is our 'standard program exit routine'.

The line of code in question that reports the error is 0110 IF TCB(12)>1 THEN EXIT.

The error details are:
Error Number        : 49
Error Description   : <*> Internal program format error <*>
Error Line          : 110
Programming Level   : 6
Program Path        : OUT             

We use SET_PARAM 'PC'=100 so i'm thinking it is related to the program cache somehow.

I'm unable to forcably replicate the error which is frustrating!

We recently had another issue where records read from data files were being corrupted in memory due to pending file writes to encrypted data files. PxPlus advise they have fixed this in the next release (due this month).

I'm thinking that the program cache is getting corrupted as well.

Has any one else experienced a similar problem to the one above? I'm starting to worry there may be other memory management issues that I haven't come across yet....


Programming / Re: Calendar on Multi-Line
« on: December 16, 2020, 01:46:44 PM »
Hi Jane,

Thank you, that's perfect. I can definately work with that and can even customize the panel to our needs.


Programming / Calendar on Multi-Line
« on: December 15, 2020, 09:09:45 PM »
Hi All,

We would like to be able to initiate the built in calendar pop up on multi-lines from within our own code. Is this possible?

The reason is that we use embedded query buttons that activate via the F2 key (not SHIFT-F2) and the built in calendar options in nomads only allow for the button to be external and don't initiate on an F2 like all our other queries do.

Thanks in advance.


Pages: [1] 2 3