Several Object Browser issues

[MarvinW]

Hello,

I have some feedback for the Object Browser.

The first is about version management. When we are preparing a new object version, we use the last digit for test releases. I think this is also how BCI is doing this, although it has been many years since I had such a BCI object in my hands. Anyway, my problem is that the test versions are thus ranked as newer than the final release version, which uses 0 for the last digit.

For example, I am upgrading an object from 1.0.0.0 to 1.0.1.0. But before I can release the new version, I give an object version 1.0.1.1 to my colleagues in the field for testing. Then after I confirm everything is fine and maybe fix some bugs they found, I will finally release 1.0.1.0 on our release repository. But the colleagues who have 1.0.1.1 in their STD will not be displayed the release version when they are looking for compatible updates, because the last number 0 is lower than their test release number. And when they select it manually, it is also labeled as "compatible downgrade" in the download dialog. My suggestion is to treat the last digit special, where 0 is the newest version and any other number is using normal sorting. Maybe this could be enabled or disabled with a setting of the Object Browser.

My second point is a question. After updating my STD I found that the Object Browser downloaded all 3 available versions of the Mode Handler Template when I updated some other objects. It was not even selected though for download. I think this is because I have no version of this object in my STD at all, but I downloaded another object that has hierarchyNodeType="ModeHandler". But I don't know if this is the cause or not. Anyway, I wish the object browser would not download any unwanted objects that I did not select and that are not a dependency of any object in my STD.

The third one is a feature request. I would like to be able to automatically download all objects (and peripherals) based on an ObjectVersions.xml file that OES generates in the Engineering folder. Or alternatively it could be from an Object Usage file (because that is created from the ObjectVersions anyway, correct?). The point is to reduce the size of our base station backups. With this feature, the person who creates a new STD for a project can get the base station project (only the Stat folder) and then use the object browser to download the STD conveniently and then update the objects that are in use. As a bonus, I would like to be able to select more than one station folder (ObjectVersions.xml file) for this purpose.

[nexidator]

One more hint concerning 2: I guess you are using the EasyPanel add-on, which contains a dependency to the ModeHandlerTemplate allowing several versions. In general, when an object contains a BaseRef or Using allowing several versions, Object Browser selects all applicable versions of the referenced object. It should not select objects referenced as "Dependency", but it currently does. These two points are already in our backlog. What I cannot reproduce is that the ModeHandlerTemplate wasn't even selected before it was downloaded. When I select the EasyPanel, several ModeHandlerTemplate versions are selected.

And another hint concerning 3: The import from the ObjectVersions.xml does not consider the object versions. It will always download the latest version. It's also on our list to improve the function so it tries to download compatible versions at least. But still I am not sure if the function would be a good replacement for backing up the Std folder. Maybe it is good enough for a BaseStation project if you don't care if the exact same object versions are used every time.

[Despejo47]

Hello all,

Regarding to the point 2. It's not only happends with ModeHandlers it's happens with few objects and his dependencies, since "versions· is added to ood.

Eg. Update NxDataSetManagerAddon dowload all incompatible versions of DataDefBase.

This is not nice because place scrap on repository. This is happen with many other objects.

One easy solutions could be a checkbox when copy objects on i"ncompatible downgrade", then we can avoid dowlload scrap.

[MarvinW]

Thanks for all the responses.

Concering version numbers: I think using gaps in incompatible version number is a possible solution. I indeed do not care how much a number increases by with each update.

Concerning mode handler template: I am using an easy panel but it's not the easy panel that is pulling in the Mode Handler Template. I tried using the reverse dependency mode in the object browser to find out which object does, but it does not work (probably because you are using versions instead of version?). Anyway, I have a similar pain like Despejo.