Mellroth

Received the the CAR# yesterday. CAR# 48H2DBYN /J

QUOTE(dannyt @ May 2 2007, 12:41 PM) Hi Dannyt, I don't think anyone but NI could really answer this question, but I agree with you that recompilation is sometimes required for very strange reasons. LV5.1 would never recompile (as far as I remember), due to changes in the block diagram, but only if changes were made to the connector pane somehow. Since this version changes on the BD sometimes force a recompilation, e.g. adding a Case structure. I can only guess why we need to recompile due to an added case structure, but my guess is that the case structure is changing the way the compiler marks the wires connecting to the VI (e.g. if a copy is needed). But again, I don't think anyone outside NI, can really answer this question completely, and I'm looking forward or at least hoping to see some NI response on this. /J

QUOTE(crelf @ Apr 27 2007, 02:32 PM) I rather not... QUOTE(martin@aerodynamics @ Apr 27 2007, 03:09 PM) Are you sure that they are not just april fools?? without april, you mean /J

QUOTE(Mikkel @ Apr 27 2007, 01:32 PM) :thumbup: /J

QUOTE(VDB @ Apr 23 2007, 08:56 AM) Hi, I can reproduce this on WinXP (English). Defining the list of allowable values works with commas, but entering commas into the Combo box don't. I think you should report this to NI as a separate bug, and maybe start a new bug thread here at LAVA. /J

QUOTE(george seifert @ Apr 20 2007, 03:50 PM) Hi George, you have to have a valid event registration refnum before entering the Event structure. In your case the event registration refnum is not defined until you have passed the "mouse enter" event. To solve this, I added a registration of events (empty array of control refnums), before the loop. http://forums.lavag.org/index.php?act=attach&type=post&id=5559''>http://forums.lavag.org/index.php?act=attach&type=post&id=5559'>http://forums.lavag.org/index.php?act=attach&type=post&id=5559 Good luck! /J

QUOTE(Nullllll @ Apr 20 2007, 12:53 PM) :question:

QUOTE(Nullllll @ Apr 20 2007, 11:14 AM) Hi Nullllll, do you ever actually read the responses you get here at LAVA? :headbang: Several members have asked you to use google, before you ask questions. Goto www.google.com enter "sending email from LabVIEW" as your search string check the results of your search. Again, please use Google first before starting new threads, as your posts are just adding noise here at LAVA. QUOTE(TiT @ Apr 20 2007, 11:28 AM) ...you have a subpalette for SMTP email... Not in the base package, which I suspect is the version used in this case /J

QUOTE(Michael_Aivaliotis @ Apr 18 2007, 09:36 AM) I haven't really tested performance of queues vs. FG's (at least not since queues became primitives). As long as the queue is only replacing a simple array memory, I think that the queue might be as fast as a FG. But when the functional global contains more than one array of data, my guess is that the FG would be faster. Anyway, a really interesting topic. /J

QUOTE(tcplomp @ Apr 17 2007, 10:43 PM) Hi Ton, I had that as my workaround #2, but today I had time to do some more tests. It seems like the Source Distribution fails to include any VIs embedded in a diagram disable structure (which would be a bug report of its own). /J

Hi, I have a bunch of VI-tree's (remember this old way of grouping VIs), that I'd like to add to a project in LabVIEW 8.2. The reason to keep the VI-Tree approach is that a user can get a graphical overview (i.e. Icon overview) instead of the listing used in the project explorer. Anyway... I tried to create a source distribution (preserve hierarchy) for all my VI-Trees, but as it turns out, the distribution only gives me the top-level VI's (no used sub-VIs are in the source build). It seems like the reason for this is that for a source distribution to go on and find all Sub-VIs, the top VI must be executable? (no VI's below a broken VI will be included in the source distribution). Since the bad VI itself is added to the source distribution, but no subVIs, it means that the bad subVI might be linking to VIs outside the source distribution target To require the top-VI (or any other VI) to be executable is fine as long as you are building an exe or dll, but for a source distribution this feels wrong. In LV7.1.1, I could open up the VI-Tree and save with options, then all VIs, regardless of execution state, would be saved in the target folder (possibly changing passwords, removing diagrams etc.). Workaround 1: If I drag all VIs found on the block diagrams of the VI-Tree's to the project explorer, the distribution contains all sub-VIs found in the hiearchies of the the top VI's (VI-Tree). This is not really a good way to do this, as I will have to manage both the VI-Tree and the project file to create a correct source distribution. At least compared to if I could only change the VI-Tree, and then just do a rebuild in the project file. This method will still fail, if any of the VIs are not executable Workaround 2: Open up all VI-Trees, then surround all VIs on each VI-Tree block diagram by a disable structure. At least this would give me the Top-level view, but VIs in bad execution state will still not be correctly included in the build. This has been reported to NI, but I have no CAR# for this one yet. /J PS. I know I can choose "Save As..." to save a complete VI Hierarchy, but this doesn't give me the options to remove BD's, set passwords etc, i.e. what you get from using the Source Distribution. The Source Distribution is also much better as it allows me to save how I would like the build to be, adding support files etc.

