Date   
Re: UniPaas V1.9e : Clients randomly blowing up with C++ error "Debug Assertion Failed!". "Buffer is too small"

Andy Jerison
 

UniPaas is written in C++. 


On Wed, Mar 28, 2018, 2:20 PM foxonstump via Groups.Io <foxonstump=aol.com@groups.io> wrote:
We have clients randomly blowing up with this error when running our application.



Has anyone ever seen it? In what capacity does UniPaas use C++?

Thanks,

Terry

UniPaas V1.9e : Clients randomly blowing up with C++ error "Debug Assertion Failed!". "Buffer is too small"

foxonstump@...
 

We have clients randomly blowing up with this error when running our application.



Has anyone ever seen it? In what capacity does UniPaas use C++?

Thanks,

Terry

Re: XPA3.2-Bug: When the only control on the screen is a checkbox, the Modifable and Allow Parking properties are ignored

Govert Schipper
 

Hi there,


It seems that you are right, very strange indeed. In previous version I remember that an error message would pop up if there was no control to park on and the task would exit.

On the other hand, changing the checkbox does not trigger the Variable Change or Control events, so nothing would happen (fortunately).


Govert




Van: BugReports@magicu-l.groups.io <BugReports@magicu-l.groups.io> namens foxonstump via Groups.Io <foxonstump@...>
Verzonden: dinsdag 20 maart 2018 14:13
Aan: BugReports@magicu-l.groups.io
Onderwerp: [BugReports] XPA3.2-Bug: When the only control on the screen is a checkbox, the Modifable and Allow Parking properties are ignored
 

We have a screen with only one control, a checkbox.   We would have this situation most commonly on a subform, but you can duplicate it in a stand alone program.

 

Create a new task with a Logical virtual, and put in on the screen as a checkbox   Change the Modifiable and/or Allow Parking properties to False.

Run the program.  You can park and change the checkbox variable.  If we had a Column variable behind the check box instead of a Virtual variable, you would actually be changing the data in the database (not good).

XPA3.2-Bug: When the only control on the screen is a checkbox, the Modifable and Allow Parking properties are ignored

foxonstump@...
 

We have a screen with only one control, a checkbox.   We would have this situation most commonly on a subform, but you can duplicate it in a stand alone program.

 

Create a new task with a Logical virtual, and put in on the screen as a checkbox   Change the Modifiable and/or Allow Parking properties to False.

Run the program.  You can park and change the checkbox variable.  If we had a Column variable behind the check box instead of a Virtual variable, you would actually be changing the data in the database (not good).

XPA3-bug: Mode property of Call-task operation inside functions

Avgerinos
 

Execution of a Call-task operation inside a function-unit depends on its Step/Combine Mode property, while Studio hides this property as non-applicable

How to reproduce:
In an online task, create a Control-Verification-unit and a Function-unit.
In the Control-Verification unit add a line with a Call SubTask operation and set it's Mode property to Step.
Copy this line (Ctrl+Shift+R) inside the Function unit
Note that the Mode property is now invisible. Still it's Step value is retained,plus it will be respected on runtime.  
Try to execute this function in Fast mode (e.g. when exiting the task): the subtask will never execute

How to fix:
Copy the line back to Verification-Unit, so that the property is visible.
Change the Mode property to Combined
Copy back to Function unit.
Notice how now it works.

The line containing the Call operation was not typed. Instead it was copied to the Function-section from the ControlVerification section.
In the ControlVerification-section the Call operation had the Mode attribute set to Step. When copying this line to a Function-section, XPA hides this Mode-attribute, so the user cannot see or edit it any more. Still it is obviously retaining the hidden Step value, and unfortunately during runtime it respects it.
The fix is to delete the line and to hand-type exactly the same. In this case XPA obviously set the the hidden Mode attribute to Combined

(This issue has been also reported to MSE problem-submission)

Re: xpa 3.2 SQL Server connection failed using Application Role authentication

e.kregting@...
 

On Thu, Feb 23, 2017 at 08:00 am, Avgerinos wrote:
%SQLDB

 Hi Avgerinos,

I'm a college off Heico,

We use SECRET NAMES for the connection to the database, not LOGICAL NAMES



In the ini we have: (Where the %% points tot the secretnames)

MAGICDATA = DBMS, 21, MAGICPROD, , SQL02\SQL2014PROD, %LOCKFILEPATH%, , +
, NoMagicRecordLock, DontChangeFileInToolkit, NoCheckDefinition, NoCheckKey+
, NoFileLocks, SQL_APPLICATION_ROLE = %SQL_APPLICATION_ROLE% SQL_APPLICATIO+
N_ROLE_PASSWORD= %SQL_APPLICATION_ROLE_PASSWORD%, , NoCheckExist, 0, , +
NoAS400SrvrSort,


And in the Database properties we have:



Re: xpa 3.2 SQL Server connection failed using Application Role authentication

Avgerinos
 

Hi Heico

