Copying Visual Script Activities

MBPM v9 SR2 hf1

Copying a visual script activity seems to work by reference and deleting the original activity will clear the contents of the copied activity. I came across this while trying to re-construct some existing forms. Copying an assignment activity from Form1 on-load to Form2 on-load is fine until Form1 is deleted at which point the contents of Form2 on-load activity become empty.

Has anyone else experienced this? or is this behaviour 'by design'?

Find more posts tagged with

BPM

Comments

Neil_Hudspeth

I'm not seeing this behaviour. I'm running SR2 with the Hotfix applied.

Jerome_Pearce

That would not be by design, as it would break every known principle (including my favorurite: The Principle of Least Astonishment).

I recall from trawling through the XML that there is a generated internal unique ID for these activities. This may, in some versions, have been duplicated on a copy. I have not seen any behaviour that shows this. An example would be great if you are able to build a simple one.

Paul Lawrence

I am suspecting that this problem is being caused by some kind of corruption with the solution as I have other strange behaviour that I do not get in other solutions.

This solution has now lost the Metastorm.Runtime.Models namespace and a promoted script (the script is there, just not visible as being promoted).

Has anyone experienced this kind of behaviour?

I think I need to track back through my backups and try and locate a version where this is not a problem.

Jerome_Pearce

Paul wrote:

I am suspecting that this problem is being caused by some kind of corruption with the solution as I have other strange behaviour that I do not get in other solutions.

This solution has now lost the Metastorm.Runtime.Models namespace and a promoted script (the script is there, just not visible as being promoted).

Has anyone experienced this kind of behaviour?

I think I need to track back through my backups and try and locate a version where this is not a problem.

This happens whenever the Designer cannot compile the scripts. If anything is wrong, even in a Library, all refeences can be lost and nothing will work. One of the joys of moving into the bountiful world of C#, I'm afraid....

Paul Lawrence

I tracked this one down yesterday. I had used a form template several times in this solution and the template included two visual script event handlers, on form load, and on select row. Although the designer had not thrown any dialogs when multiple forms had been created from a single it did not like the fact that the visual scripts had the same name.

The impact of this was that when the solution was opened the designer could not compile the Metastorm.Runtime.Models namespace. It did not throw any errors on opening the solution but the designer did write warnings in the logging file (which I do not routinely inspect every time I open a solution). So it seems that you can open a solution and think everything is OK when if fact something quite serious has happened.

This seems to have been the source of all sorts of strange behaviour. It would be a significant improvement if these kinds of warnings/errors were displayed to the developer when a solution was opened rather than having to rely on the developer looking at the logging file just in case something might have happened - that just isn'y very intuitive.

The other impact I have noticed is a change in the project file. The 'status' of the project had been set to False, although changing back to True (seems to be the default) does not appear to make any noticable difference in behaviour. Anyone know what this does?

In relation to naming, it seems that form components from templates can keep duplicate names but visual scripts need to be unique across the project. Now I know that the documentation indicates that everything must have a unique name but in practice this only seems to apply to a sub-set of components.