Yair

QUOTE (Val Brown @ Aug 29 2008, 08:12 PM) I didn't say anything about my experience, so you can't really have the opposite opinion. I've used 7.0 almost exclusively for the past 5 years and was refering to issues I saw others have or only ran across occasionally. Did the issue you resolve have anything to do with saving variants to a DB when upgrading from pre-8.0 to 8.x? If not, then it's not really relevant to the example I cited. In any case, you should note that I'm not saying anything about the level of support you get from NI, just that in some cases they don't have a solution for you either and if you look through NI's known issues documents you will find some issues with no known workarounds.

Looks like you can't. See here for another attempt. One option would be to add a VI (or two) which will register and unregister its caller in a master list when it starts and stops running, but you would need to add those VI to every single VI that you want to monitor, which makes it impractical.

It is rarely a good idea to rely on controls and indicators for data passing, unless you're using them through the connector pane. If you want to trasnfer data between VIs, there are any number of methods, from global variables to LV2 style globals to queues and notifiers.

You need to have at least one front panel in your application, or it will be shut down automatically, but as Ben suggested, you can set its state to Hidden, which accomplishes the same goal. Additionally, if you're running Windows, you can convert the executable to a Windows service (which does not have a window) and it will run even if you don't log into the machine. You should be able to find the details on NI's site.

QUOTE (Val Brown @ Aug 29 2008, 10:55 AM) That's a good one. NI's release schdules are usually in at least six months cycles and even then there is no guarantee for your problem to be fixed in the next release. I'm not saying that NI doesn't resolve the issues or offers workarounds, just that it's not guaranteed to do it and relying on it is potentially dangerous. At least in open source (and some of NI's code also falls under that category) you have the option of fixing some problems yourself. A couple of examples that spring to mind: You mentioned the DB toolkit. The DB toolkit relied on a certain behavior of variants when flattening them to be saved to a binary field. In LV 8.0, NI changed the internal structure of variants and this broke, because that use case wasn't tested. This might have been fixed in the new version of the DB toolkit which came out with 8.6, but I never ran into this personally, so I don't know. Before LV 7.1, you could control the properties of a caption without any problems. Since 7.1 you had to manually make the caption visible once before it would be created. If you didn't do that, the code which worked for years would now be broken. Did NI fix that? No. It was decided and you had to modify your own code.

QUOTE (Aristos Queue @ Aug 29 2008, 12:18 AM) I humbly withdraw my nomination. Sorry, JiMM.

YES!!! George, can I please get the award for the most stupid CAR ever? It doesn't have to be a cup or a medal. A nice plaque will do fine. :laugh:

