silmaril

QUOTE(Tomi Maila @ Nov 20 2007, 12:46 PM) I agree absolutely. Did you already suggest this on NI's site?

QUOTE(djp_eng @ Nov 17 2007, 02:44 AM) IIRC this VI comes with the LabVIEW Basics I course examples and is to be used if you don't have DAQ hardware. It doesn't do much more than generating a random value. If you only need it as a sub-VI to open some example, it might be easy to replace it by a simple VI of your own.

Did you try Ctrl-Shift-Run on your top level VI? Was the run arrow still unbroken after this?

QUOTE(Aristos Queue @ Nov 4 2007, 10:03 PM) If A!=B and A==B are both false for NaN values, how do you explain this behaviour of LabVIEW 8.5? http://lavag.org/old_files/monthly_11_2007/post-7932-1194603753.png' target="_blank">

QUOTE(beckerg @ Oct 28 2007, 10:25 AM) QUOTE(crelf @ Oct 28 2007, 03:53 PM) I'd love to hear what you and your colleague come to in your discussions If you have a little time, we'd appreciate you guys adding a comment here or there - it all adds to the conversation and I'm sure what you come up with might be crucial for others' education too :thumbup: OK, looks like a good time for me to come out of the dark, too. :ninja: I am the college, beckerg refers to Don't worry - I already try to add my share to this great forum. The only problem is what you so fittingly describe as "little time"...

It's often difficult to get the return data from a DLL that allocates it's own memory. LabVIEW is much easier to use, as long as it can do the memory allocation. There is a very usefull function inside Windows kernel32.dll: void RtlMoveMemory(void *dest, int32_t Source, int32_t length); You could use this to copy the data from the returned address into an array you allocated in your LV app. It works fine for me with my own cluster connected to the *dest input using "Adapt to Type" and "Handles by Value". It should do the same if you have an array instead. If you have access to the DLL source code, I would recommend following Tomi's advice and change the way you return the data. I find it easiest if the DLL gets a pointer to the memory that is already allocated by LV.

QUOTE(Hacti @ Oct 25 2007, 08:21 AM) It seems to me you are mixing the terms here: Run-time, Realtime, DSC. So I am not quite shure what you are really doing. Every property or method has it's table in the online help which states things like "Available in Run-Time Engine and Real-Time Operating System", "Settable when the VI is running" and others. If a property is not available in the Run-time environment, there is usually a good reason (which means, it doesn't make sense to use it outside the development environment). This means there is no way to use those properties/methods in an EXE or on an RT target. If you really think you need one of those on your target, let us know what you want to achieve. Maybe we can find a workaround together.

QUOTE(jlokanis @ Oct 24 2007, 07:57 PM) In a table you can use "-2" as the "line" coordinate to color a whole column in one step, which works pretty fast. I didn't find an equivalent for this in the tree control properties. Is this really missing, or was it just me who missed it? The fastest way I found to make large changes to a tree control is still hiding the tree until I'm finished. This doesn't look very nice, but it works.

QUOTE(mballa @ Oct 25 2007, 08:32 AM) I'm shure it will! QUOTE(mballa @ Oct 25 2007, 08:32 AM) By renaming the Main you disabled my fix and the problem returned. :headbang: Oh yeah! I like this kind of problems QUOTE(mballa @ Oct 25 2007, 08:32 AM) Here is Version 4 it has the fixes above plus some icon cleanup. Yes, this one works nicely, but I'm sorry to say that I found two more little things that should be fixed. In _FIXER Subvis Main.vi there should be a "This VI" reference at the beginning. Without this, I always get error 1026. http://lavag.org/old_files/monthly_10_2007/post-7932-1193296538.png' target="_blank"> The OpenG SubVI was designed very carefully. If you don't wire a reference to it's input, it opens it's own reference and makes shure it is closed again at the end of the VI. Also there is still a breakpoint in the engine, that gets hit everytime I use the "Set as Required" button. Looking at your code, one question comes to my mind: What exactly does the method "FP.Set Close If Lonely" do?

QUOTE(mballa @ Oct 24 2007, 05:50 AM) This is a really nice tool! Thank you very much for all the time you put into this! :worship: The tool works very nice, as long as the name of the main VI starts with an underscore. I copied it into my projects directory and removed that underscore to get a Tools menu item for this. Now I get a funny problem: every time the tool changes the window focus to itself, it seems to detect the VI Activation event and sets "Target VI" to itself, which makes it impossible to use the tool anymore. The straight-forward solution to this seems to work fine here: I didn't upload the complete VI, since it's a really small change, and I suspect, you already have made much bigger changes in your own version.

QUOTE(crelf @ Oct 24 2007, 02:44 AM) I wouldn't want any automatic function to mess with VI or tunnel positions that I have chosen carefully before. :thumbdown: So I'd prefer a function that only changes the size of structures, i.e. the bottom left corner, but doesn't move anything. In my opinion, it shouldn't touch any parent or child structures as well. I expect this would only lead to diagramms on which you can invest hours to bring them back to a decent coding style.

QUOTE(alukindo @ Oct 21 2007, 08:10 PM) It would be interesting to see an example of this behaviour. Maybe it's an effect similar to what I saw in one project, where I printed a front panel as a report: First call: panel with default values was printed, Second call: panel with values from first call was printed, and so on... It seems that LabVIEW simply generated the image to print before updating the data in the controls. Fortunately, all the elements were in one cluster, so the solution was easy: I wired the cluster control directly into a local variable of itself and used a sequence structure to make shure the image was generated after this. Could this be the same thing you are experiencing?

