7.20.0808 |
  
|
7.20.0808 |
|
Released on October 23, 2020
The IWbs.GetFullData method could return wrong data if the estimate was opened with IEstimateFactory.GetEstimate and the last saved user profile in the estimate was different from the current user (which is always Admin in the case of the estimate opened with IEstimateFactory.GetEstimate).
In such a case, the saved WBS workbook was not valid if IEstimate.CheckAndRepaint was not called. The problem only happened if the WBS column positions were different for that user and for Admin, i.e. the user has moved the WBS columns (the positions of WBS columns are user-specific). Since the data is read from the workbook, the result from IWbs.GetFullData was shifted according to column position differences between the user and Admin.
As already mentioned, to avoid the problem, a call to IEstimate.CheckAndRepaint was required before a call to IWbs.GetFullData. Now this is no longer required.
The problem didn’t occur in normal macros with the estimates passed in the Es parameter, because this estimate is opened for the current user and not for Admin. The most likely affected applications were external clients that use QDV interface and open estimates with IEstimateFactory.GetEstimate method.
This problem only occurred starting with QDV version 7.20.807. When you tried to execute a compiled macro, an error saying that recompilation failed could occur. This applied only to some macros.
For example, some older macros that were probably saved from Visual Studio. Or when a macro was exported and then imported.
With propagation, only the algorithm must be locked. This allows the second phase to run without error.
If you had no file DefaultFolderForReport.inf in the installation folder of the application, default reports (samples) were displayed. Now when you don’t have such file, the list is kept empty.
With propagation, only the algorithm must be locked. This allows the second phase to run without error.
In the database of the estimate, you can have this:
Where article C doesn’t belong to the set because you cannot create a set having a header coming from the database of the estimate. But of course, you make B a set containing C and have it seen as below:
Which is the correct way to structure sets in the database of the estimate. In the first screen shot below, you clearly see that the article C is not attached to the set because you have no vertical line between B and C.
Unfortunately, in the minutes, the set was taken into account as a whole set, including line C:
Leading to errors which were detected at computing time but quite hard to find because the location of the error was not in the message.
The problem is now solved, so when you use a set like SA above, you get A and B but C is ignored:
When a set coming from the database of the estimate was collapsed in the minutes if displayed correct figures on sum columns but if when a change is brought to the set in the database of the estimate (adding or removing an article, etc.) the figures are not adapted immediately on the collapsed row. A Compute-all operation was requested to get correct figures.
The problem has been solved: N/A is displayed on the collapsed row after such a change and a simple Compute-Costs operation displays correct figures.