I just tested the following setting in magic.ini:
TEST SQL Server = DBMS, 21, %SQLDB%, , %SRVNAME%, , %USR%, %PWD%, NoMagicRecordLock, ChangeFileInToolkit, CheckDefinition, NoCheckKey, NoFileLocks, SQL_PHYSICAL_LOCKING=Y, , CheckExist, 0, , NoAS400SrvrSort, , NoWebServiceDB,

I verify that all logical names were evaluated correctly in XPA3.2a
Maybe something in your INI messed up while transferring from XPA 3.1 to 3.2?

Regards
Avgerinos

On 21/2/2017 1:49 μμ, Heico van Wieringen via Groups.Io wrote:

Hi Avgerinos,


Thanks for your reply.

I tried what you suggested with Logical Names. Logical Names are not evaluated in my case. In xpa 3.1 they are. :(


Regards,

Heico

Re: xpa 3.2 SQL Server connection failed using Application Role authentication

Heico van Wieringen
 

Hi Avgerinos,


Thanks for your reply.

I tried what you suggested with Logical Names. Logical Names are not evaluated in my case. In xpa 3.1 they are. :(


Regards,

Heico

XPA3 issue with mouse-wheel

Avgerinos
 

Reposting from main group to the bug-reports group:
============================================

In XPA3.2a form (desktop app), a table-control will stop responding to mouse wheel, the moment it "stumbles" on a row where all contained controls are non-parkable. Rest of navigation methods will still work.
The issue appeared in XPA3.2 or 3.2a. It was not happening with UniPaaS 1.9 and with any XPA version up to 3.1b.

Workaround: either make one of the controls parkable (and protect by making it not-modifiable) or add a dummy fields that allows cursor to park

Regards
Avgerinos

Re: xpa 3.2 SQL Server connection failed using Application Role authentication

Avgerinos
 

Hi Heico

It would be useful if you re-post this message in the main magicu-l group also.
The chances for this issue to be read by someone who faced the same issue are better there.

The BugReports group is a good idea, but it still has only 36 members (maybe we need to advertise a bit more)
I believe if we keep double-posting we may also make this group followed by more people.

BTW, regarding the issue you reported: for test reasons, did you try with simple logical names and not with secret names?
I know it's not safe for production environment, but it may help you verify the issue: logical names are for sure evaluated in db-properties (I 've tried already in XPA 3.2)

Regards
Avgerinos

On 18/2/2017 10:03 πμ, Heico van Wieringen via Groups.Io wrote:
It seems that Magic xpa 3.2 doesn't translate the Secret Names that are used in the definition of the connection with SQL Server. Has anyone experienced a similar problem?

Set-up:
SQL Server 2014, using a Application Role for Magic access.
Logon information stored in Secret Names.
Entry in the Database Information field of the Magic
Database Properties:

SQL_APPLICATION_ROLE = %SQL_APPLICATION_ROLE%
SQL_APPLICATION_ROLE_PASSWORD=
%SQL_APPLICATION_ROLE_PASSWORD%

On access of a SQL table in the Magic Runtime the following error appears:
====
"<DB name>: Cannot set application role
'%SQL_APPLICATION_ROLE%' because it does not exists or the
password is incorrect."
====

All settings are verified and correct.
With Magic xpa 3.1a, and unchanged settings, there is no problem.
Because of this error, Magic xpa 3.2 is a No Go for us.

Regards,
Heico van Wieringen


xpa 3.2 SQL Server connection failed using Application Role authentication

Heico van Wieringen
 

It seems that Magic xpa 3.2 doesn't translate the Secret Names that are used in the definition of the connection with SQL Server. Has anyone experienced a similar problem?

Set-up:
SQL Server 2014, using a Application Role for Magic access.
Logon information stored in Secret Names.
Entry in the Database Information field of the Magic
Database Properties:

SQL_APPLICATION_ROLE = %SQL_APPLICATION_ROLE%
SQL_APPLICATION_ROLE_PASSWORD=
%SQL_APPLICATION_ROLE_PASSWORD%

On access of a SQL table in the Magic Runtime the following error appears:
====
"<DB name>: Cannot set application role
'%SQL_APPLICATION_ROLE%' because it does not exists or the
password is incorrect."
====

All settings are verified and correct.

With Magic xpa 3.1a, and unchanged settings, there is no problem.
Because of this error, Magic xpa 3.2 is a No Go for us.

Regards,
Heico van Wieringen

Re: XPA3 combo-control: incompatibly with prior versions

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:
Re-posting so that it also goes to the new BugReports sub-group:
=====================================================

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







Re: XPA3 combo-control: incompatibly with prior versions

Avgerinos
 

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

On 17/2/2017 8:45 πμ, Avgerinos wrote:
Re-posting so that it also goes to the new BugReports sub-group:
=====================================================

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




XPA3 combo-control: incompatibly with prior versions

Avgerinos
 

Re-posting so that it also goes to the new BugReports sub-group:
=====================================================

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

UniPaas to XPA CtrlGoto Bug

Joe Searfoss
 

Not sure this would be considered a bug, but it is different behavior between UniPaas and XPA. I have programs that have a form with a subform. Allow Tab Into is set to false on the subform control. The only way to park on the subform is to click on it or I have a button that raises a CtrlGoto to jump to the subform. I also have a Event  (Window Hit) so the user cannot click off the form and close it. It no longer works. The Window Hit stops the CtrlGoto from working. As soon as I removed the Window Hit event the GtrlGoto started working again. I have checked this in XPA 3.1 and 3.2

Joe

XPA-3 bug: Verify op. in Main program ignores the display-mode property

Avgerinos
 

Hi magicians

Documenting an issue noticed in XPA3 (tested up to 3.2)

A Verify operation in MAIN program's TaskPrefix always ignores the property "Display=Status"
Instead it is always shown as a popup-alert
That was not the behavior in uniPaaS 1.9

Anyone else noticed it?

Regards
Avgerinos

Re: Expression evaluates differently in XPA-3 compared to uniPaaS

Avgerinos
 

The only workaround I found so far is to locate all my DirectSQL statements (not easy when you have 1700 programs to migrate)  and change the expression to:

Str ( '01/01/2016'DATE - '01/01/0001'DATE  + 1,'6.8' )
('6' picture would do, but I kept the '6.8' picture just in case, for full compatibility with uniPaaS)

Still it would be nice if there was a global setting to instruct XPA3 to handle dates the old way

Avgerinos



On 17/1/2017 10:29 μμ, Avgerinos wrote:

Hi magicians

Documenting some difference in behavior I noticed while migrating from uniPaaS to XPA3 (tested on 3.1.b so far).

Expression  DVal (DStr ( '01/01/20616'D, 'DD/MM/YYYYY'), 'DD/MM/YYYYY' ) )  is sent as a parameter to an DirectSQL command (MSSQL).
I use the SQL Profiler to see how this finally evaluates:

  • in uniPaaS it evaluates as number 735964.00000000 (the integer behind a MagicDate) and works fine.
  • in XPA is evaluates as number 160101 and brings wrong results
