Yair

Does the compact edition not use the UDL configuration dialog like other DBs in Windows?

QUOTE (jlokanis @ Sep 23 2008, 12:48 AM) I haven't tried, but what happens if you make the window modal and then programmatically change it to be floating?

QUOTE (Attila @ Sep 19 2008, 06:43 PM) Scripting isn't officially a feature of LabVIEW. NI does not support it and not all of it is implemented. In any case, you should note that the problem is not with saving the VI. The problem is that after you create the diagram, that diagram needs to be compiled into machine code. The compiling code is only found in LabVIEW, not in the run-time engine. As the others mentioned, if you explain your actual use case, another solution might be offered.

QUOTE (Phillip Brooks @ Sep 19 2008, 05:14 PM) The SRI is the behind all the master conspiracies in the world. Its evil plot is to give you some money at the end of each year depending on how much you worked. Naturally, alfa is a big threat to them, so they have to try and kill him.

QUOTE (James N @ Sep 18 2008, 04:24 PM) No, but it will be ignored in the palettes. And I'm not sure, since I have used 8.x enough, but I believe they are also ignored when you add a folder to a project.

You can read this post for more details on NI's actual attempt and its results. My own idea (which I actually implemented and which should also appear in that thread) was to have an easily accessible menu like the Current VI's SubVIs menu which will list all open VIs with their icons. My proof of concept implementation worked fine, but had performance issues. I know that some people move the Windows task bar to the left side of the screen so that it has room for more windows and you can more easily see the name of each window, but that takes getting used to.

QUOTE (pallen @ Sep 11 2008, 09:50 PM) That's a basic rule of floating-point math. You can't represent a fraction like 0.1 exactly. What you should do is compare to a small range (you can use the In Range and Coerce function) and only add or subtract if you're outside the range. The style would also be better if you used a shift register and a couple of select nodes or if you at least combined the case structures into a single structure by nesting them.

QUOTE (HChandler @ Sep 8 2008, 08:57 PM) That's the basic point, although you can have LabVIEW open. You just need not to have the VIs loaded. I'm not sure what effect this will have on projects, since I'm not an 8.x user (yet, at least). QUOTE Also, what about lvlibs. Should I use them or not? Should I take things out of them before moving things around? I'm not sure. My understanding is that when you add a VI to a library, it remembers that it's owned by that library. I'm not sure what will happen if you open the VI and it can't find the library or vice versa. You probably don't want to use LLBs. They were originally created to allow long VI names in Windows 3.x and pose some problems since they are a single file for multiple VIs.

QUOTE (pikro @ Sep 9 2008, 10:43 AM) That code works just fine. As I mentioned, the part on the left (getting the name of the top level VI) might not behave as you expect under all circumstances, but the loop was the important part of the code.

QUOTE (HChandler @ Sep 8 2008, 06:11 PM) False, and therefore, the answer to the second question is no. By default, every LabVIEW object that holds a path to another (VIs, projects, libraries, etc.) keeps the path as a relative path (or a symbolic path, for VIs in special folders), and only holds an absolute path if it can't (e.g. if it's on another drive). However, if you have Foo.vi in memory loaded from X and you open a VI (bar.vi) which expects to find Foo.vi at Y, you will get a conflict, since Foo.vi is already in memory. LabVIEW will alert you to this conflict using the dialog. If you now save bar.vi, it will remember that Foo.vi needs to be loaded from X, even if X is on another computer.

I can't access that link you provided either. Again, the best thing for you to do would probably be to call your local NI office and get direct phone support.

QUOTE (HChandler @ Sep 5 2008, 07:58 PM) Because a) the code has to be in memory to be compiled, b) it has to be loaded from somewhere and c) you can only have one VI in memory with a given name. If you turned it off, LabVIEW would not be able to do its edit time compiling which it currently does and would be not be able to perform all kinds of optimizations it currently does. My understanding was the whole concept of libraries in LV 8.x was to avoid the cross linking problem. QUOTE Why can't I explicitly (and exclusively) specify what to link to and what to compile? You sort of can. If you open a VI from disk and then open a hierarchy calling another VI with the same name your first VI will be loaded. Of course, the practicality of that for multiple VIs is limited. Should NI have a dialog which will allow you to manually resolve cross linking issues across your entire hierarchy? Maybe, I don't know. You should submit a product suggestion in NI's product suggestion center. Maybe a dialog like that can be written today, but the first option I'm thinking of will not work, becuase LV will not let you open a reference to a VI on disk with the same name as a VI currently in memory. I believe there is a private method for replacing a VI with another in code, but I'm not sure how it would behave. The only solution might be to keep a list and then close the hierarchy, open the VIs in the list and then open the hierarchy again. QUOTE It's like nailing jello to the wall! http://www.myscienceproject.org/j-wall.html' rel='nofollow' target="_blank">I don't see the problem:

Welcome to LAVA. QUOTE (rharding @ Sep 5 2008, 11:24 PM) I have no idea what the answer to your question is, but you should post it to a different thread. In general, error 1172 doesn't mean anything, as it's just the error code for a .NET exception. The description is what's important and you might want to search around for that in pages related to C# or to that library. Alternatively, you can try calling the library directly from LabVIEW using the call library function node or you can try using a set of LabVIEW wrappers for WinPCAP which might do what you want and which was posted to the NI forums.