Bug reported in 8.2 and confirmed by NI in 8.2.1 as well. CAR#: 48F0MHE8 /J

EDIT: I accidentally posted this bug again, original bug is (http://forums.lavag.org/Flatten-Unflatten-...-bug-t7324.html) I've asked Michael to remove this thread, sorry :headbang: /J

QUOTE(LV Punk @ Apr 16 2007, 02:58 PM) Workaround: 1. colorize the control in green 2. change FP background to a brickwall voila . /J

QUOTE(kate @ Apr 16 2007, 02:27 PM) Hi, it is possible to convert between different graphic formats using LabVIEW. You can find methods to read and write different formats in the Tools palette, just look in Functions->Graphics and Sound->Graphics formats. /J

QUOTE(Tomi Maila @ Apr 14 2007, 10:50 PM) Hi Tomi, great article series. But I think the link is wrong, it currently reads (http://"http//expressionflow.com/2007/04/14/reusing-code-by-inheritance/"). /J

QUOTE(Jim Kring @ Apr 13 2007, 05:53 PM) I didn't mean to say that typecasting was the solution. I replied to Stephen's question if a typecast node would work, and it does. Anyway, in this case I would use solution #2 from my first reply. /J

QUOTE(Aristos Queue @ Apr 13 2007, 04:41 PM) Yes it does. Sometimes I put a type cast node after the case structure, forcing the "correct" name. The "start" case in Tomi's first post, could then output a duplicate reference in an extra tunnel (set to "Use default if unwired"), and use this output to cast the reference passed around in the shift register. /J

QUOTE(Sally @ Apr 13 2007, 01:43 PM) Please post what you have done so far... Is the "Extra information" front panel objects? If so, create control references for all the objects that you want to show/hide, and put all these references in an array. Then use a property node in a loop, to set the "Visible" property for all these objects. /J

QUOTE(Jim Kring @ Apr 12 2007, 06:07 PM) I've been waiting for this, thanks Jim :thumbup: /J

QUOTE(Tomi Maila @ Apr 13 2007, 12:38 PM) Hi Tomi, I think that this has to do with the unitialized shiftregister retaining the name of the first instance that "named" its wire. The event refnum in your initialize case is then "type-casted" to the older version, since the Event structure outputs a previously named version. Workarounds that I can think of right now 1. If you wire the event refnum from outside the loop everything should be OK, but this might not work depending on what you are trying to do. 2. Bypass the Eventstructure, i.e. don't use the event structure output (OK, as long as you don't change the dynamic events). http://forums.lavag.org/index.php?act=attach&type=post&id=5493''>http://forums.lavag.org/index.php?act=attach&type=post&id=5493'>http://forums.lavag.org/index.php?act=attach&type=post&id=5493 /J

QUOTE(Sally @ Apr 13 2007, 11:09 AM) Please add a VI to show what you have tried so far, or what you are trying to do... and what has the topic "Menu" to do with your question? I'm note sure I understand your request, but to display values point by point, you usually use a chart instead of a graph. The update speed is determined by the LabVIEW code, that updates the chart. /J

QUOTE(Guenther @ Apr 11 2007, 03:27 PM) This will only work as long as the user presses alpha-numeric keys on the keyboard. If the user presses backspace, delete etc., the resulting string would be different than the actual cell value. Ben's method would take care of all this, and also if the user moves the cursor with a mouse click and start editing inside the sting instead of at the end. /J

QUOTE(Nullllll @ Apr 6 2007, 11:12 AM) Nullllll, please show some effort. Several members have requested that you should include some schematic and/or show us what you have done so far in terms of LabVIEW programming, but you ask basically the same question over and over again. QUOTE Stupid questions require stupid answers Why Do People Answer Stupid Questions More Than Good Ones?? http://ca.answers.yahoo.com/rss/question.p...01061627AAB6Ue6 I do not mean to be rude, but you really have to read about how to ask questions in a better way. Now to your problem. 1. What DAQ card do you use? 2. How is the DAQ card connected to the circuit? (schematic) 3. Show us a what you have done so far, in terms of VIs. 4. Can you include a picture explaining what you intend to do? QUOTE(Tomi Maila @ Apr 6 2007, 01:14 PM) I think you should consider using http://expressionflow.com' target="_blank">expressionflow instead. I agree, but then I imagine all questions that could be asked (and how they could be asked)... Lets stay with your first camera solution /J

Congratulations Jim, can't wait to read your next 1000 posts. :worship: Cheers :beer: /J