Jump to content

Recommended Posts

Here is the set-up:

 

I have a component project library (StepperMotor.lvlib) that I have moved to the userlib in order to facilitate reuse over multiple projects.  Within the library I have

1) a strict typedef (StepperMotor.ctl) cluster that contains a numeric control for expressing the maximum output step rate.

2) the StepperMotor.lvclass, an abstract class that contains effectively virtual methods (they do nothing but wire inputs to outputs) and LabVIEW-generated accessor methods for the two items in the class private data.

This is LabVIEW 2013 SP1 on Windows 8.1.

 

 

OK, so I start with everything clean (git status reports clean, LabVIEW opens and closes the library without prompting for changes).

1) Then I open the StepperMotor.ctl directly from Windows Explorer (hence not opening the library), change the range of the numeric from 2 kHz to 4 kHz, and save it.

 

 

2) Then I open the library, make no further changes, and attempt to close the library.  LabVIEW correctly prompts me to save changes.  I opt to close the project without saving changes, however.

 

3) Next I discard the change to StepperMotor.ctl using git.  (I have been using Discard in SourceTree, or a git reset --hard command.)  Then git status returns a clean status.

 

4) I open the project and attempt to close it.  Since I have reverted all changes, LabVIEW does not prompt to save changes.

 

So far, so good.  This is expected behavior.

 

Now, I repeat the steps, except that in step

1) I open the library first, open the typedef control from the project, make the same change, save the control (without applying the changes), and close the project (without saving).

2) is the same as above (OK).

3) is the same as above.  Again, git status shows me everything is clean.

4) I perform the same action as above, but this time LabVIEW prompts me to save all the accessor methods on the class, citing a changed typedef (even though if I open the typedef the range is indeed back to its original value).  This is unexpected behavior.

 

Worse yet, even if I perform a git reset --hard and verify with a git status that everything is clean, if I open and immediately attempt to close the project, LabVIEW still prompts to save, citing "Type Definition modified".  This is indeed problematic.

 

(Further note: If I let LabVIEW save the changes, git status still shows clean, and LabVIEW opens and closes the project without prompts.)

 

 

 

 

post-6989-0-15856100-1395249831.png

post-6989-0-06952900-1395250001.png

post-6989-0-59620500-1395250294_thumb.pn

Share this post


Link to post
Share on other sites

I didn't read this discussion closely enough to see if you were already part of it, but if you haven't read it, I think it touches on your problem. Steven Mercer talks about the differences in typedef behavior between different LabVIEW versions and says 2014 vastly improves upon this.

 

https://decibel.ni.com/content/thread/20339

Share this post


Link to post
Share on other sites
Do you have compiled code separated?

Yes

I didn't read this discussion closely enough to see if you were already part of it, but if you haven't read it, I think it touches on your problem. Steven Mercer talks about the differences in typedef behavior between different LabVIEW versions and says 2014 vastly improves upon this.

 

https://decibel.ni.com/content/thread/20339

Yes, I have seen that thread.

 

Yes, there is a nebulous promise that NI is working on something, but whether or not it will address this specific issue is unknowable from that thread.

 

I understand the font issue as a cause, but that clearly is not the cause in the problem I have presented.

Share this post


Link to post
Share on other sites

Note: In post #1 where I have "project" I should have written "library".  In this specific example I only used the library interface, although the results are the same with the project interface.



Another note: LabVIEW wants to save all the accessor methods, even those that deal with the other attribute of the class.  On the other hand, the *almost* virtual methods that are also members of the class have object instances (in and out control and indicator), but LabVIEW does not feel the need to save these.  This may show the problem is with the class private data bundle/unbundle nodes.

Share this post


Link to post
Share on other sites

I've seen similar behavior. I managed to isolate a pretty simple example and sent it in with the CAR I quoted in the linked thread.

Paul, I have no advice other than showing it to an AE if you can isolate the code and aren't prevented from giving it to NI. This issue has been an issue for years and the more examples NI can get, the more hope there may be of fixing the behavior.

Share this post


Link to post
Share on other sites

OK, thanks!  I did submit open a support case yesterday, too.

Share this post


Link to post
Share on other sites

NI Support said this was a known issue and will be addressed in a future version. CAR  451107.

  • Like 1

Share this post


Link to post
Share on other sites

