gmart

QUOTE(crelf @ Feb 19 2008, 04:00 PM)

I assume you put the quotes there because you disagree? I know why it happens, but I still don't think that it should. Each instance of the constant retains its' size when I move it, save a VI, etc, so why does it reset when something unrealted to size changes in the typedef source? Why can't each instance remain the size it was? I assume that it's easier for you guys to have each instance simply replaced, but when you have large (real estate-wise) constants in multiple locations, it can be a real pain resizing them all. It may not be a bug per se, but I certainly think that it's an unwanted "feature".

I have been bitten by this behavior as well so I share your frustration. I said "bug" because from the standpoint on what the data typedef behavior is, the behavior is expected - the data is replaced (though obviously not desired for the display aspect). We've tossed around separating a data change versus a display change for typedefs. More feedback from the community sure helps in decision making .

I'm curious. What is your objection to an option of having constant icons?

QUOTE(cmay @ Feb 19 2008, 02:47 PM)

Couldn't you just make a VI that only contains the type def and wire that to the output? Then you only have the VI icon on your block diagram instead of the huge type def constant.

Yes you could and that is what many people do, but then you are adding to your VI hierarchy, could make extra copies of the cluster, and may be losing out on optimizations such as constant folding.

QUOTE(crelf @ Feb 19 2008, 02:09 PM)

The "bug" happens when you change the data type of the typedef. This is due to the fact that typedefs don't have a display state separate from the data state. So the typedef is reinitialized to it's default size whenever the data changes.

What does it mean to commit with this type of UI? Does a commit happen when you enter a zone around an area? What if I didn't want that to mean commit? I think the "instant action" behavior would probably lead to confusion and frustration. What if moving over a graph caused a hardware action? I think there is still the need to click an object to convey the message that the user wants an action to occur.

QUOTE(Aristos Queue @ Dec 12 2007, 02:26 PM)

A class will stay in memory as long as there are any data instances of the class lingering around on VIs that aren't members of the class. That means hiding in the operate data of controls/indicators (controls of type LabVIEW Object or LVVariant are common hiding places), or even just sitting in terminals.

The inability to close the .ctl window is a new one. I haven't heard of that before. If you can get it reproducible, please post it to ni.com so it gets investigated and CAR'd.

Another "hidden" place is the magic clipboard where LabVIEW items go when they are copied. If you copy a class (I think via CTRL+C), the class is copied to the clipboard and will hang around in memory until the app instance is released (I think).

QUOTE(jdunham @ Nov 29 2007, 02:40 AM)

We have a big project and none of our builds worked when we tried to use our 8.2 lvproj files. They just failed with errors with blank error descriptions. Everything was fine when we started from scratch (after a couple of wasted days and some tech support). The lvproj 8.2 -> 8.5 upgrade seems to be just hopelessly broken. :headbang:

I would be interested to know specifics on what problems you had when you tried to work with your 8.2 project in 8.5. What exactly didn't work?

QUOTE(lavezza @ Nov 26 2007, 11:17 AM)

You're right. After my last post I took another look and realized it was easier than I thought. I'm not sure how I missed that the last time. I think it would be fairly easy to take the P4CMD folder and make an equivalent for SVN (or any other SCC that has a command line interface).

Pat

Good luck and I look forward to seeing an SVN command line plugin in the future :thumbup:

QUOTE

I've looked at the Perforce specific VIs and came to the same conclusion. I didn't dig much deeper than that but I did see that there are other things that would need to be done for it to work. For example, the preferences for LabVIEW only display Perforce and providers that have MSSCC interfaces, but only if they are installed. And it looks like the code that determines which VIs to call is locked. There needs to be a way to tell LabVIEW 'Add Subversion to the list of SCC Providers and call the VIs in the \vi.lib\SourceControl\Providers\SVNCommandLine folder'. There may be a way to do this now, but it certainly isn't documented. Adding provider specific menu items to LabVIEW would be another (currently impossible?) task.