It's messing up all programs that use direct SQL, since they all base on date filtering.
Any known workaround or global setting, so that I avoid correcting programs with Direct SQL one by one?

Thanks in advance
Avgerinos


Re: Expression evaluates differently in XPA-3 compared to uniPaaS

Avgerinos
 

Same issue with a more simple expression like:  DVal ( '01/01/2016', 'DD/MM/YYYYY' )

Maybe XPA stopped using the Magic (Integer) Date format internally?
Or it is simply a bug of how it sends parameters to a DirectSQL?

On 18/1/2017 8:07 πμ, Avgerinos wrote:

Correcting the typo:

DVal (DStr ( '01/01/2016'D, 'DD/MM/YYYYY'), 'DD/MM/YYYYY' ) )


On 17/1/2017 10:29 μμ, Avgerinos wrote:

Hi magicians

Documenting some difference in behavior I noticed while migrating from uniPaaS to XPA3 (tested on 3.1.b so far).

Expression  DVal (DStr ( '01/01/20616'D, 'DD/MM/YYYYY'), 'DD/MM/YYYYY' ) )  is sent as a parameter to an DirectSQL command (MSSQL).
I use the SQL Profiler to see how this finally evaluates:

  • in uniPaaS it evaluates as number 735964.00000000 (the integer behind a MagicDate) and works fine.
  • in XPA is evaluates as number 160101 and brings wrong results
It's messing up all programs that use direct SQL, since they all base on date filtering.
Any known workaround or global setting, so that I avoid correcting programs with Direct SQL one by one?

Thanks in advance
Avgerinos



Re: XPA3 - Tab control accelerators not working?

Avgerinos
 

Hi magicians

Accelerators in Tab-controls seem not to work in XPA-3 (tested up to XPA 3.2, desktop form)
I could not find any official documentation that this functionality is officially obsolete

Regards
Avgerinos

Re: Expression evaluates differently in XPA-3 compared to uniPaaS

Avgerinos
 

Correcting the typo:

DVal (DStr ( '01/01/2016'D, 'DD/MM/YYYYY'), 'DD/MM/YYYYY' ) )


On 17/1/2017 10:29 μμ, Avgerinos wrote:

Hi magicians

Documenting some difference in behavior I noticed while migrating from uniPaaS to XPA3 (tested on 3.1.b so far).

Expression  DVal (DStr ( '01/01/20616'D, 'DD/MM/YYYYY'), 'DD/MM/YYYYY' ) )  is sent as a parameter to an DirectSQL command (MSSQL).
I use the SQL Profiler to see how this finally evaluates:

  • in uniPaaS it evaluates as number 735964.00000000 (the integer behind a MagicDate) and works fine.
  • in XPA is evaluates as number 160101 and brings wrong results
It's messing up all programs that use direct SQL, since they all base on date filtering.
Any known workaround or global setting, so that I avoid correcting programs with Direct SQL one by one?

Thanks in advance
Avgerinos