Distributed Control & Automation Framework (DCAF)

cancel
Showing results for 
Search instead for 
Did you mean: 

Deleting a module breaks the configuration file

In the process of refactoring some of my code, I deleted a module which I wanted to re-design before I had removed it from my config file.  When trying to open the config file, it won't load at all and since editing the pcfg file by hand is not feasible given that modules are referenced using GUIDs, I lost a lot of configuration information unrelated to the module I deleted.

 

Surely the configuration should still load, and maybe a red cross gliph be placed over the module it couldn't find?

 

Bruce

0 Kudos
Message 1 of 3
(3,662 Views)

I believe this is a known issue. The best workaround for now may be to reinstall the module that was deleted, assuming it is backed up somewhere. Then remove it from your configuration file(s) before deleting it from disk again.

 

It looks like a better long-term solution for this is under investigation here:

https://github.com/LabVIEW-DCAF/TagEditorCore/issues/284

0 Kudos
Message 2 of 3
(3,643 Views)

Like Burt said, we are looking into a good long term solution but if you are looking for more of a short-term "hack" to at least let you open the configuration, you should be able to do the following.

 

1. Using the File>Create File... dialog, create a new Dynamic Module and save it to<vi.lib>\NI\DCAF\Tag Editor Core\Framework Configuration Classes.

2. You shouldn't really need to modify anything but I made the following changes to at least give a bit of information to the user. Screenshots are below but I modified the from string to push all of the "Data" input to the classes data (you will need to add a string to the class's private data). I edited the to string method to just throw an error to block the user from saving the configuration. Finally I edited the Main Editor UI to simply display the data.

 

From String.png

To String.png

Main UI.png

 

3. Now you will need to monitor the configuration editor to load this class when it cannot find the correct module to load. The two VIs you need to modify are "NISE_CEF_TreeSerializer.lvlib:strings to memory.vi" to pass an object of the configuration class you just made if there is an error from loading the class by name. Then you will need to modify "NISE_CEF_Node.lvclass:FromRepo.vi" to pass an object of the editor class you just made if there was an error loading the correct class. It would be better to search for a specific error but this worked and should something like the images below.

 

2018-01-24 12_24_57-NISE_CEF_Node.lvclass_FromRepo.vi Block Diagram _.png2018-01-24 12_19_31-NISE_CEF_TreeSerializer.lvlib_strings to memory.vi Block Diagram.png

 

I would revert these changes after you get the information you need but this should at least let you look at the configuration. Hopefully we can have a better and more permanent solution in the future but I hope this helps for now.

Matt J | National Instruments | CLA
Message 3 of 3
(3,640 Views)