Et tu, Christian? While that method is reasonably likely to work (at least in Windows), it fails to account for many corner cases (e.g. non-Windows OS, a VI in an LLB, a VI whose extension is .exe, etc.). A more robust way would be to do something like this: Incidentally, this example has its own problems (the top level VI might not always be what you think), but the stripping part is sound.

You should probably call NI to get some phone support, but you can also try at NI's CVI board.

This idea might or might not be good (I can't say I really thought about it), but in any case, you have some better options for implementing your example. The Value Change event doesn't really help you, since it doesn't cover cases where users clicked outside the controls or outside the window. You could handle each of those as well (and handle all controls together by using dynamic events), but one easier solution would be to do this: Personally, I can can't think of many VIs in which I would want something like this, but I suppose you might want this in some VIs.

QUOTE (Phil Duncan @ Sep 1 2008, 06:32 PM) Thanks, Phil. After having to think about albums which are better I ended up listening to both Scenes From a Memory and War of the Worlds today and now I'm happier. Just hearing Richard Burton saying "No one would have believed, in the last years of the 19th century" makes me more relaxed. QUOTE (PaulG. @ Sep 3 2008, 04:14 AM) But I saw/heard this tonight and thought it was beautiful and BRILLIANT. You're right, that is good, although I don't recognize the piece (and I don't like sites which require installing additional plug-ins . What's wrong with Flash?)

That sounds like a reasonable assessment, although to be sure, you should set the preallocate option. Quoting from the help: QUOTE This seems to indicate that the clone is created when you call the VI and since the VI doesn't stop, the clone should remain as a "separate VI". What issues are you seeing exactly?

QUOTE (Phillip Brooks @ Sep 2 2008, 11:16 PM) I've had quite a few opportunities to use all versions of 8.x, so that option does not surprise me. I never used the Windows Explorer option, so the fact that the top level VIs do not open automatically is annoying, but it's still easier than having to deal with the zip file. If anything will make me sad, it's the fact that 8.x seems to crash a lot more than 7.0 and be slow, especially when using all the new niceties like projects and LVOOP, which I will be. Also, 8.6 broke the way Hebrew works, so that's annoying if you try to create a UI in that language. If anything, that will be the reason for me not to really use it and I'm disappointed I didn't think to check it during the beta.

QUOTE (Norm Kirchner @ Sep 2 2008, 05:38 PM) Actually, when you build the application into an executable, both the FP and the BD are removed by default on all VIs, and are only retained under certain conditions. Even in the IDE, a VI can be saved without a BD (although not without an FP). QUOTE (jives @ Sep 2 2008, 03:34 PM) If I convert my application to a service, the FP will automatically be disabled/hidden? I don't remember, but the tutorial I mentioned on NI's site is quite details and should probably help Norm as well.

QUOTE (giopper @ Sep 1 2008, 12:32 AM) The common solution is usually to allocate the full size array and then replace elements in it using a shift register. You can see an example implentation of a circular buffer I posted here. QUOTE In other words, I will probably give up and go back to the hardware solution, using the IRIG-B code from the local GPS clock. Sounds like a reasonable solution to me. QUOTE (crelf @ Sep 1 2008, 07:05 PM) I don't use LLBs at all anymore - there's no real use for them I don't use 8.x (yet), so I don't need lvproj or other files. Using an LLB has the advantage that you can open the file directly from the browser (without needing to use whichever program reads your zip files) and that you can specify a top level VI. IMO, that makes them useful for posting code online. I find both methods to be valid.

QUOTE (Phil Duncan @ Sep 1 2008, 06:32 PM) I can easily think of any number of albums which are better (even by DS), but I agree it's a worthy one. I noticed that I forgot to mention the most important song I put on: P.S. Yes, Really.

QUOTE (crelf @ Sep 1 2008, 07:35 AM) Mine too! QUOTE * Disclaimer: I can't vote. Neither can I!

I will start by saying that I have zero knowledge about this, so everything below may be wrong, but since you asked: QUOTE (giopper @ Aug 30 2008, 06:50 AM) I'm not sure if you can do that reliably without dedicated hardware, even on Linux. QUOTE However, we know that the absolute time comes with a 10-20 ms error Maybe YOU know it. I only see that the displayed resolution is ~16 ms. I know nothing about the accuracy (maybe it's synchronized with sub-ms accuracy?). QUOTE I can tell you that under Linux + ntpd server properly running you can get better than 1 ms simply using the LV built-in time function. But can you trust it to be synchornized? Regarding your code, I can't say much, since I didn't dive into it, but I can comment on a couple of things: The local is unnecessary and causes a race condition. It can be read before its indicator is written to. You can just get rid of it and wire the data straight into the loop. Building arrays in loops is a big no-no as it requires repeated calls for memory allocation and can hurt performance and statistics, especially when trying to time code. When you want to distribute code, it's better if you do a save as and create an LLB, as it's then a single file.

I'm not saying that I prefer open source. I use both kinds (including the DBCT, since we've mentioned it). What I'm saying is that even if NI are guaranteed to address your issue (to use your original term), they're not guaranteed to offer what you would consider a completely satisfactory solution. I'm not saying that's wrong, either. They can't solve everything. My point is that the assumption that paying for service necessarily means you'll always get what you want could be dangerous. How was the issue with saving variants resolved in your case?