You are correct that the mechanism is not documented but that doesn't mean that it's not extendable. The list of VIs in the "sccapi" directory should give you an idea as to what VIs need to be written for a new plugin (as a hint, "Find All Providers" is where the list of "installed" plugins is returned to the SCC config page). As far as provider specific menus, the task is not impossible, but if you want to go down that road, I would again suggest you talk to your sales rep and see what arrangements could be made to give you more information.

I think it would be great if the LabVIEW developer with domain expertise with various SCC plugins developed custom SCC providers. Maybe someone could develop an SVN plugin for LabVIEW so I'd quit hearing about how Tortoise SVN is the best thing since sliced bread

QUOTE

Our current project has 6554 *.vi or *.ctl files. Having an "All VIs" vi is not an option

Why is this an issue? Are you concerned with possible slowdows or memory usage?

QUOTE

Having separate source and object code is a long standing request. Just because it hasn't happened doesn't mean it hasn't been considered.

QUOTE

If you are interested in this, I would contact your sales rep and work through the system to see if something can be arranged. It would be great if the LabVIEW community would develop custom SCC providers. If you wanted to work with the functionality that is currently there, let's just say that it wouldn't be too hard to look at the current provider implementations and deduce your way to a functioning SCC backend :-)

There's a lot to digest so I hope I get it all.

QUOTE

• The low level NI SCC are password protected so that is a pain.

• The NI SCC tools for the Clearcase interface work at to high a level and do not give you anything useful to work with for an advanced ClearCase user or admin, for example the SCC File Properties.vi and the SCC File History.vi launch the ClearCase properties window and History browser respectivly, there is not a lot you can do with that. Whereas to generate a bill of meterial I want to a File Properties VI to return a string I can then work on. There is an advance option input to both these VI's but with no documentition on the format or API of these (that takes me back to point one)
  
  

• There is a large amount of ClearCase functionalilty not available with the exposed interface (I am sure somebody will correct me here
  
  ), getting or even changing a ClearCase view configuration specification, getting a list of files on a branch, get back checkout / check in commets applying labels baselines and much more. ClearCase can be a great tool, but only if you spent time getting this level of stuff working to help you.
  
  

• What settings there are for the configuration of using their VI like "checkin even if identical" are up at the configure source control advanced level. If you are trying to auto builds / labeling / deployment you need to do these things programatically.

  
  The interface to Clearcase is via the Microsoft SCC Interface which is generic in order to support many SCC providers. So as you have pointed out, you don't get detailed functionality for each provider but from LabVIEW's side, we are able to interface with many providers without having to write custom backend code. The intent of the SCC tools in LabVIEW is to allow you to do the basic, everyday operations from within LabVIEW without having to use the SCC client. More advanced functionality needs to be done from the SCC provider. Regarding the advance option input, support for that input is based on the provider and would be extremely difficult to document the usage to most users. It is mainly used by LabVIEW's SCC tools.
  QUOTE

  
  

• Finally, and I am not sure if I can explain this correctly but the built in SCC for ClearCAse seems to be built more around ClearCase UCM and not the far better (IMHO) Base ClearCase. The source control Project concept in LabVIEW for ClearCase at anty rate just does not work for me. I have several views and branchs on the go at any one time (1 view = 1 branch = 1 fix) when I finish with a view to goes, in fact to get LabVIEW Clearcase interface working I have a fake view mounted all the time just to stop LabVIEW complaining when I lauch it with a newly created view.

  
  LabVIEW calls generic functions via the MS SCC interface and Clearcase determines what support it provides. So if Clearcase decided the UCM interface was what they wanted, that's what you get.
  

I've avoided the discussion about why LabVIEW marks VIs as needing to be saved so I can focus on the SCC related issues. There is an option in Tools>>Options>>Environment - Do not save automatic changes. Here is the help for this option:

• Do not save automatic changes—Does not prompt you to save any changes automatically implemented by LabVIEW. You do not need to save these changes because LabVIEW implements the changes each time the VI is loaded. Changes automatically implemented by LabVIEW include recompiling, converting from an older version, and updating type definitions or fonts. This checkbox is unchecked by default.
  

The option is slaved to the "Treat read-only VIs as locked" option but you may find that you want that behavior anyway.

I'm glad you are able to write VIs to perform the operations that are not intrinsic in LabVIEW. I'm sure others will benefit from the work you do if you post to a code repository.

