PR 227576 Errors running the automated surface profile tests.

huangyhg

Errors running the automated surface profile tests.
<< Alessandro Zanetti  --  10/04/04  15:45:17>>
Errors running the automated surface profile tests.
Steps to reproduce:
Run the automated surface profile tests.
Results:
See attached text file
Expected Results:
No errors
<<END>>
<< Jerry Naylor  --  10/06/04  09:35:32>>
notaddedtoreadme
<<END>>
<< Alessandro Zanetti  --  10/06/04  11:54:22>>
Thanks Don, works fine now.
Verified on current 3.7, test passed with no errors, closing.
<<END>>
<< Changes made by Alessandro Zanetti -- 10/06/04  11:54:50>>
Action:  Alessandro Zanetti to Don Turcotte, Status:  REVIEW to CLOSED
<<END>>
<< Don Turcotte  --  10/05/04  16:59:21>>
This has been corrected by the fix to PR227570.  Please read the Description field in that PR.
<<END>>
<< Changes made by Don Turcotte -- 10/05/04  16:59:32>>
Action:  Don Turcotte to Alessandro Zanetti, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Tim Wernicke -- 10/04/04  08:57:18>>
Action:  Wade Burton to Don Turcotte, Assigned:  Wade Burton to Don Turcotte, Priority:  to High
<<END>>

huangyhg

PR 227570 Errors running the automated angularity tests.
<< Jerry Naylor  --  10/06/04  09:40:14>>
notaddedtoreadme
<<END>>

<< Alessandro Zanetti  --  10/06/04  11:56:50>>
Thanks Don, works fine now.
Verified on current 3.7, test passed with no errors, closing.
<<END>>

<< Changes made by Alessandro Zanetti -- 10/06/04  11:56:56>>
Action:  Alessandro Zanetti to Don Turcotte, Status:  REVIEW to CLOSED
<<END>>

<< Don Turcotte  --  10/05/04  16:55:21>>
I have logged a separate problem report concerning the problem that the automation Execute() call does not invoke executeprivate() on the dimensions directly, but only indirectly as a result of the edit window LoadReport() method.  This is PR227628.

I have modified the VB automated tests to call Evaluate() on the dimension commands rather than EXECUTE() on the command.  This avoids the current problem with the way EXECUTE() is handled in PC-DMIS and has the added advantage of allowing the VB tests to run somewhat faster since PC-DMIS is not constantly re-loading the edit window.  No changes were made to the test algorithms or logic.  The basic problem here is automation related only.  These changes apply to PR227570 through PR227576 which are all against the VB automated tests.

Alessandro,
I have attached an updated VB test install package zip file to this report.  Please uninstall your current version before installing this new version. (Use Microsoft Windows Control Panel, Add & Remove Programs.)
<<END>>

<< Changes made by Don Turcotte -- 10/05/04  16:56:41>>
Action:  Don Turcotte to Alessandro Zanetti, Status:  OPEN to REVIEW
<<END>>

<< Don Turcotte  --  10/04/04  14:27:16>>
I have traced the problem to changes made in the dimensions where a check is made for editor->ReportLoading.  In this case, do_math() is not performed.  In the automated tests that are failing, do_math() is not called because editor->ReportLoading is true.  I have sent e-mail to Wade to get an explanation of this change.
<<END>>

<< Changes made by Tim Wernicke -- 10/04/04  08:58:56>>
Action:  Wade Burton to Don Turcotte, Assigned:  Wade Burton to Don Turcotte, Priority:  to High
<<END>>

huangyhg

PR 227628 When VB automation calls EXECUTE on a command, the executeprivate() method is called only from editwin LoadReport()
<< Don Turcotte  --  10/05/04  11:07:50>>
When a VB automation program calls EXECUTE on a PC-DMIS command, the executeprivate() method of the PC-DMIS command is called only as a result of a call to Editwin LoadReport().  At this point, the ReportLoading flag is set so calling EXECUTE on a dimension command from VB will not call do_math() on the PC-DMIS dimension command since the dimension command executeprivate() skips the call to do_math() when ReportLoading is TRUE.  The executeprivate() method should get called before LoadReport().

