Summary
DataModel that could be read/written to by all program nodes, with each saved program having its own instance that can be read/written to.
What is it?
In an application I am writing a URCap for at the moment, a very useful feature to have would eb a DataModel that was program wide, i.e. a DataModel type object, of which there was one instance per saved program, which any program node could access.
Why is it needed?
I realise that using the installation file’s DataModel acheives something very similar to this, however this means that 2 different programs wouild be able to access the same data which I would like to avoid, and the workaround would be to start saving data against randomly generated keys which some program would generate, though this gets messy and there isn’t a clean way of acheiving the desired functionality, hence the need for a data model which is program specific.
If anyone has any other ideas of how this could be acheived, let me know! In general I think this would be a useful feature for a variety of applications.
You could have a parent node that feeds its own datamodel to its children through dependency injection.
then they have a shared datamodel through the parent.
the down sides is that this required them all to share a the same parent. which might not be ideal if the node type is supposed to be sprinkled in here and there in the node tree.
best regards
This was another consideration but like you say it restricts the data to children nodes specifically, which unfortunately for my usecase wouldn’t work
The only thing left would properly be to simply save what ever data they need access to into a file, perhaps json, xml, or Yaml
by using the dashboard client you could get the name of the program which could be used to name these files.
this way every program would get a unique data file they can save and load from…
the down side here would be that the data would not transfer in cases where the programs are renamed.
but this could be mitigated by making a load data file functionality somewhere allowing old data files to be loaded and used instead of the auto generated one.
If there is not a lot of data, then you can try to create a global
a installation variable of type text (or several). Which has
just about the following structure:
global i_var_1=“ID:obj1, A:1, B:3, C:7; ID:obj2, A:1.3, B:36, C:7.2”
or
global i_var_1=“(ID:obj1, A:1, B:3, C:7) (ID:obj2, A:1.3, B:36, C:7.2)”
etc.
First, the variable must be created manually in the list of setup variables.
Then all that remains is to read, parse, change some parameters and
save again to the setting variable. The robot will save when rebooted
data to disk.
This variable is now readable and writable in both URCap and
PolyScope.
Again I had considered this as an approach, but like you say as soon as a program gets renamed things get very complicated which stops it from being a clean solution, I considered running a thread to monitor the name of the active program to rename this data file accordingly, but I’m not sure how to check if a change in program name is as a result of loading a new program or renaming an existing program, and it doesn’t get around renaming a program in the file editor when a program isn’t loaded
Yeah, I do not think this is possible either or at least I do not know of a way to accomplish this.
I would simply check if a data file exist for the corresponding program name, when the user press play.
If the file do not exist ask them via pop up to go to the installation node (or maybe toolbar) where they can either “copy” and old one or create a new one.
While being a slight inconvenience, I think that as long as you make it an obvious part of the work flow, that it properly wont be to bad of a user experience
best regards.
I think that you can try using a database to separate access.