Jim Kring

Take a look at this knowledgebase entry: Run Reports in FogBugz. It contains an overview of the reporting features that FogBugz does have, why it doesn't have others, and links to a couple of third-party add-ons.

We use FogBugz. It meets all your requirements except "open source" and "Comprehensive reporting functions". It's not open source, but it is not very expensive. I looked hard, and could not find an open source solution that met my needs (bugzilla, mantis, trac, etc). FogBugz doesn't have extensive reporting functions, but there is a third-party tool that provides reporting. Actually, Joel Spolsky (Fog Creek founder and Joel on Software blogger) says that too much reporting detracts from fixing bugs and other important stuff -- for example, if you measure project success by the lack of bugs or the rate they are fixed, then people will focus on not reporting bugs and closing them as soon as possible. That said, FobBugz does have good reporting and notification, where it matters, e.g., issues that are past due, etc. -Jim

Here's another little gem... Modify a MS Word document in your SVN sandbox (that is already under revision control, so that it shows up as modified) and then select TortoiseSVN >> Diff. You will see the all the differences as track-changes modifications (additions and removals) in the resulting document that opens in MS Word :thumbup: Congratulations on the upgrade! Cheers,

LabVIEW has nothing to do with setting up an SVN repository. And, unless you only work on a single LabVIEW project, you can forget about using the Source Code Control integration with the LabVIEW project environment. But, that's OK. Once you get used to TortoiseSVN, you'll rarely feel the need for anything else. As far as setting up a repository, this can be a little tricky. I prefer using apache for providing the network, and encryption (SSL). I use an authorization file containing users+passwords and have also set up systems that use NT Domain authentication. There is pretty good documentation on how to do this, inside the TortoiseSVN online help.

I asked NI for this a long time ago. They told me not to hold my breath.

I linked to the wrong posting, see here: "Wait on Notification from Multiple" output values can be wrong on timeout

Regarding the handling of errors in this VI, I just posted some additional comments (here), which are shown quoted below.

Stephen, Thanks for pushing things forward on your side. One more thing... the description of the "notifiers out" indicator (which is shown in the context menu when you hover over the indicator) states: "notifiers out is the entire array of notifiers in, unless an error occurs. If an error occurs, notifiers out contains only those notifier refnums that caused the error." However, this is not the actual (or the desired, IMO) behavior. If some notifiers are received before the error occurs (for example, if one notifier becomes invalid after others are received), then the notifiers and notifications received should be output to "notifiers out" and "notifications" (respectively). I don't think that it is entirely possible to know which notifiers caused the error, since the "Wait on Notification from Multiple" primitive does not tell you which notifier generated the error. We could infer which notifiers caused the error by checking if any of them are Not a Refnum. But, in any case, the user of this VI could make this check, themselves, if an error did occur. If this VI does actually need to output an array of notifiers that caused the error, then I would prefer if this were an additional output ("notifiers with errors") and we used "notifiers out" to contain the notifiers that were actually fired. Thanks a million!

This bug also appears in 8.0. See this posting.

[CAR 45E9BHJ1] If an error occurs while waiting on notifiers, previously fired notifiers are lost, as the \"notifiers out\" array is emptied. This bug is caused by \"Wait for All Notifications Sub.vi\" (vi.lib\\utility\\Wait for All Notifcations.llb\\Wait for All Notifications Sub.vi) clearing the \"fired notifiers\" array.

This bug also appears in 8.0. See this posting.

[CAR 45E9BHJ1] The "Wait for All Notifications.vi" VI (vi.lib\Utility\Wait for All Notifcations.llb\Wait for All Notifications.vi) always outputs an extra null (empty string) notification as the 0th element of the "notifications" array of strings. This is caused by a shift register that is initialized with a string array having one empty-string element -- this should, instead, be an empty array.

This bug also appears in 8.0. See this posting.