QUOTE(Staffan @ Nov 21 2007, 03:49 AM)

When working with LabVIEW and Source Code Control, it quite often happens that vi:s need to be saved due to subvi recompilation.

Even if "Checkout Callers..." is checked, those vi:s are not always checked out by LabVIEW when the vi to be modified was checked out.

This is also happens when working with LabVIEW classes. Making a changes in one class makes may affect other classes.

To solve this when using Perforce as SCC, I checkout all vi:s (in Perforce), save all vi:s (in LabVIEW) and the "Revert Unchanged Files" (in Perforce).

When using Clearcase I havn't found an easy way to do this.

Why doesn't LabVIEW always know of which files to check out?

Any suggestions on how to make it more easy when working with LV/SCC?

/Staffan

In order for "Check out callers" to work, the callers of a VI have to be in memory. The same goes for classes. What I typically have is a "All VIs" VI and load that while developing. This pulls all my working VIs into memory and when I check out a VI who has callers that are not checked out, those should be included in the list of Calllers. This should apply for all SCC providers.

QUOTE(Paul_at_Lowell @ Oct 12 2007, 08:00 PM)

Generally, we can create an override method for extension or replacement of the parent method. (The parent and child methods must have dynamic terminals and identical--except for the class objects--connector panes.) In LabVIEW 8.5 (nicely improved from 8.2.1 in the options availabe!) when we right-click on a child class and select New... VI for Override... from the shortcut menu the VI template used is better suited for extension. (There is already a call to the parent method. One can add further behavior to the block diagram.)

The question is, what if we want to create an override VI that we will replace the parent VI method's functionality? In LabVIEW 8.5 we can do this as follows:

1) Create an override VI as above, delete the call to the parent method, and add the functionality to the block diagram. (Unfortunately the template isn't set up as nicely for this as it was for the original VI. We have to add space and a case structure to get to the same place.)

2) Create a New... VI from Dynamic Dispatch Template in the child class. This is probably the easiest path currently. The drawback here is that the connector pane may very well not be the same as it was in the parent VI. (In particular, if we had any inputs or outputs that aren't part of the default template in our parent VI, then the connector panes won't match.)

3) Save a copy of the VI to replace from the parent class to the child class. Unfortunately we have to replace the parent class objects manually with the child class objects, update the labels (a separate step), and remove any existing code we don't want.

These are the paths I know to accomplish this. Solution 2 seems to be the simplest solution for me, but it's not great. Hopefully the next LabVIEW release will have a New... VI for Override for Replacement option that will combine the best parts of options 1)--ready-made connector pane and 2)--code-ready template with empty case structure. Personally I would prefer this for the override template in any case. I'd like to have the case structure and add the call to parent method wherever it is appropriate.

Would you expect that the new VI would have a copy of the parent's code (essentially a Save As with patched up object references) or do you just want a case structure INSTEAD of the Call Parent Node?

QUOTE(Jim Kring @ Oct 4 2007, 11:07 AM)

I wouldn't say that File I/O functions never worked with LLBs -- a few of them do. For example, the File Exists? function works with LLBs (although I think there is/was a bug that prevented it from doing when running from a built application).

http://lavag.org/old_files/monthly_10_2007/post-17-1191513865.png' target="_blank">

And, I'm sure Mikael's probably right about the change in behavior of his application that used the Copy primitive

Also, don't forget that you can store LabVIEW class (.lvclass) and xnode (.xnode) files inside LLBs, too, as well at run time menu (.rtm) files and a few other esoteric LabVIEW file types.

Cheers,

-Jim

I should have been more clear. The File I/O functions (primitives) don't work with LLBs. Some of the File I/O VIs do. And I should have said project libraries and their variants (lvclass, etc.). Thanks for cleaning up my mess, Jim :thumbup:

QUOTE(MikaelH @ Oct 3 2007, 07:08 PM)

This is not a bug, just a change of how the Copy function works.

The Copy function don't support files in the LLB any more.

Does that mean that LLB's soon are unsupported

I got quite when my application stopped working when I recompiled it to 8.5

