1. Magicu-L | Main
  2. Topics

XPA3 combo-control: incompatibly with prior versions

Avgerinos
 

Hi magicians

Documenting an incompatibility in behavior of combo-box controls between XPA3.x v/s prior versions:

Desktop app form contains a combo-control, with bot ItemsList & DisplayList properties defined as expressions pointing to string variables.
If you try to reconstruct the content of these variables in XPA3 (maybe parsing some array that contains the names or values), an error will appear in the error log.
After you repeat for a while, the runtime-engine will eventually crash.

Same case in uniPaas behaves correctly for years. It creates no issue and does not affect stability.

The possible cause behind this:
Since 2 different variables are used as the source of ItemsList and DisplayList, and they are not updated simultaneously, XPA3-engine gets very "sensitive" the moment you update the first variable and still you did not have the time to update the second one to equal items-count. It sees an ItemsList v/s DisplayList length incompatibility and this is what it reports in error log.
Probably this creates a memory leak inside and eventually ends up in application crash.

Work-around that seems to work so far:
Use a parallel couple of variables to hold and update the ItemsList & DisplayList. Whenever they are both updated and ready, then update the primary variables with the final values

Regards
Avgerinos
Avgerinos
 

Correction: message refers to tab-control and not to combo-box

On 17/2/2017 8:45 πμ, Avgerinos wrote:
Hi magicians

Documenting an incompatibility in behavior of combo-box controls between XPA3.x v/s prior versions:

Desktop app form contains a combo-control, with bot ItemsList & DisplayList properties defined as expressions pointing to string variables.
If you try to reconstruct the content of these variables in XPA3 (maybe parsing some array that contains the names or values), an error will appear in the error log.
After you repeat for a while, the runtime-engine will eventually crash.

Same case in uniPaas behaves correctly for years. It creates no issue and does not affect stability.

The possible cause behind this:
Since 2 different variables are used as the source of ItemsList and DisplayList, and they are not updated simultaneously, XPA3-engine gets very "sensitive" the moment you update the first variable and still you did not have the time to update the second one to equal items-count. It sees an ItemsList v/s DisplayList length incompatibility and this is what it reports in error log.
Probably this creates a memory leak inside and eventually ends up in application crash.

Work-around that seems to work so far:
Use a parallel couple of variables to hold and update the ItemsList & DisplayList. Whenever they are both updated and ready, then update the primary variables with the final values

Regards
Avgerinos
Avgerinos
 

Suggested solution does work always
A better solution is to add a condition to temporarily "unlink" the string variables from the ItemsList and DisplayList properties while updating them.

On 17/2/2017 10:34 πμ, Avgerinos wrote:
Correction: message refers to tab-control and not to combo-box


On 17/2/2017 8:45 πμ, Avgerinos wrote:
Hi magicians

Documenting an incompatibility in behavior of combo-box controls between XPA3.x v/s prior versions:

Desktop app form contains a combo-control, with bot ItemsList & DisplayList properties defined as expressions pointing to string variables.
If you try to reconstruct the content of these variables in XPA3 (maybe parsing some array that contains the names or values), an error will appear in the error log.
After you repeat for a while, the runtime-engine will eventually crash.

Same case in uniPaas behaves correctly for years. It creates no issue and does not affect stability.

The possible cause behind this:
Since 2 different variables are used as the source of ItemsList and DisplayList, and they are not updated simultaneously, XPA3-engine gets very "sensitive" the moment you update the first variable and still you did not have the time to update the second one to equal items-count. It sees an ItemsList v/s DisplayList length incompatibility and this is what it reports in error log.
Probably this creates a memory leak inside and eventually ends up in application crash.

Work-around that seems to work so far:
Use a parallel couple of variables to hold and update the ItemsList & DisplayList. Whenever they are both updated and ready, then update the primary variables with the final values

Regards
Avgerinos
Heidi Schuppenhauer
 

Unfortunately it's not just an issue with combo boxes. Basically, back in the day we used expressions as a kind of a hack to do other things. Like, there would be an "invisible" property, which would have an expression with a VarSet to set some totally unrelated variable. Since we all knew when those expressions would be evaluated, this worked.

However, in the last subversion or so, the timing on when those expressions are evaluated, seems to have changed. So when the expression does something like "VarSet", the variables may or may not be in a place to accept the new value? I dunno what is going on internally. But the upshot is: a lot of those expressions now wreck havoc on memory.

The safe bet is to create a variable. Use Init or an Update to set the variable. THEN use the variable in the Control property. And never, ever, ever use a Varset in a control property! 

Of course keep in mind that by next service pack, this will all be history.

-----------

Another timing issue seems to be "stuff that happens in Task Prefix". In the past, supposedly nothing much happened in task prefix, so you shouldn't count on things being initialized. However, it did work, and a lot of people displayed data there. Nowadays it often does not work, and there is a lot of blank space that should not be blank. 

Once you get used to the new rules, it works fine.

1 - 4 of 4