gmart

QUOTE(crelf @ Feb 19 2008, 04:00 PM) 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) 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) I don't agree with replacing constants with icons, but I certainly would like to see the resizing typedef bug fixed. 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) 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) 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) Good luck and I look forward to seeing an SVN command line plugin in the future :thumbup:

QUOTE 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 Why is this an issue? Are you concerned with possible slowdows or memory usage? QUOTE I would like the option of saving source and object code separately and the option of saving run time menus in the source. 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 As for the integration into the LV editor, it would be nice if the interface was opened up a little. Obviously there are limits to what can be done with MSSCC. Couldn't NI provide a way to let you develop your own VIs that are called when the SCC menu options are selected in LV. Right now the Perforce VIs call the Perforce command line. Someone could to the same thing for Subversion. If the SCC menus were configurable, someone could develop VIs that call the ClearCase command line (or use ActiveX?) for the advanced options that aren't supported by the MSSCC API. I think that NI could definitely update LV so that the SCC integration is more of an API. They could provide the basic MSSCC and Perforce VIs and let the community develop more advanced options. 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 implementation VIs for the providers (Perforce, WinCI) are for the most part not password protected. The VIs used to implement the SCC functionality are password protected but that should be expected. QUOTE 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) 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) 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 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) 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) 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) A bug report has been filed with R&D - 4E1B60P2.

QUOTE(torekp @ Oct 1 2007, 06:49 AM) 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) 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 And, as I mentioned, OpenG Builder treats support files differently from VIs and is able to handle wildcards and recursion. For example, you can do things like add a folder's contents recursively, but exclude any folders that are named ".svn" or "CVS". You can also do things like include all files named "*.ini" from the "configs" folder. These sorts of features are the reason why people want autopopulated folders in the LabVIEW Project Environment. 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) 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) 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) 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'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) 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.