http://lavag.org/old_files/monthly_10_2007/post-941-1191456372.png' target="_blank">

//Mikael

The File I/O functions have never worked with files in LLBs. The confusion is that the documentation was updated to actually make that clear (ironic, huh?).

As far as what can go into LLBs, in addition to VIs and CTLs, you can have project libraries (.lvlib) in LLBs as well.

QUOTE(george seifert @ Sep 27 2007, 02:53 PM)

I suppose they looked somewhat similar. At least one of them was pretty big. This one is fairly small. The big one had the shift register initialized outside the loop so I don't think that's problem. It's curious that it worked when I moved the control out of the case I was trying to duplicate. The VI was even broken because I didn't bother to delete the wire after I moved the control. I've duplicated cases that have local variables and porperty nodes in them. Guess I'll have to do some more experimenting.

George

See discussion at NI Dev Forums - http://forums.ni.com/ni/board/message?boar...mp=true#M275833

QUOTE(jaegen @ Oct 2 2007, 11:29 AM)

Could it be related to http://zone.ni.com/devzone/cda/tut/p/id/6449#3IKBUP99by%20Category' target="_blank">Known Issue #3IKBUP99?

Jaegen

A bug report has been filed with R&D - 4E1B60P2.

QUOTE(torekp @ Oct 1 2007, 06:49 AM)

Sometimes you just haven't left yourself enough extra connectors on the connector pane and you need to change your subVI's connector pattern. Or you find a strange behavior in a subVI (how it handles negative numbers, maybe) and you want to change it but can't remember how your other projects used this subVI. Maybe they needed negative numbers to be handled in that strange way. However we get there, I think most of us have had the experience of changing a subVI for the sake of one caller, only to break another calling VI in a different project. I know I have.

Can any Source Code Control provide a security check against this? That is, can it notify me when I try to check my subVI back in, "this may affect ProjectX.vi and ProjectY.vi", or some such? I haven't selected an SCC provider yet, but I was looking at Microsoft Visual Source Safe and didn't see it.

If you use the SCC integration in LabVIEW, there is a mechanism provided that may help. There is an option (which is on by default) that if the callers of your subVIs are in memory, when you edit or check out a VI, you will be prompted to check out your callers. So this check isn't on the check in side of your workflow, but should at least get all the callers checked out in the case you change a connector pane or something along those lines.

QUOTE(Jim Kring @ Sep 11 2007, 10:30 AM)

I misspoke (it was late when I wrote that). Yes, all VI dependencies are added to the build. What I meant to say is that in order to target VIs to a specific destination, they must be beneath My Computer (and no longer in the Dependencies).

Ok, that makes more sense. You can send dependencies to a defined destination, but it has to be ALL dependencies. You can't pick and choose. To do that, you need to move them under My Computer.

QUOTE

I'm not sure if your use case is THE reason for autopopulating folders. I think a major motivation was being able to have some control from the project over the physical location of files. The current implementation may not be the ideal for all users, but I think it helps many who have wanted the feature.

Even without autopopulating folders, you can still achieve what you want. It requires you to structure the project such that all .svn files are in one folder. That way you can control the actions of those files via the folders settings in app builder. The organization is pushed to the project versus having options in app builder. Again, perhaps not the ideal case, but it is doable.

QUOTE(Jim Kring @ Sep 10 2007, 10:02 PM)

In the LabVIEW project environment, anything that is a Dependency (or not explicitly in the project under My Computer) is excluded from the build.

I don't understand what you mean. Let's say you have a top level VI which has a hierarchy. The only VI in the project under My Computer is Top-Level.vi. If you create an executable build specification and build it, the hierarchy of Top-level.vi will be included in the build. Now, if what you mean by dependency are support files that are not part of a VI's hierarchy, then there is a mechanism to manage that. You would need to add them under My Computer and then make them "Always Included". I'm not clear as the what behavior is lacking.

One thing you could do is remove the problem file from the project. When you load the build specification again, it will not be present. This is not ideal, but it should get you going without having to manually edit the project file. Also, it seems the problem only affects non-VI files. If you have the same setup with a VI, you will not get the same behavior.

