LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Rebuild library contents after crash

I've been building up classes, members and VIs in a Library in NXG all day.  I've saved files, renamed namespaces and classes, added data, generated member VIs and basically done a lot of work.

 

Then NXG crashed and aborted.  When I reopen my project, the view of the library is a very old one - obviously saving individual files is one thing, but the gcomp file needs to be saved in its own right it would seem.

 

My files are on disk, in the right folder (which maps to namespaces) but the only thing I can see to do at the moment is to "import file".  I can't do that at a folder (namespace) level, only file-by-file which means right down at the member level - i.e. for each type or .gvi.  It's not even possible to select multiple files.

 

There must be a better way to bring my namespaces back into the .gcomp library file - it is a lot of work to try and do it at a file level.

 

This has happened before but the last time, I only had a few simple VIs to re-import and whilst it was a pain, it only took a few minutes.

0 Kudos
Message 1 of 9
(1,214 Views)

@andrewDJ wrote:

I've been building up classes, members and VIs in a Library in NXG all day.  I've saved files, renamed namespaces and classes, added data, generated member VIs and basically done a lot of work.

 

Then NXG crashed and aborted.  When I reopen my project, the view of the library is a very old one - obviously saving individual files is one thing, but the gcomp file needs to be saved in its own right it would seem.

 

My files are on disk, in the right folder (which maps to namespaces) but the only thing I can see to do at the moment is to "import file".  I can't do that at a folder (namespace) level, only file-by-file which means right down at the member level - i.e. for each type or .gvi.  It's not even possible to select multiple files.

 

There must be a better way to bring my namespaces back into the .gcomp library file - it is a lot of work to try and do it at a file level.

 

This has happened before but the last time, I only had a few simple VIs to re-import and whilst it was a pain, it only took a few minutes.


I don't know of any way to get back your data, but I do know that the time to use your safety belt is before you get into an accident.  This is particularly bad because you already had a close call.  I can't stress this enough: Use versioning software!!!  And don't be afraid to make commits, either.  Every time you commit, it's a point in time you can go back to in case of catastrophic events, or even if you find you went down the wrong path and want to do something differently.  If you committed your changes every time you made some major change, you probably would have only a few things to redo.

Think of it like a video game.  Make saves often so if the game crashes, you won't lose all your progress.  Save the game also if you are going to attempt something difficult.  Then if you fail, you can always try a different strategy.  Some may call that "cheating", but there's no such thing as cheating when it comes to keeping the software you are working on safe.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 9
(1,211 Views)

I agree with you in respect to version control, no issue.  

 

However, the problem here is that every time you change a file in a Library, it updates the library .gcomp file as well.  It won't matter a jot about version control unless that .gcomp file is saved after every change to a sub-file as well and that doesn't happen automatically.  Committing changed files to version control is all well and good but they will be out of sync with the library unless you have remembered to save that file so it is also committed so the best you can do is rollback to the time the library was last saved (which is no better than where I am now.)

 

Whilst the project is open and being worked on, the .gcomp file is being quietly changed behind the scenes as well - it is flagged with a * to indicate it's changed but it's not obvious that your work is changing that file.  The only way to avoid this would be to not use muscle-memory to CTRL+S the file being worked on, but remember CTRL+SHIFT+S or navigate the pointer to the 'save all' icon and click on that.  I haven't 'lost' data as such, it's all there on disk, the issue is that the .gcomp file is out of sync with disk contents and needs rebuilding/refreshing or whatever.  

 

And yes, once bitten I should have remembered that that file was being changed quietly but when you're concentrating on work it's not at the forefront of your mind: you think "I've saved that file, all's good with the world"  but it's not because the library file is now out of sync with what has been committed to disk: in other words, the application is in an inconsistent state.  I'd call that crazy behaviour but I don't know if there are internal architecture reasons for it.

 

But nonetheless, it would seem the only recourse is to work out how best to import files into the library so that dependencies are re-built at the same time.  Hopefully missing dependencies will be resolved as the dependent file is imported.

0 Kudos
Message 3 of 9
(1,203 Views)

@andrewDJ wrote:

I agree with you in respect to version control, no issue.  

 

However, the problem here is that every time you change a file in a Library, it updates the library .gcomp file as well.  It won't matter a jot about version control unless that .gcomp file is saved after every change to a sub-file as well and that doesn't happen automatically.  Committing changed files to version control is all well and good but they will be out of sync with the library unless you have remembered to save that file so it is also committed so the best you can do is rollback to the time the library was last saved (which is no better than where I am now.)

 

Whilst the project is open and being worked on, the .gcomp file is being quietly changed behind the scenes as well - it is flagged with a * to indicate it's changed but it's not obvious that your work is changing that file.  The only way to avoid this would be to not use muscle-memory to CTRL+S the file being worked on, but remember CTRL+SHIFT+S or navigate the pointer to the 'save all' icon and click on that.  I haven't 'lost' data as such, it's all there on disk, the issue is that the .gcomp file is out of sync with disk contents and needs rebuilding/refreshing or whatever.  

 

And yes, once bitten I should have remembered that that file was being changed quietly but when you're concentrating on work it's not at the forefront of your mind: you think "I've saved that file, all's good with the world"  but it's not because the library file is now out of sync with what has been committed to disk: in other words, the application is in an inconsistent state.  I'd call that crazy behaviour but I don't know if there are internal architecture reasons for it.

 

But nonetheless, it would seem the only recourse is to work out how best to import files into the library so that dependencies are re-built at the same time.  Hopefully missing dependencies will be resolved as the dependent file is imported.


I understand what you are getting at now.  So you're saying, "I'm making a bunch of changes, then crash before I could actually save the library (gcomp) file".  This is how it is in LV Classic, too.  I don't have a good explanation for that design choice.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 9
(1,173 Views)

Bum.  Apps crash,  bugs happen, but it’s pretty inexcusable to leave work inconsistent and irrecoverable.  I’ll have to work it through tomorrow but hopefully an engineer will be able to comment.

0 Kudos
Message 5 of 9
(1,154 Views)

@andrewDJ wrote:

Bum.  Apps crash,  bugs happen, but it’s pretty inexcusable to leave work inconsistent and irrecoverable.  I’ll have to work it through tomorrow but hopefully an engineer will be able to comment.


Sorry I couldn't help you.  😞

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 9
(1,138 Views)

No problem, thanks for looking.  

 

I've managed to re-import files and rebuild the .gcomp file but there ought to be a better way than that.  It feels wrong that whenever a change is made and saved, that something else needs to be navigated to and saved as well - that's a recipe for disaster.  In fact, to such an extent, it feels like I must be missing something; I'm very new to the LabView/LabViewNXG ecosystem so there is a lot I don't know yet.

0 Kudos
Message 7 of 9
(1,111 Views)

Hmmm... in LabVIEW Classic, there's an option for autosaving files in case of a crash; in NXG I don't see that option.  😞

 

It has saved me from situations exactly like what you described here.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 9
(1,071 Views)

I looked as well and found nothing.  I've been CTRL+SHIFT+S'ing like a demon all day!  

 

Message 9 of 9
(1,064 Views)