Yair

OK, so I didn't really read the entire thread, but I think maybe the documentation should be updated. I wanted to have an array of "current values" updated from dynamically called VIs. I could have done it many ways, but I figured the quickest would be to create a notifier for each VI and go over those notifiers in a for loop with Ignore Previous set to F, like the attached example, right? Well, no. It was wrong. As the help says, each node remembers the time of the last notification, and as Stephen said here, remembering a separate time for each reference is apparently not worth it. OK, since I'm using 8.6, I did a quick workaround by replacing the notifier with a lossy queue, which works fine, as can be seen in the example. I have to say that it took me a while to figure it out, though. I think the help needs to be more explicit about how this specific case (iterating over notifiers) will not be handled as the user might expect. P.S. I haven't looked closely at how the W4MN and the new notifier primitives are supposed to work, but a quick test seems to indicate that they do not do what I want.

QUOTE (lenny wintfeld @ Dec 29 2008, 11:02 PM) You haven't looked closely enough:

I never used the wizard, so I can't say for sure, but I doubt there should a problem with deleting that folder. There might be a menu file, but VIs in the instr.lib folder go into the palettes automatically, so I'm assuming there isn't a separate menu file created for the project. The most obvious issue would be if you call VIs in that folder, but I'm assuming that you're not. One last thing is that LabVIEW sometimes locks a folder and prevents you from deleting it until you exit LabVIEW. I think this has to do with LabVIEW setting the current directory for the process, which probably prevents Windows from deleting it, but that's a corner case.

Well, if you came up with something, I suggest you post it to both threads in case someone else will want it in the future. I can say that the code Mike posted already does almost everything you need. It took me about a minute to modify it to handle alpha blending for the entire array and plug it into my code and it worked nicely in 8.6. I guess that means that the algorithm I originally used was wrong, but it's interesting that it did work fine in 7.0.

I would have to agree with PJM. If you look at the last video he posted, you can see this very clearly in the shadows cast by the sequence in the LV logo. The LabVIEW picture control functions load the alpha channel from PNGs, but the VIs that draw the image discard it. That's why you need to get both the FG and BG image and do the merging yourself. I explained this in more detail in the other thread.

QUOTE (MikePorter @ Dec 22 2008, 05:10 PM) Can you expand on that? I noticed that using it makes the query considerably faster for larger data sets (natually) and I'm pretty sure that NI uses this in their new version of the DB toolkit. I know you think the toolkit is unnecessary, but presumably both NI and Microsoft have at least some people who know what they're doing, right (ducks to avoid the shower of rotten tomatoes)? P.S. Welcome to LAVA. Did Ben manage to convince you?

Bob, can you help me with this, please? Personally, I just ignore these as well and I usually don't even go into these threads because LAVA works too slow and I don't feel like waiting until the page loads. The only exceptions are if the thread looks potentially interesting or if I see a lot of people replied and hopefully there'll be some fun in there. However, I try not to join the ganging up (although I do remember one case in which I did, and I got reprimanded for misconduct). Personally, I feel that the NI forums are a much more suitable place for any beginner posts, as it has more mass and the poster is considerably more likely to get a quick reply, but I know that Mike feels otherwise. Either way, I don't really care that much as long as the volume is not so large that it drowns the good stuff.

Yeah, what Rolf said. My point is that you do already have an alphabetical list of all VIs and primitives (even three, if you count the palette search and QD as different ones). It's just that those lists are not flat, but searchable. All your user needs to know is to go there instead of to your list (which is presumably in a file somewhere that they have to dig up or in a very thick book on the top shelf).

Well, the image I saw this happen with has more complex transparency than that and since the code did work fine in 7.0, I would have to blame 8.x. However, as I mentioned, I didn't look into this at all other than seeing that it happened, so the fix would probably not be too hard.

QUOTE (BrokenArrow @ Dec 20 2008, 05:20 AM) But that's exactly the point of an indexable and searchable database. Why is opening a book or a virtual document any easier than searching using the search function (or Quick Drop, both available using a couple of clicks)? In both cases you would have to KNOW to do what you want.