QUOTE(Michael_Aivaliotis @ Oct 18 2007, 07:38 PM) :laugh: It sounded more like "we try to do it this year". 8.5.1 is mainly supposed to bring bug fixes, not new features. This sounds like a very good idea to me... Let's hope this dream really comes true (I heard, they were talking about a version 8.0.1 after the 8.0 desaster, but it was never released, because NI considered it too expensive. :thumbdown: )

QUOTE(orko @ Jun 11 2007, 11:45 PM) I took my CLA recertification exam in June this year. The written part consisted of a lot of questions that had to be answered in your own words. Quite a few of them seemed to target topics from the course "LabVIEW Advanced I - Architectures", so it's definitely a good idea to review this manual before taking the test! There were some questions for which you cannot give the one and only correct answer. It looks as if NI only wants to see that you are able to think for yourself The programming part was a project that's quite a bit larger than the one from the CLD exam. One important thing to keep in mind during the whole exam: You are not supposed to deliver a working application! You are supposed to show your skill as a LV architect, which means you should define the complete architecture of the application, so that others can implement it by filling in the gaps you left. This means you have to wire the complete state machine (or whatever you use) and create all the sub VIs, including their icons, connectors and descriptions. The descriptions have to be sufficient to tell another programmer what to implement at this point. I found it quite difficult to really stick to the architecture without wasting a lot of time implementing details. Because of this, I didn't finish the practical part (4 hours can be such a short time! ). In the end, I really wasn't shure if I passed or failed, so I was very nervous for the next weeks. I really wouldn't call the challenges in the CLA exam easy, but NI seems to make up for that by correcting in quite a friendly fashion, so it ended well for me :thumbup:

QUOTE(TG @ Oct 18 2007, 03:03 AM) In the LV User Group Meeting during VIP 2007 (last week's NI congress in Germany), the NI people told us that LV 8.5.1 will be released "in a couple of months".

QUOTE(Justin Goeres @ Oct 10 2007, 03:58 PM) Of course it will. That's exactly the point of password protection From my point of view, this is the one and only correct behaviour. This way you can for example put password protected VIs into a password protected library and sell it to customers to use it without giving them the chance to pick out single VIs for standalone use (which could be hidden deeply inside the project more easily).

QUOTE(nicolasB @ Oct 9 2007, 01:48 PM) It's only available, if you have Scripting enabled. You need to have this in your labview.ini: SuperSecretPrivateSpecialStuff=True Please read this first, if you are new to this topic: http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">VI Scripting - Readme First

QUOTE(yen @ Sep 8 2007, 09:36 PM) No! That's way to simple! That doesn't count!!!!!!! ok, maybe you've got a point here...

QUOTE(rolfk @ Sep 7 2007, 09:53 PM) Those two images are a really nice example that teach me to use the traditional approach with shift registers rather than the unowned feedback node. With the traditional version, I recognize the pipelining at once. Even if the new version does in fact the same, it still looks like sequential code if you don't look twice. I don't think it's very intuitive. The unowned feedback node still has one advantage: If you use it to build a functional global, you can now have a defined initial value without the need to write to the FGV at least once! :thumbup: As far as I can see, this can't be done using the "old" shift registers.

It is possible to read the command line options in a LabVIEW application, but only if the programmer made the effort to implement it. If he didn't document any special command line options, the best guess is, that there are none. :headbang: So command line won't help you much here. Maybe you could achieve your goal using AutoHotkey?

QUOTE(yen @ Sep 6 2007, 07:16 PM) Yes, you are absolutely right! Did it

QUOTE(Eugen Graf @ Sep 4 2007, 05:42 PM) Even if this is solved for the simple task of making a transparent cluster, I'd still like to have a "change control style" option to change the style of controls on a front panel. This would be very usefull for the cases when I want to use a VI from a 3D-style-project inside a system-style-project. I'm not only thinking about complex clusters, even a simple numeric control contains lots of configuration data. If you are tweaking all the tabs in the properties dialog (which I usually do for real world user interface panels), you have to set all those properties again for the replacement control. This is a very time-consuming task compared to the simple wish "I want to change what the control looks like".

QUOTE(dsaunders @ Sep 6 2007, 02:15 AM) There is an easy way to solve this particular issue: When designing your panel, use labels that tell the programmer what the control does. Then hide all your labels and display captions instead. You may change the captions as often as you like without touching the labels. If you take a look at any localized version of LabVIEW, you have loads of example VIs that show what I mean in your function palette

QUOTE(lraynal @ Jul 20 2007, 09:23 AM) QUOTE(crelf @ Jul 20 2007, 01:56 PM) That's got to be the tip of the day - thanks Laurent! I'd rather think this is the misunderstanding of the day. If you put *.dir in the pattern field, the file select box will show you all the directories and all the files that match this pattern. I named some files test1.dir and test2.dir and - of course - they were visible with this parameter. Of course, you could try using something like *.salflsdhflkasflsdjlfdjfl to achieve the effect of a "directory only file select box". But be aware, that this mask will always be shown in the file type field of the dialog and the user can always change it back to "*.*".

QUOTE(Aristos Queue @ Aug 18 2007, 08:52 AM) Thank you very much, AQ! :worship: I would really appreciate a feature to have project-specific function palettes. The "official NI way" of doing this has several disadvantages (no different library versions for different projects, bad Perforce integration, "illegal" to copy user data to programm files directory...), so I am looking forward to a good way of getting rid of the "user.lib" without loosing it's comfort. :thumbup: At the moment I am using my project window as a palette, but I am shure, usability can be improved here.