If I want to create a program node having movement node, waypoints node, comments node , popup node etc. I can use the URCap SDK to create a subtree for my program node, which works fine. The problem is when the subtree is very complex and large, this will be very hard for a novice user to grasp, but for an for expert user this would be great.
I want to be able to cater for boths groups, the novice and the advanced user, but today I need to do double the work, by
creating the subtree via the SDK to show the complexity
and by writing a big urscript to hide the complexity
both does exactly the same thing.
What is it?
Its just for hiding complexity when needed.
As a URCap developer I want to create a custom program node which is be able to hide the children nodes as default, if an advance user want’s to look up how my custom node works he/she will be able to check unhide, to see the children node for inspection.
If I just want to cater the novice users only. I can decide to permanently hide the children nodes.
Why is it needed?
Like stated before this feature is needed to hide compexity from users while still maintaining the subtree for advance users.
To hide complexity today, you must create every single thing within the generatescript method which is all in string and “wrap” it in a program node.
Since all is in strings there is no typechecking and the possibility for errors are very big.
The URCap SDK has great support for creating subtrees and it would be silly not to take the advantage of using it, it is less error prone since it is all in java.
Another great thing by creating a subtree is that, while developing you can step by step see if your program node runs correctly in the Robot program, because it’s just using the native nodes.
This is great for URCap developers and is much easier to debug, in contrast to resolving errors within your urscripts written in plain text.
This should be simple to implement since folders and subprograms already has this ability , but you cant do this via the URCap SDK which also would be very useful.
Would it be sufficient if the FolderNode interface got the methods set/get HideFolderProgramTree?
That would be a very good alternative for now.
Related to this existing feature request: