Yair

I'm not sure if you can have VIs in inherited classes which have the same name and are not override VIs. Try reading this. That said, I'm far from an expert on LVOOP. This smells like a bug from your description.

I can't say I read that post (I mean, why would I?), but the word "gematria" caught my eye. For those wondering, it refers to the process of assigning a numeric value to each letter, summing these values and comparing these sums between words, as is demonstrated in that post. I can't say I saw anyone do it English, though. It is actually interesting to note that one of the Hebrew words for "God" also comes up to 26.

Well, since we're hijacking, someone had to do this:

The main problem I can think of is selecting which event structure it would be part of. Many people probably only have one, but that's not necessarily the case. I think that the problem is simply that the event configuration dialog isn't that great (yes, I'm understated, what can I say?). Perhaps an alternative implementation would be to select the control from the from panel (similar to how you associate a control in the connector pane) instead of the listbox. One shortcut you can use today is that you can type to jump to entries in the listbox. This applies to both the control selection and the event selection.

For "create subVI" this seems pointless, as the subVI is created based on the code you select, so there's no way to know in advance. For the new VI, you should be able to override this by placing a VI called lv_new_vi.vi in the <LabVIEW>\resource\plugins folder. Here are some details. I'm not sure, but you might have to write some code there (e.g. to have the called VI spawn a new copy of a VIT). See here for an example of using this method.

I think I like the idea of moving the error wire to the top. I did a quick mockup (no screenshot, sorry) and I think it actually looks good. Stephen, I would suggest that R&D play with it for a bit to see how it works. If it looks good NI could probably create a reasonably simple UI for automatically modifying the wiring of existing VIs based on a user request. Of course, I would probably like more the idea of better error handling, but that's another discussion.

QUOTE (crelf @ Feb 26 2009, 09:50 PM) Well, I happen to disagree with that one. The whole point of a subVI is encapsulating functionality, so why put a case structure around every single instance where I wouldn't want to execute the code? This takes time, takes space, creates noise and actually hides the functionality more IMO, since you have to look inside the other frame to make sure nothing happens there. You're not hiding the functionality if you say "NO filtering" in your input. The real problem here is using a numeric instead of an enum. I'm guessing that this comes from an old NI VI.

I think what you want is the reorder button, but I agree with Chris on the unclear terminology.

That post is spam and has been reported as such. QUOTE (jzoller @ Feb 20 2009, 08:19 PM) The increase should happen as soon as you open the refs. You should first do a test (with many millions of refs) where you open the refs and wait and then check the memory usage. I suppose there is a possiblity that you won't see the memory increase at all (e.g. if .NET is doing everything out of process), but I don't think it works that way. That said, I know pretty much nothing about .NET, so I'm not exactly an authority.

I had a quick look at the code and you would probably want to change the connector pane. The standard convention is using the top corners for references and the bottom corners for the error clusters. Additionally, you should probably get rid of the "lossless compression" boolean, as JPEG is useless when dealing with images like LV code. Just do PNG all the time. Another point is that in the final UI you would probably want to get rid of the folder name and just let the user select the file name, since you will presumably have a single file. It seems to me that parsing the subVIs should be relatively simple, as you already have the recursive parsing code. All you need is to check the depth of the call chain. Also, this is from memory, so it may be wrong, but you might be able to simplify the code by pushing all the objects in the top level diagram into the queue instead of dealing with them in the main VI.

This may have changed recently, but at least in the past, NI's "official" recommendation was to close ALL .NET references. See this post by Brian Tyler, who used to head LV's .NET team. This might have changed, however. Since the references have a clear scope, I can actually imagine NI releasing them automatically. Can you provide details regarding the tests you ran?

One nice feature the DBCT has is its parser which allows you to wire a cluster (as a variant) and it parses it into its datatypes automatically for inserts. This saves you some work. You can do this fairly simply yourself, however, if you start with some of the OpenG variant VIs, as they do most of the heavy lifting. The DBCT also has some convenient wrappers, which, if memory serves, LabSQL does not. Personally, I feel that the DBCT is somewhat lacking (e.g. it doesn't have an UPDATE wrapper, which I wrote fairly quickly and I don't really like the way it handles times, although I can't say I looked closely at it), but I don't use it enough to be able to really pass judgement.

I can't say I know the details of the GPL. Rolf seems to think that the restriction on calling executables is for purists and unenforcable and common sense would make me agree. However, you can also simply distribute it as a parallel capture tool with its own license. As for the features, you should probably think about the relevant uses and how much you want to invest in this. Personally, I think I would find something like this useful when posting an example on-line, and I would want the creation UI to be as minimal as possible (e.g. a single control asking how many levels down the call chain I would like to go. In most cases, I expect this would only be one or two). The coolest thing would be if the resulting flash file could have its own "window manager" which will allow moving the VI windows around, but a listbox with the open VIs is probably enough too. P.S. VIPreview is a good name. You can get an icon of a viper, similar to how LabPython uses a Python. You could probably even rename it to ViperVIEW or something, if you don't mind the lack of clarity.

I haven't looked at the new version yet, but I think it would only be practical in the real world if it ended up generating a single file and had a simple UI (which I understand you want to wait with until you get ahead with it). As mentioned, including it with the CCT would be great.

I did actually make the change I described here and I posted it to the other thread, but as mentioned there, it's not production level code. I didn't run it on a cFP, but on the PC it was faster. Either code has to do the recursion of the data structure, but the MGI code has the advantage that it doesn't have to manage the values, only to build them into a string.

QUOTE (rolfk @ Feb 9 2009, 03:31 PM) Which explains why I didn't remember it from DSC 7.0.

There are generic workarounds for handling continuous events. You can see a couple in this thread (Ton's post followed by mine). In the CCT, we used a separate loop with a notifier. The event loop sent a notification with each event firing. The processing loop had an explicit wait (which forces the loop to wait) and a wait on the notifier (to get the current data): The other option is doing the actual work in the timeout event and passing the actual timeout in a shift register.

I haven't done any of this, so this is just educated guessing. Subversion clients (or is it the server software? Can't remember) have the option of installing triggers (or whatever term they use) that fire on certain actions (a commit, in this case). I don't remember the details, but I believe these are created using scripts. You can probably create a script which will call an EXE you will write using LabVIEW and pass the data using command line switches. The EXE will then open a VI server reference to LabVIEW and use that to open and modify the VI. I would suggest placing the data in a tag (8.6 has tagging VIs in vi.lib) or in the VI Description property, but that depends on how you want to use it.

I would say that in the strict sense of "what is a password?" this is a bug. For the purpose of the argument, suppose I open a web browser and log into NI. Does that mean that when I go to LAVA I should be logged in automatically if I use the same name/pass combo? Suppose that someone decided to lock their VI and they just happened to choose the same password I did. That would mean that unlocking my own VIs would unlock theirs as well, even though I would probably not think of trying my password on their VI. Obviously, most people who really care about protecting their code probably choose a password which would be unlikely to be used by anyone else, so in the real world this is more an ease of use feature which allows you to unlock a group of VIs together.

You can set the window position and size using the VI properties, so there's no need to call into the OS API for that part. In any case, I have a feeling that whichever method you choose will have the choppiness Darren was refering to, because even if you get the event, I'm not sure you'll be able to preempt it so that you can move your second window before the first window move is drawn. In that case, I don't think you'll get any better performance from events than from polling. That said, I'm far from an expert on the Windows API. An alternate implementation would be to use subpanels. This will include some overhead, as you'll need to build the "windowing" yourself, but you might be able to do this nicely using panes and automatically resizing the subpanels to fit the panes.

VIPM is closed source, so I don't have access to its source code. I originally didn't look at the program at all, which is why I didn't know if the image was clickable or not. Incidentally, after actually thinking about it, I'm guessing that VIPM actually uses a transparent PNG and loads it into a picture control using either a mask or code that does full alpha transparency.

OK, so I figured "why not?". Here's a quick example (8.0). The tricky bit is using the Text.Visible property to hide the text of the transparent ring. In the example I used the picture control, but I assume that in VIPM a transparent PNG is what's actually used.

OK, so now I did look at VIPM itself and here's my current guess: What you actually have there is an image of the ring (or an actual ring, more likely) with the images on top of it. On top of that image is a transparent ring which is what you actually click. You can see evidence of this in that the ring does not highlight when you mouse over it (which can actually be changed by using the mouse enter event for the transparent ring). You can also check if this is so by changing the OS theme, but this can also be worked around by building the ring image dynamically by placing a system ring off screen no need for this if you simply use a ring and place the images on top of it. Incidentally, the filter ring (to the right of the version ring) does seem to have the image overlayed on top of the ring (it's not clickable and the ring highlights when you move off it).

QUOTE (Aristos Queue @ Jan 26 2009, 06:07 PM) QUOTE (Tomi Maila @ Jan 26 2009, 06:39 PM) Good, then specifying a new VI schema would not be duplicate work Ziiing! Actually, 8.6 does ship with some vi.lib VIs (in _script) which use some sort of schema for scripting VI elements. I'm assuming that this isn't complete, but it could probably serve as a base for something like this.

I don't think you can this either, because it goes against the concept of the history. The point is to save a log of the changes which were made, not to be able to modify that log. If you want to trigger this automatically, you might be able to do it by setting the history to required when the VI is saved and then call the Save Instrument method on all the VIs, but I'm guessing this will simply pop-up a dialog for each of the VIs, which you would still need to update manually (e.g. by pasting your text). The better option is probably to start using a source code control tool for handling versioning. Personally, I used to use the VI history feature in the past too, but using SCC is much easier after you get over the initial hurdle and has many advantages. We (like many others here) use Subversion and if you search for "SCC" or "Subversion" you will find many threads on this topic. In Subversion, you would commit many files together with a single comment for describing the change.