LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

More specific change descriptions for projects

Status: Declined

Declined for reasons listed by AristosQueue in the thread:

 

"I am sorry you have hit this... it's partially my fault. I also wish this were improved, but I don't see it happening as it requires identifying every possible edit to the project and associating that edit with a descriptive string. There are far more types of edits than I can enumerate. Had we done it when the project was first being created and added those strings as each modification occurred, it would be manageable. It didn't seem that important at the start (circa 2004), and by now, there are too many to revisit.

 

LabVIEW NXG evaluated that and decided that generating a bulleted list of changes was really useless even when complete: it's hard to meaningfully describe everything that changed about a tree or graphical file in a text description. Therefore, that product has dropped the "what changed?" entirely. Reevaluating that decision now is pretty much impossible without overwhelming effort, for much the same reason as the LabVIEW 20xx platform. Having said that, the ability of LabVIEW NXG to diff two versions of a file is better than in LabVIEW 20xx, so it would be possible to add a "diff what is in memory against disk" option, which would be better than any flat list of changes.

 

This is one of those rare ideas where I could leave it open and let the kudos build up, but even if it gains lots of kudos, I don't see how we have the bandwidth to make the change requested, so I'm going to recommend to the rest of the evaluators that this idea be declined."

Often, I will open a project, poke around, and go to close.  When I close, there The LabVIEW project will prompt me to save.  If I press on "List unsaved changes..." The project will just say "An attribute of the project has changed".  This is so generic as to be completely useless.  I think this should be more specific to what attribute of the project has changed.  

4 Comments
Proven Zealot

I am sorry you have hit this... it's partially my fault. I also wish this were improved, but I don't see it happening as it requires identifying every possible edit to the project and associating that edit with a descriptive string. There are far more types of edits than I can enumerate. Had we done it when the project was first being created and added those strings as each modification occurred, it would be manageable. It didn't seem that important at the start (circa 2004), and by now, there are too many to revisit.

 

LabVIEW NXG evaluated that and decided that generating a bulleted list of changes was really useless even when complete: it's hard to meaningfully describe everything that changed about a tree or graphical file in a text description. Therefore, that product has dropped the "what changed?" entirely. Reevaluating that decision now is pretty much impossible without overwhelming effort, for much the same reason as the LabVIEW 20xx platform. Having said that, the ability of LabVIEW NXG to diff two versions of a file is better than in LabVIEW 20xx, so it would be possible to add a "diff what is in memory against disk" option, which would be better than any flat list of changes.

 

This is one of those rare ideas where I could leave it open and let the kudos build up, but even if it gains lots of kudos, I don't see how we have the bandwidth to make the change requested, so I'm going to recommend to the rest of the evaluators that this idea be declined.

Proven Zealot
Status changed to: Declined

Declined for reasons listed by AristosQueue in the thread:

 

"I am sorry you have hit this... it's partially my fault. I also wish this were improved, but I don't see it happening as it requires identifying every possible edit to the project and associating that edit with a descriptive string. There are far more types of edits than I can enumerate. Had we done it when the project was first being created and added those strings as each modification occurred, it would be manageable. It didn't seem that important at the start (circa 2004), and by now, there are too many to revisit.

 

LabVIEW NXG evaluated that and decided that generating a bulleted list of changes was really useless even when complete: it's hard to meaningfully describe everything that changed about a tree or graphical file in a text description. Therefore, that product has dropped the "what changed?" entirely. Reevaluating that decision now is pretty much impossible without overwhelming effort, for much the same reason as the LabVIEW 20xx platform. Having said that, the ability of LabVIEW NXG to diff two versions of a file is better than in LabVIEW 20xx, so it would be possible to add a "diff what is in memory against disk" option, which would be better than any flat list of changes.

 

This is one of those rare ideas where I could leave it open and let the kudos build up, but even if it gains lots of kudos, I don't see how we have the bandwidth to make the change requested, so I'm going to recommend to the rest of the evaluators that this idea be declined."

DNatt, NI
Member

Ok thank you for the response Darren.  That is totally understandable.

Active Participant

Also experiencing this and it's causing so much frustration trying to track it down. If I save the changes and compare it to the previous version they are completely identical (same hash etc.).

 

If I purposely modify every VI in my project, by just moving something on the front panel, and save the changes it corrects itself permanently. I have no idea which VI/s is at fault, but something is buggy. This is another reason why human readable source files would be useful, so that end-users can actually track down the source of potentially problems.

 

Recompiling all VIs doesn't work.

 

Anyway, I appreciate AQ's candidness on the subject.



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/