Steps to reproduce:
Load PC-DMIS (do not open a program)
From Visual Basic 6.0, load the attached VB project.
Run the VB (this will create features and dimensions) and display a dialog.
Press OK on the dialog to execute the dimension tests.  In the VB code, EXECUTE is called on the dimension commands.


Results:
When the Execute method of the commandwrapper is called, the executeprivate() of the dimension command is called only from LoadReport() of editwin, at which point ReportLoading is TRUE so do_math() of the dimension command is not called.

Expected Results:
executeprivate() of the dimension command should be called before LoadReport().
<<END>>
<< Jerry Naylor  --  10/26/04  16:29:36>>
notaddedtoreadme
<<END>>

<< Changes made by Don Turcotte -- 10/26/04  13:25:33>>
Status:  RESOLVED to CLOSED
<<END>>

<< Bret Naylor  --  10/26/04  10:32:26>>
Reviewed.
<<END>>

<< Changes made by Bret Naylor -- 10/26/04  10:32:32>>
Action:  Bret Naylor to Don Turcotte, Status:  REVIEW to RESOLVED
<<END>>

<< David Petrizze  --  10/25/04  16:07:13>>
Reviewed.  Thanks, Don.  This looks good.
<<END>>

<< Changes made by David Petrizze -- 10/25/04  16:07:21>>
Action:  David Petrizze to Bret Naylor
<<END>>

<< Don Turcotte  --  10/13/04  15:39:39>>
Dave,
I set the FAST_EXECUTE on global_edit_options in commandwrapper.cpp Execute() method.  The reason why the executeprivate() of the command was still not being called from the execute loop is that the MARKED bit must also be set and the sequence must be reset to 0.  After the command executes, I restore the original state of the MARKED bit.  All now works as expected.

I removed Rex's change.

******************************
Wed Oct 13 15:35:26 2004
******************************

Files inserted to server
------------------------
V40\AUTOMATION\COMMANDWRAPPER.CPP
V36\AUTOMATION\COMMANDWRAPPER.CPP

<<END>>

<< Changes made by Don Turcotte -- 10/13/04  15:40:52>>
Action:  Don Turcotte to David Petrizze, Status:  MOREINFO to REVIEW
<<END>>

<< David Petrizze  --  10/11/04  14:46:56>>
Reviewed.  Don, this is not the correct solution.  I thought that we exchanged emails about how to resolve this using the FAST_EXECUTE bit on global_edit_options.  So I have two questions, why did you fix this and why wasn't the fix according to our discussion?
<<END>>

<< Changes made by David Petrizze -- 10/11/04  14:47:10>>
Action:  David Petrizze to Don Turcotte, Status:  REVIEW to MOREINFO
<<END>>

<< Alberto Piolatto  --  10/11/04  10:15:56>>
Reviewed.

<<END>>

<< Changes made by Alberto Piolatto -- 10/11/04  10:15:58>>
Action:  Alberto Piolatto to David Petrizze
<<END>>

<< Alberto Piolatto  --  10/11/04  10:14:44>>
Reviewd.

<<END>>

<< Rex Heagy  --  10/06/04  11:02:55>>
Merged and tested changes in v40.

Files for review:

******************************
Wed Oct 06 11:01:58 2004
******************************

Files inserted to server
------------------------
V36\AUTOMATION\COMMANDWRAPPER.CPP
V40\AUTOMATION\commandwrapper.cpp

<<END>>

<< Changes made by Rex Heagy -- 10/06/04  11:03:03>>
Action:  Rex Heagy to Alberto Piolatto, Status:  OPEN to REVIEW
<<END>>

<< Rex Heagy  --  10/05/04  15:06:08>>
Duplicated problem report. Started tracing flow to determine where to insert a do_math() prior to the ReportLoading flag being set TRUE in LoadReport().
<<END>>

<< Don Turcotte  --  10/05/04  11:15:24>>
In the attached zip there is also a "C-DMIS Distance Tests.exe" which can be run instead of loading Visual Basic 6.0.
<<END>>

<< Changes made by Don Turcotte -- 10/05/04  11:16:42>>
Action:  Don Turcotte to Rex Heagy
<<END>>