silmaril

You are right. I just posted this request there. Now it's waiting for Christmas to see which items from the wish list will be inside all those colorfull boxes

There is a function called "Not a Number/Path/Refnum?" on the comparison palette. Use this to check if the reference is invalid (which will be the case if the reference input is unwired).

The Get/Set Tag methods provide very interesting possibilities of saving and retrieving additional information with controls, panels... This looks very similar to the Get/Set Variant Attribute functions. There is just one function I am missing: Is there any way to get all the tag names associated to a scripting object?

If there is only one recipient, do you really need several queues? I could think about one queue which is fed by several senders. If they need different data types, you could use a standard message type for the queue: A cluster, containing an enum ("command") and a variant ("data"). For each command there can be a different type of cluster in the data part. If you use this kind of message queue, I am quite confident that you will soon find out many additional ways to make use of this concept.

QUOTE (jed @ Jun 5 2009, 10:34 PM) QUOTE (jed @ Jun 5 2009, 10:34 PM) -Does anyone else have their own tools that they would be interested in sharing? -Would anyone be interested in creating an openG project? I would like to plug them into the JKI right click framework (although they don't have scripting, their program could connect right-clicks and hotkeys to them) Sorry, I don't have any tools I could provide. The tools you have already written sound quite interesting, though. I'd definitely encourage you to start this openG project. :thumbup: I am especially interested in how you solved the "Rename in P4 and LV". I was thinking about writing such a tool myself, but I couldn't find a good way to do this, since I always end up having some kind of conflict betweeen P4 and LV names. :headbang: QUOTE (gmart @ Jun 8 2009, 03:43 PM) For the most part both providers provide a similar level of functionality. An advantage of the Perforce Command Line provider is that it is cross-platform. Also, by using the command line, operations such as a native LabVIEW diff can be performed. You can diff LabVIEW files with Perforce SCM, but you have to configure a tool (such as lvdiff) from the client to do this. To make this clear: you can use the VI diff with both providers configured in LV. If you use the client application that comes with Perforce (P4V or P4Win), you need lvdiff to get a useful VI diff. So there is still the question: which of the two Perforce providers should I configure in LV? I prefer the Perforce SCM provider, simply because it's faster when working with large projects.

QUOTE (GregSands @ Nov 3 2008, 10:13 PM) Yes! That's one thing that would really improve programming in LV. It would also improve readability of the code a lot. :thumbup: QUOTE (GregSands @ Nov 3 2008, 10:13 PM) It may not be straight-forward to allow programmatic access of the array index - if so, it would be sufficient to have a popup menu to choose which index is used, and some visual indication of the usage, as in the lowest example. The edit-time-configuration would enable the compiler to optimize this code even further to get a bit more performance out of this. In most algorithms a runtime-decision which dimension is to be indexed is not necessary. Still there might be some occasions where a programmer would like to decide at runtime, which dimension to auto-index. So this feature would be a "nice to have" from my perspective.

QUOTE (Aristos Queue @ Sep 3 2008, 05:15 PM) I didn't post this suggestion there yet. Before doing this, I wanted to get some feedback from other LAVA members. But I will definitely do this sometime during the next days! Thanks to everyone for your feedback until now! Any other aspects of this topic that should be mentioned?

LabVIEW offers two great features for nice user interfaces: tab controls and splitter bars. It's really a pity, that you cannot combine them by setting splitter bars on the pages of tab controls. My typical use case for this is a tab control with "Fit Control to Pane". On a page of this tab control there might be a tree control that should use the entire height of the tab page an keep a constant width. On the right side of this tree cotrol there might be a graph that should use all the rest of the space available. I know how to programm this manually. I know how to get this effect by using a sub-panel and simulating a tab control. But I would really appreciate beeing able to use the "natural" way of setting splitter bars on tab pages. As far as I understad the logic of splitter bars, they can only be used on panes. So the tab control would need to be redesigned in a way that it's pages are real panes. (or maybe there could be a new additional "Pane Tab Control" or something?) I have no idea how much effort this wold take NI R&D, but it would really be a great feature for building professional user interfaces that are not bound to a fixed screen resolution! What do others think? Is this a good idea? Would you use this feature in you own applications, if it was available?

QUOTE (Darren @ Aug 7 2008, 04:50 PM) These are good news! :thumbup: I will consider installing the toolkit again with LV 8.6. Thank you for clearing this up!

QUOTE (Darren @ Aug 5 2008, 09:32 PM) This is surely correct. And it reminds me of an old problem with the report VIs: Did the changes in LV 8.6 fix the bug that made the report VIs incompatible between computers with and without the Report Gen. Toolkit for MS-Office? What I'm talking about: The toolkit introduced a new required input to New Report.vi, which meant you were not able to open and run a VI that was built without the toolkit and used LV's regular report functions. If you fixed this immediate problem by wiring a constant to this input, you could run it on your machine, but if you saved this VI, it wasn't possible to run it on a computer without the toolkit any more (sure, you could remove the constant there, but this made it incompatible with computers that had the toolkit installed........). Has this vicious circle been broken by now?

There might have been some shared variables in this project once, but they were replaced by a self-implemented TCP/IP-communication. The mentioned tags are propably left-overs from this time. The Project ist quite large (over 700 files and growing). It's completely under source code control, so I can access older versions any time. I deleted those two lines yesterday in the morning and worked all day with the project without any problems. If I should really run into any problems, I can still copy the deleted tags from an older version. That's one of the really nice things about using XML

QUOTE (Jeff B @ Jul 29 2008, 03:35 PM) Great! Thank you! :thumbup: QUOTE (Jeff B @ Jul 29 2008, 03:35 PM) silmaril - if you still have the LVPROJ file, open it in a text editor like notepad. See if one of the first few lines contains the text "varPersistentID". If so, there's no need to send it in. If you do not see this text in your project, please let me know. Be careful to not save or modify the project in the text editor. I'm still working on this project (and will continue to do so for the next months). My project file contains two varPersistentID-properties. Is this the way it shold be, or could that be part of the problem? I don't use any shared variables in this project. Maybe deleting those varPersistentID-Tags could solve the problem for me? What do those tags do anyway?

QUOTE (neB @ Jul 16 2008, 02:58 PM) I think you are right. Why should a simple read from an address in memory make a thread switch necessary? (But you will definetely have a switch to the UI thread, if you use property nodes.)

Could this have something to do with the environment-option "Do not save automatic changes"?

QUOTE (Yair @ Jun 27 2008, 12:03 PM) Yes, it is set to F in either case. But this is no Goldberg-code at all! It's simply a data flow solution to make shure that you really read the input value before you reset it using the local variable. OK, there might have been solutions that are easier to read (like using a single sequence frame or calculating "value AND false" or ...)

QUOTE (Götz Becker @ Jun 17 2008, 12:28 AM) Yes I agree that this type cast makes sense. Still, it wouldn't hurt to have coercion dots at those inputs, too. To split some hairs: In this example, the I16 values are not really coerced, they are typecasted, which should make a difference for negative numbers. But that seems to be LabVIEW's normal coercion dot behaviour for converting I16 to U16. If you wire a value of -1 to an U16 input you will get 0xFFFF (which is correct, but I would call this a type cast; a coercion should give the result 0 here as I understand this term).

QUOTE (Jeff B @ May 27 2008, 04:01 PM) This is exactly my problem. Since I don't have any time to dig into this any deeper, I simply disabled automatic saving in the options dialog to get rid of the message. I got the same message frequently in my current project - not only after restarting LV, not on every start of a VI, but several times a day from time to time. Maybe I can throw in some facts about the project in question: It was created by copying and renaming another project. It only has one target "My Computer". It currently consists of 300+ VIs and CTLs. It uses several LVLIBs. It does not contain LVCLASSes. It does not contain auto-populating folders. All files including the project file are under Source Control, using the Perforce Command Line client. There are some custom Conditional Disable Symbols on the "My Computer" level. If it helps, I could send you the project file without the VIs via E-Mail. Please let me know if you think this might help. If NI R&D is not able to track this down, I have one wish for the next version: Please make this error message more verbose! Right now, the only information it gives is that something went wrong. If the message contained more background information about the "local circumstances" inside the code, you would get much more helpful user reports on this.

Is there a "Most Valuable Poster Award"? I'd like to nominate AQ :thumbup: . THANK YOU for a lot of inspiration!

QUOTE (sara @ Apr 30 2008, 09:25 AM) I don't know which exact board you have, so I assume it's some NI multifunction DAQ board. The digital IO lines on those boards have pull-up resistors, which means they will always go to their high level by default. This is the documented behaviour. If you want to switch off whatever you connected to the digital outputs when turning off the computer, you might use inverse logic in if your external hardware allows this. But please be aware, that the output levels may still change to totally undefined states, if you disconnect your computer's power cord!

QUOTE(gosor @ Jan 31 2008, 03:53 PM) I don't agree with this latest addition. There are virtually no reasons to use any stacked sequences in a well-designed LV application. There are even fewer reasons to use sequence locals. I don't think NI should invest any extra development time in a feature that only supports bad programming style. Sorry for the harsh words, but I had to go through my share of stacked-sequence-applications, and I didn't find one stacked sequence which could not have been replaced using other features, like sub-VIs. In all cases, this would have improved readability of the code a lot!

QUOTE(PeterB @ Jan 28 2008, 12:34 AM) That's interesting, very interesting... If user events don't force a thread switch, I have absolutely no idea, why my application wasn't able to run properly on a single core CPU. I cannot explain, why changing my user events to queues solved the problem. QUOTE(rolfk @ Jan 28 2008, 10:48 AM) But they execute in a structure that also handles all the normal UI events that WILL switch to the UI thread for sure. And also might contain a timeout case that will also snoop some time for handling. In my case, I had the impression, that the loop that fired the events was delayed. A delay in the UI part of the application wouldn't habe posed any problem. QUOTE(rolfk @ Jan 28 2008, 10:48 AM) ONe extra point. Queues are very specifically optimized to NOT copy data at all but instead use the reference to the data instead. User events might not be able to use the same optimization in all cases or even at all, especially if you use multiple event structures to receive the same event. I transported only a few bytes for every event, so I don't think this really is an issue. But I don't want to hijack this thread. We could discuss this topic much more easily with an example that shows the behaviour isolated, but I don't think I'll be able to reproduce it easily.

QUOTE(jfazekas @ Jan 26 2008, 03:20 AM) Maybe the problem is due to something else. It seems to me that queues can be handled in any execution system, but events are always handled in the UI thred. Even for firing a user event, LV has to switch to the UI thread. I had an application that used user events and several parallel loops, which worked fine on my hyperthreading PC. It didn't work properly on the customer's PC without hyperthreading, until I replaced the user events with queues. So I think it's fine to use UI events and maybe user events for UI puposes, but for general communication purposes I'll stick to queues and notifiers.

QUOTE(jlokanis @ Jan 22 2008, 06:01 AM) That's exactly what I would like to have! Sounds great, but I don't know where to start.

QUOTE(neB @ Jan 20 2008, 03:37 PM) That depends very much on what you call "interesting" If you are really making large projects using LV, it certainly pays to invest some time in learning about architectural issues. The big question is, if the NI way teached in the courses (and asked in the exams) is the one only right way. And I think it's no question at all that having a certification makes nobody write better programms. It's a little bit like a driving license: When you finally get it, you can really start learning to drive. QUOTE(neB @ Jan 20 2008, 03:37 PM) BTW Congrats to you Silmaril ! :thumbup: Thank you very much, even if my re-certification was not very re-cently. (*ouch!* ok, I'll stop the puns...) QUOTE(crelf @ Jan 20 2008, 03:54 PM) I just had a few guys go through CLA for the first time, and their pass mark was set at 70. I think it's 75 for the CLAD and CLD and 70 for the CLA. Anyway, just stay above 90% and you won't have any problems.

QUOTE(i2dx @ Jan 20 2008, 09:46 AM) Of course there is a difference! You have other questions to solve! OK, what really matters is that the recert exam is exactly the same exam that someone has to do who does his first CLA certification on the same day. There is no "short version" ro the recert people. I had my first CLA re-certification half a year ago and found that the exam topics really had changed, since NI had introduced a completely new LV Advanced course. But I don't assume the topic changes will be so big in the coming years.