QUOTE(paracha3 @ Aug 30 2007, 04:35 PM)

The only reason i wanted to write a plugin is because LabVIEW project shows you nice status of each file in project view. Also (not sure about this one) doesn't labview also automatically checkout all the called subVIs when you check you the top level caller? And also i think as soon as you start editing a checkin VI, that it prompts you like "This VI is checked in do you want to check it out? YES NO?".

I agree those are nice to have features. I am comfortable with DesignSync command line interface but the engineers who will be working with this will definitely find it hard because they have no previous exp with SCC what so ever. I just wanted to make it easy for them to do SCC operations from within LabVIEW env.

I guess i will have to write some utility VIs that would nicely wrap the commands for check in and check out etc.

Thanks for all who responded.

You are correct in regards to the benefits of using the source control integration within LabVIEW. The status indications are good. I think one of the most helpful features is the prompting on edits. This feature helps me not have to worry about remembering to check out the file I'm working with as well as can display calllers of a certain file so that if you change a connector pane, the callers will get checked out as well.

Sorry there is not a better solution for you in regards to DesignSync. I would try to contact them (if you haven't already) to see if they do have a plugin for third party IDE's before giving up all hope

QUOTE(tcplomp @ Aug 24 2007, 11:34 AM)

It works! I can browse my own repository with LabVIEW :thumbup:

There's a trial license for a period of time (which I don't know)

So that's great news!

Only the 'Show Differences' doesn't work.

Does anyone have used this with an SCC?

Maybe I can try it with the LabVIEW VI to do the diff.

As my post shows it will most likely work!

Ton

Trying to convince a LAVA guy who uses Tortoise SVN to use anything else is not a winning proposition I have found . The PushOk plugin seems to allow the basic operations. Perhaps it has more advanced functionality, but most of that was not tested with the integration to LabVIEW. I believe Show Differences was tried and it did work. I'm not sure why it would not work (unless they've changed something in the meantime). I'd say keep working with the plugin to see if it satisfies your current needs. Obviously if it does not, there's other alternatives.

After some searching, I found this article - http://www.matrixone.com/pdf/ds_designsync.pdf. Here's the relevant bullet to this post:

Plug-in for Source Code Control for Software

Components

ENOVIA Synchronicity DesignSync includes a plugin

for the Microsoft Visual Studio IDE (Integrated

Development Environment.)

So, since this plugin exists, in theory, you should be able to hook into it from within LabVIEW. Give that a try and let us know how it worked for you.

QUOTE(Michael_Aivaliotis @ Aug 23 2007, 12:10 PM)

I agree with jaegen on this one. Single EXE build needs to be a future feature. This restriction alone will turn off many from adopting Classes. Let's not forget that people (including myself) have been building successful test systems for 20 years before classes were introduced. Even without classes, work can still go on as usual - until NI forces us to use classes (which they probably will). I'm in favor of classes, I'm using classes in customer projects, but the more gotchas you present, the harder it is to convince people.

I'm not sure what you mean by "gotchas". The current behavior is a result of the current mechanism used to build applications. It affects regular libraries as well but is not as big an issue there since a rename doesn't have the same impact as with a class.

We are aware of the need to improve how we build applications and are looking at how the process can be improved.

QUOTE(jaegen @ Aug 23 2007, 10:50 AM)

Is this considered the final solution to this issue? I really hope that the end goal is to have a single *.exe with all the VIs inside it (with names "mangled" like they already are in the development system). Jim's "http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' target="_blank">security through obscurity" issue is minor compared to having individual VI files out in the wild with every built executable.

Jaegen

We are looking at ways to not have to place code outside of executables. For those who use the Mac (and you know who you are), built apps are one "file". The reason is that on the Mac, apps are folder-ish. So send your thanks to Steve Jobs on that one.

Just in case this was missed, with a project window active, you can press CTRL+F (Edit>>Find Project Items..) and the "Find Project Items" dialog will come up. In the dialog, you type the name of the VI and press Find and you will get a list of all the items that match the search text. You can then double-click on the result and it will be located in the project. This works for any project item, not just VIs.

In addition, in a project, you can right-click on a project item and select Find Callers or Find SubVIs.