The 3D graph in 8.6 was implemented as an Xcontrol. I don't remember off hand if it uses classes (although it probably does), but you should be able to see its code by dropping one and selecting Advanced>>Show Diagram from the right click menu.

I've done this in the past as well and I can also say the code is quite simple (although I can't share mine either). If you do this, maybe you should post your code to both threads. You can get the color info by unflattening the pixmap and then splitting and joining the 2D arrays or by taking the data directly from the 1D image array and you can get the transparency info from every fourth element in the image array (e.g. by using the decimate array primitive). Philippe, as I mentioned in the other thread, my code which worked fine in 7.0 doesn't really work in 8.6 and sort of messes up the picture. I didn't look into this, so I don't know the details, but did you run into anything like that?

QUOTE (asbo @ Dec 19 2008, 05:12 PM) Or you can press Ctrl+Run, which force compiles the VI (with the side effect of clearing SR data).

I haven't checked, but I believe the project ignores files and folders starting with an underscore. At least Subversion clients have the option of having the hidden folders start with an underscore.

Yes, definitely an impressive use of the picture control. I also liked the traced video image. I assume that this was done with a standard IMAQ VI.

Resizing the window sounds like a bad UI design to me. If you just want what's in the pane to be invisible, you can just make the individual controls invisible (e.g. by using the Controls[] property). I don't know if the pane has a Visible property, but I can't say it seems to make sense. P.S. For a progress bar, you might wish to open a separate VI and transfer the progress using a notifier or another mechanism.

The bounds property is always read-only. Each class of control has other properties for setting its size, although the ones for the cluster class are not exposed, if memory serves. What you can do is set the cluster to auto-size and then use the properties of the controls inside the cluster to move them around. This will change the size of the cluster as well.

I don't know if the vision module has a .NET interface and I'm not entirely clear on how your system is set up and what you want to do, but here are a couple of options: 1. Compile a DLL in LabVIEW (this should be an option in the project). This is the closest you can come to what I think you want. 2. Look at the LabVIEW VIs calling the vision C functions and reimplement those calls in .NET.

The key should indeed be the different port numbers. If you have the same port, then I believe you always get the IDE. Also, if memory serves, you have to wire something into the machine name input, or you always get the current instance. I believe at least that part appears in the documentation. QUOTE (Dan DeFriese @ Dec 11 2008, 09:21 PM) That's because enabling the VI server overwrites the value you set with the default port. I reported this to NI a couple of versions back, but I don't know what they did about this.

QUOTE (Justin Goeres @ Dec 1 2008, 07:02 PM) Something like this? http://lavag.org/old_files/monthly_12_2008/post-1431-1228673781.png' target="_blank"> Sorry about the low quality and cheesy font, but I didn't feel like putting much into it (as can could be seen in the stupid spelling error which was in there).

The snap to grid option already exists. I'm not sure if it works in the BD as well, but you can check that in the options menu. P.S. I agree this might make an interesting NIWeek session.

QUOTE (normandinf @ Dec 5 2008, 06:11 PM) You could make a LAVA shirt out of that. :laugh: ... Not that I would wear it, of course, but...

QUOTE (KarstenDallmeyer @ Dec 5 2008, 12:34 PM) Which was what I wasn't sure about. As I said, it's been a while since I used the UDP VIs and I was sure that at least some of them do accept the IP address, just like the TCP primitives.

I haven't really used UDP and I'm not in front of LabVIEW at the moment. Why would you need to translate 255.255.255.255 to a network address? Doesn't the broadcast primitive accept a string as the target? In any case, if you think this is a bug, you should report it to NI.

QUOTE (skof @ Dec 3 2008, 12:00 AM) There are properties for changing this, but there was a bug with this. I don't remember the details off hand, but you can read about it http://forums.lavag.org/Bug-in-VI-Server-activation-t11406.html&pid=53251' target="_blank">here. It's possible that you can't do this currently. I'm not sure.