Nice. Same CAR. That makes me feel better-- that the problem has been characterized enough such that it has been identified as the same issue in multiple requests.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By Francois Normandin
      As I've reported in the UI Tools support page, I've started migrating the open source code I still have on bitbucket (Mercurial-based repos) to Github.
      I didn't think that it might be worth a specific topic until @LogMAN mentioned it. Personally, I'm moving my code to Github in the process. I know there are some reports of Hg-to-Git transitions not going so well when using sub-repositories, so please share your migration experience if you've had to jump into some hoops to get it done!
      For all of you who still use Mercurial and host your open source and/or enterprise repos on Bitbucket, this blog post is worth reading:
    • By The Q
      The QControl Toolkit by Q Software Innovations is an object-oriented and extensible alternative to XControls. Use the QControl Toolkit framework and the QControl Creation Wizard to create QControl Classes and receive the benefits of XControls without the headaches. Take advantage of easy UI logic code reuse. Encapsulate and decouple the UI logic away from the business logic of the main application and from the UI skin. Use wherever the VI Server and LabVIEW object-oriented programming are allowed. Easily extend the capabilities of current LabVIEW controls through access to all properties available at run time. And easily use the toolkit with more complex frameworks like the Actor Framework or other plugin architectures where LabVIEW libraries and packed project libraries are used and where XControls can behave unpredictably. 

      Check it out now on the NI Tools Network here.
      I also started a thread on the NI Community: UI Interest Group page, here.
    • By etgohomeok
      I use SVN for version control in my project and am often faced with many conflicted VIs that must be dealt with. I have found that frequently, the changes causing these conflicts are not "real" changes (for example, a wire was moved or a typedef for a cluster control was changed). So, I am trying to create a tool that queries my project directory for any VIs that have conflicts, and running the VI Comparison tool with only non-cosmetic changes enabled to automatically find VIs that don't have any "real" changes and marked the conflicts as resolved. I would like to build the tool into a .exe because I would like to be able to run this tool from the command-line so that I can create a right-click menu item in my Windows environment to easily run the tool from any folder containing conflicted files.
       
      I found vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi which performs the comparison operation, allows me to specify which types of changes to detect, and returns if there are differences. This is exactly what I need and it works perfectly in the development environment. However, when I build my tool to a .exe file, I get a LabVIEW error with the following description:
      Error 1574 occurred at Open VI Reference in SCCSup Compare Two VIs.vi->Resolve False Conflicts.vi Possible reason(s): LabVIEW:  (Hex 0x626) Cannot open a file with separated compiled code in the LabVIEW Run-Time Engine. An error occurred loading VI 'my.vi'. LabVIEW load error code 59: The source file's compiled code has been separated, and this version of LabVIEW does not have access to separated Where my.vi is the path to the VI that it is attempting to compare. All of the VIs in my project have "Separate compiled code" enabled since I use version control on them, therefore turning it off it not an option. Is there any way to get around this issue?
    • By odoylerules
      All,
       
      Recently I moved from SVN to GIT as my source control and revision manager.  I'm still getting used to everything so i don't consider myself an expert yet, but i really missed the Project Provider options that I used for SVN source control within the project window.  
       
      I'm releasing an open source beta project provider for TortoiseGit Integration.  This addon is very similar to the current SVN options but was developed entirely from scratch.  Currently this provider requires TortoiseGit to perform most of the Source Control Actions.  I know a lot of you on here have recently switched to sourcetree, however, unlike TortoiseGit they do not currently offer a command line interface yet for windows that i could find.  I've tried to make this project flexibile and if they offer a command line for windows eventually it should be fairly quick to re-factor for that.  
       
      The project can be found here: https://bitbucket.org/jed_d/lv_tortoisegit
       
      Addon Features
      Tortoise Git Icon Overlays within Labview IDE Tortoise Git Commands from within Labview IDE Ability to directly reload a project from within the Project Window, as well as prompts to reload the project when performing actions that require a reload. Open Git Bash from project window

       
      I'm hoping some of you will have a chance to try this out and let me know of any issues.  I would like to track issues on bitbucket if possible so that they are all in one place, but i will also be checking these post for issues as well.  
       
      Feel free to fork the project and hack on it yourself.  If you come up with something decent and don't mind sharing, send a pull request.  
       
       
      One initial issues i'm hoping the community can help with is building the package for older versions of LV.  Currently i only have access to 2013 so i am only able to build the package for this version.  If anyone has a change to pull down the repo and build it for older versions please do.
       
      Another question i have for the community is the license i currently have on the project.  This is my first open source project of any kind so i wasn't sure what license to put on it.  I did not want to be too restrictive so i went with a BSD license.  If any of you see an issue with this please let me know as I'm open to suggestions.
    • By bigjoepops
      I am getting started with using TFS for source code control with LabVIEW.  I am using TFS 2013 and LabVIEW 2013.
       
      I have a few questions:
       
      What is the best way to move files from one project folder to another?  The "move on disk" doesn't appear to be a good option.  I want to be able to make file moves if needed and don't want my project to end up blowing up with conflicts.
       
      It appears that once source control is set up in LabVIEW that all check in/check out operations need to happen in LabVIEW and not TFS or windows explorer.  Correct?
       
      I just noticed the "Include callers when checking out files" option.  I am assuming that is probably a good option to select so that they callers will be modified and saved as needed.
       
      Does having files set up as auto populating have any negative effects on how source control is done?
       
       
      Unfortunately it appears that we are stuck using TFS for source control since the firmware developers are using it and it is a company application now.
       
      Any help or guidance you can provide would be appreciated.
       
      Thanks.
       
      Joe
       
       
       
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.