QUOTE (Phillip Brooks @ Aug 28 2008, 10:15 PM) Well, you were warned. I believe the diagram width (and position? can't be bothered to check) are a 16 bit integer, so the flat sequence would be too wide. So you see, stacked sequences are better. QED. P.S. To paraphrase Stephen Mercer "LabVIEW crashes when my wire is over 32,000 pixels long and I try to clean it up. Fix it".

I'm with the leave-it-on-but-handle-errors-camp. This is good for catching places where you missed wiring an error cluster, although if you want, the VI analyzer also has a test for this. In any case, when you compile an executable, errors won't pop up under any conditions, so leaving it on only applies in the IDE (where it can also be globally disabled). That said, there are cases where leaving it enabled can give you trouble. I was once asked to debug a VI which had a primitive (open app ref, I think), which returned both a reference (although an unusable one) and an error. The error out wasn't wired and I didn't think to check it because the VI was returning a reference and I had AEH on. What I didn't realize was that the person who wrote the VI didn't have AEH enabled and so the VI didn't have it enabled. Without relying on it, I might have wired the error out terminal sooner and found the source of the problem. If you want, you can read this discussion for more. P.S. Regarding your question, yes, there are cases where it's OK not to handle errors (e.g. certain property nodes, disconnected segments), but you have to be very careful about this.

QUOTE (neB @ Aug 28 2008, 04:19 PM) http://forums.lavag.org/index.php?s=&s...ost&p=42439

Hmm... Maybe this would make a good signature.

QUOTE (Gabi1 @ Aug 27 2008, 08:56 PM) Actually, it's 7.0, and you can find it here. It works great, but the main problem is that unlike Darren, I can't scan the palette and need to hold the list of possible functions in separate files. What's in that thread is a version that I still use all the time, but I haven't worked on it in a long time, so it doesn't include code for creating the lists, so you will either need to create your own code, use the existing lists (which should cover most VIs) or add things manually. It does, however, include shortcuts just like Quick Drop has. It doesn't have a convenient interface for opening the dialog, since I didn't really work on that. Basically, it only opens the shortcuts dialog if you give it a string it can't match (which is correct behavior, but isn't enough). Adding a button to open the shortcuts dialog should be very simple. QUOTE (PJM_labview @ Aug 27 2008, 08:59 PM) I there a way for you to share these shortcuts (I am the lazy type...)? I'm pretty sure there's a KB article with the list on NI's site.

As mentioned, the PDA module (and licenses, although I think you don't need one if you only have one copy) is expensive. Additionally, I haven't worked with the recent versions of the module, but you should still expect it to be buggy. In the past, it was often "code something, test it, and then spend quite a bit of time finding and working around the PDA module bugs, some of which will be highly unexpected". I assume it's still more or less the same. I believe you should be able to use the IR port using the IrDA functions or as a serial port, but I never tried, so I can't tell. The documentation for the module can probably give you the answer. All in all, I would go with the others' suggestion of using a real remote or proper software.

VIs in LLBs are displayed in the user.lib palettes only if they are marked as top level VIs. The VIs you want are not marked as top level. You can either change that by using the LLB editor (from the Tools menu, I think) or you can edit the palettes and add them manually.

If you want to implement common rounding, you can do this by adding 0.5 and then rounding down. Here's an example.

QUOTE (crelf @ Aug 22 2008, 09:02 PM) I won't go into this discussion either, but just to comment on this point: http://forums.lavag.org/A-Blast-From-The-Past-t729.html' target="_blank">This article from 1986 makes repeated reference to the language behind LV as "G". I have the "G programming reference manual" (for LV and BridgeVIEW) from 1999, which also refers to the language as G, so at least NI thought about it that way. It's possible that this was stopped due to copyright issues.

QUOTE (ASTDan @ Aug 25 2008, 01:29 AM) You could try using an annotation of or a cursor and control it using property nodes, but I have a feeling that the pop up will look better and be easier to write.

QUOTE (giopper @ Aug 24 2008, 03:47 AM) The attached example (8.0) has simpler logic, but you should note that it does not handle the U32 rollover. In any case, you can't expect to get ms accuracy in a desktop OS. While the CPU is certainly capable of it, the OS is not designed to guarantee it. If you expect to get synchronization in more than one machine, I think you will have to use some external triggering or even a real time OS.

QUOTE (normandinf @ Aug 22 2008, 07:00 PM) You can also access the brush directly from the BD. No need to go through the FP. QUOTE (Michael_Aivaliotis @ Aug 24 2008, 09:30 AM) Isn't there an ini key that will give you transparent structures? If memory serves, the key gives semi-transparent structures, not fully transparent.

I was expecting to see a Laurel and Hardy VI when I saw the title of the thread. :laugh:

QUOTE (Raymond Tsang @ Aug 22 2008, 12:46 AM) So? Just fix it. It's a simple enough example. In any case, both cases were just quick examples and quite possibly have bugs, etc.. I can't look at the code for either at the moment, but they should demonstrate how to handle the array "in place" by replacing and rotating. This should have good performance, as you're only allocating the memory once (or twice, since it's also going into the indicator, but you can't avoid that).

QUOTE (lycangeek @ Aug 21 2008, 06:50 PM) That kind of rules me out, then. I only code in LabVIEW, so I can't say I have any need for VS features. One thing I can say is that the graphical project design feature which a friend showed me in the VS2008 beta a few months ago (and which I assume made it to the final version) looks nice and is at least reminscient of LabVIEW. Nice to hear you have interesting stuff to do.

If you want to avoid having memory problems, you need to replace and rotate the array. There is actually a shipping example of this, but it's not very nice (it uses a local variable), so I created a quick one myself once and you can find it here. Just for the fun of it, here's another version of it which creates a vertical chart.

Great to hear from you again, Brian. Good stuff. I take it your MS project is still secret? Michael, I believe 8.6 should have a native DOM parser (possibly even the one Rolf mentioned), so you can also try looking in that direction. Of course, if parsing XML is easier in C#, then that's probably a better solution.

The resolution of the get time primitive in Windows is ~16 ms. I'm not sure why, but I don't think you can change that. If you want to get ms values, you can use the tick count primitive, which returns the number of ms since the OS was started (U32, so it wraps after ~49 days). You can wrap it in a functional global, so it would remember the timestamp when it started and would do the calculation itself. If you want higher accuracy, you can call the queryperformancecounter API function for a microsecond resolution, but unless you can sync it correctly, I doubt it would help you.