With version 7.0 of the Visual Scheduling Add-ins Developer Tools (short: VSADT) we publish, besides some minor enhancements, a new view type that allows to structure resources depending on their skills.
At the beginning a word about the only breaking change of the new version: Please note that there is now no fallback of allocation property values to activity property values by default. For example, if an allocation did not have its own color, it was previously colored with the color of the activity to which the allocation referred.
We decided to change the behavior since this improves the performance when updating activities. Also, many customers did not use these fallbacks at all. If the old behavior is needed for your application, you can re-enable it by setting DecouplingOfAllocationPropertiesFromActivities to False.
This is by far the most important enhancement of this VSADT release. Production planning requires a wide range of skills from resources – regardless of whether they are machines or resources. Therefore, it is obvious that VSADT also provides a view focused on this aspect of resources.
The new view of type SkilledResources is a special kind of resources view and shows resources grouped by skills. These skills can be defined by objects of type Skill. Analogous to all other VSADT object types, you can handle these objects with the methods AddSkills, UpdateSkills, and RemoveSkills
Skill objects are displayed as rows – similar to resources. And the resources that belong to a skill are positioned below its row.
To define skills for a resource, the resource property SkillIDs can be set an array of strings listing the corresponding skill IDs. Since a resource can have more than one reference to a skill object, it is possible that a resource is displayed multiple times, once for each skill.
Similar to how resources can have skills, allocations can have them as well. However, each allocation can have only one of them (see allocation property SkillID). This allows you to determine which skill of a resource is required or claimed for processing an activity.
In the new view, each resource row shows all allocations associated with the corresponding resource. That is, those allocations that have no skill assigned to them are also displayed. To make them visually distinguishable from the allocations with skill, their design can be altered by the setting AllocationBarDesignOfOtherSkill, for example, to tone down their colors (see setting onedDownOverlayColor) or to reduce their heights (see setting educedBarTopOffsetAndHeightScaleFactor) so that they are less noticeable.
Please note that the following limitations apply:
The following figure gives you an impression of what such a view looks like:
Here we see on the left side a Resources View with five resources and four allocations assigned to them. In the Skilled Resources View on the right side of the figure above, we see three skills (welders, electricians, and plumbers) with the associated resources. Lisa is not shown in this view, because she has no skills. Peter is referenced by Allocation 1, which requires the skill of a welder (see the green bar). Since he is also an electrician, a second bar is displayed for Allocation 1 below the electrician skill (see the small pale bar). In a similar manner, Dave and Allocation 2 are treated. For Mary, the bar representing Allocation 4 is drawn pale for each skill because no skills are required for that allocation. Tina is listed in this view because she has a skill, regardless of the fact that she has not been assigned any allocation.
For an application developer, not having to deal with APIs that are too complex or difficult to use makes their daily work easier. With this in mind, the following changes have been made.
Performance improvement is an ongoing topic for us. This time we have created a possibility to reduce the complexity of bars by a switch in such a way that an increase in performance can be achieved.
For this, the new property BarDesign has been created for activities and allocations. Here you can specify in great detail which elements of a bar should be displayed. The values of the BarDesigns enumeration can be combined by using bitwise OR operators for this purpose:
Simple: 0
Default: 65535
DefaultReduced: 16711680,
Entries: 1
ComplexShape: 2 // actually only Regular is changed to Rectangle when unset
Symbols: 4
Status: 8
Constraints: 16
ReleaseAndDueDateSymbols: 32 // ignored on allocations
Baseline: 64 // ignored on allocations
ProgressAndPredictedEnd: 128
Text: 256
TonedDownColoring: 65536 // see setting TonedDownOverlayColor
ReducedHeight: 131072 // see setting ReducedBarTopOffsetAndHeightScaleFactor
Instead of specifying the design individually for each activity or allocation, you can also use the settings DefaultActivityBarDesign and DefaultAllocationBarDesign for setting a default design.
If your code still contains the allocation property For the value 4 this is without after-effect, for other values which were marked as deprecated for a long time, changes to the application are necessary. If this is the case, please contact us in case of difficulties.
There is a wide range of new options and properties for
The following enhancements to options and object properties are related to the graphical representation:
So far, when using the grouping feature of VSADT, it was possible to color table rows depending on their grouping level. To improve usability, the new property TableColorVisibleInTimeArea for the GroupingLevelDefinition object allows to color also the row in the time area with the same color as used in the respective table row.
The following figure compares the previous representation with the new one:
<style>
#root {
--my-color: magenta
}
</style>
activity.Color = "var(--my-color)";
The smart thing about this approach is that you can easily change the styling via CSS without having to change or replace a CSS file. For more information about using CSS custom properties in VSADT, please see also this blog post (originally for our HTML5 product VSW), but usage is analogous in VSADT).