[CAR 45E9BHJ1] The "Wait on Notification from Multiple" function seems to have a bug in how it sets "notifiers out" in the case of a timeout. If an instance of "Wait on Notification from Multiple" is called successively (for example, in a loop), calls that timeout will pass out notifiers (in "notifiers out") from previous calls which did not timeout. I would expect "notifiers out" to be an empty array if the function times out. See "TEST - Wait on Notification from Multiple.vi" (attached) for an example that demonstrates this bug. In this example, "Wait on Notification from Multiple.vi" is called twice in a For Loop. On the first iteration a notification is successfully received and on the second iteration a timeout occurs. On the second (timeout) iteration, the value of "notifiers out" contains the notifiers that there fired on the first call. I would expect "notifiers out" to be an empty array if the function times out. Download File:post-17-1168812196.vi

Steve, I just tested in LabVIEW 8.2 and I don't see any issues. Here are my results: Array Size, Time in Seconds 10, 0.015625 25, 0.03125 50, 0.046875 100, 0.09375 1000, 0.53125 10000, 6.75 I'm going to stick with my guess that you were hit by the Major LabVIEW Slowdown (Several 100 time slower) bug. Thanks,

Yen, This is a great solution! I didn't even think of that -- I just tested and it works in 8.2. Thanks, Jimi, No, the To More Specific Class function will not work, since a StringConstant object is not a more specific type (subclass) of a String (control/indicator). StringConstant inherits from Constant and not Control -- if VI Server objects were implemented using multiple inheritance, then maybe both could simply inherit from the String datatype, but that's a different discussion. The reason that the typecast solution works, is that property/invoke nodes don't do type-checking at run-time (they rely on LabVIEW's type checking of wires in the editor) -- they only check to see if the input object has the properties/methods that are being accessed/called. And, the StringConstant VI Server object does have a Text attribute, but it simply hasn't been exposed yet in VI Server. This is akin to duck typing -- if a StringConstant has a Text attribute, then reading the Text attribute should work (even if the StringConstant is masquerading as String control, as long as nobody checks to make sure that it is really a String). Thanks,

Matthieu, I have moderated your posting. Please refrain from the use of profanity. It does not promote the positive/constructive atmosphere that we work so hard to foster, here on LAVA. We are very forgiving of poor english, but don't like bad language. Thank you, -Jim

That's a short question with a long answer. See here: VI Scripting Forum - Readme First

I'm trying to get a reference to the Text of a StringConstant (so that I can set it's Justify attribute). I can get the Label attribute (which I'm not interested in), but the StringConstant does not appear to have a Text attribute, as the String (Control/Indicator) does? I'm using LabVIEW 7.1. Maybe this exists in 8.0 or 8.2. Any ideas? Thanks, -Jim

Hi Steve, It could be that you experienced this bug: Major LabVIEW Slowdown (Several 100 time slower) I'll take a look at your example and see if I see anything strange. Thanks,

Stephen, there is a bug in "Wait for All Notifications" -- it should be reentrant. I've reported this here and here. Thanks,

This bug appeared in 8.0. See this posting.

[CAR 45BGR0J1] The following VIs should obviously be reentrant (but they are not), in order for two parallel calls to work as expected: <LabVIEW>\vi.lib\utility\Wait for All Notifcations.llb\Wait for All Notifications Sub.vi <LabVIEW>\vi.lib\Utility\Wait for All Notifcations.llb\Wait for All Notifications.vi

Steve, There are a couple factors that could make this slow. 1st off, the NI Configuration File VIs are pretty slow with large data sets. Secondly, the OpenG Variant Configuration File VIs can be slow in certain situations. If you create a quick example VI that demonstrates your problem, I'll investigate the performance issue and let you know if we can improve things. Thanks,

That's right. Not any more. Take a look at my blog posting titled NISLA July-05 - The end of the beginning. NISLA - August 2001 (circa LabVIEW 6.1) stated that you could not build "general purpose tools" using LabVIEW. NISLA - April 2003 (circa LabVIEW 7.0) changed to state that an authorized application was solely determined by NI. Finally, NISLA - July 2005 (circa LabVIEW 8.0) authorizes all applications which are developed using a licensed version of LabVIEW. :thumbup: