Yair

There are various controls here - http://lavag.org/files/category/1-user-interface/ You can also find some stuff here - https://decibel.ni.com/content/groups/ui?view=documents

There should be a post in the scripting group on NI's site with the values. Do a search for "DPID" and you should be able to find it.

You need a reference to the control so you can call the Move method on it. To get that reference you first need to drop the control somewhere: The easiest is probably to use the New VI Object primitive to drop the control.

You can call the Move method on the new control and specify the cluster as the owner. This will move the control into the cluster.

If you just want to save and load the values from controls, you can find a simple example here - https://decibel.ni.com/content/docs/DOC-15349 That example flattens the values, so it's unlikely the users would touch them, but you can also use the OpenG VIs and simply place the files where the users don't look. This should usually be enough to protect from users touching them.

First, it should be pointed that you have an uncontrolled memory allocation, because each call to Obtain Queue creates a new reference to the queue. Second, if I understand what you want correctly, the easiest way is a VI which looks like this: At first call it generates the SEQ (or DVR, in this example, because it has some advantages), then it just returns the same reference on every subsequent call. This doesn't handle a case where the queue was destroyed, so if you want to handle that, you can check the reference coming out of the feedback node for an error and generate a new one if there is an error (which would also happen on first call).

You should follow the instruction in the error message - contact NI and ask them to check this.

There is one option I can think of here - that the user double clicked the button in the subVI and that the subVI closed after processing the first click. The event structure then remembers the second event and processes it the next time the subVI runs. I have seen this happen before, but this doesn't seem to match your description, though. I've actually been thinking of posting an idea to the idea exchange for a feature which would prevent this from happening, but I couldn't come up with a good method of preventing this and it is a relatively rare occurrence, as it only happens with users who double-click buttons.

The schedule usually appears in the NIWeek section of NI's site two or three weeks before NIWeek itself. The schedule wasn't very good with all kinds of things in previous years (such as easily resolving conflicting session times or easily seeing exactly what it is that you want), but it is workable and it may have improved this year. In any case, you should definitely register there beforehand (by adding the session to your schedule), as some sessions get filled up and my understanding was that registered users get priority (they scan your badge at the entrance to each session). If the session isn't completely full, though, you should have no problems with entering any session which is listed on the public schedule.

Also, just to be on the safe side - a value change event is also triggered if you call the Value (signaling) property on the control, which is relatively easy to check by looking for all of the control's references or property nodes. This doesn't cover everything (e.g. someone using the pane's Controls[] property, but it covers most of it. Also, this can't be done for latched booleans, so if it's latched, you can also know it's not that.

wouldn't that be plancking? Also, correct me if I'm mistaking, but wouldn't something of "planck" sizes technically be unable to be laid flat? And it wouldn't fall, because it would be small enough to stay on whatever it was put in.

I'm not sure how the memory profiler presents the data, as I only use it rarely. In any case, I would agree that it would be nice if this was changed so that a reference would only be destroyed after all the hierarchies which use it stop executing. I know that NI is aware of this desire and maybe one day they will change LV to work like this, but that's not the way LV behaves today.

In general, references are automatically destroyed when their hierarchy goes idle or out of memory. The hierarchy is determined by the top-level VI, which in your case would be the daemon. One way of working around this for queues and notifiers is to obtain the references by name. Then, the reference which was created in the daemon will be destroyed, but if the queue still has other references, it will not be destroyed.

I suggest you do a search here, as there should be some references to how to build applications which comply with the LGPL license using the OpenG builder. In any case, I thought that all of the OpenG packages were moved to the BSD license quite some time ago, partly to avoid this issue. Which package are you using? Can you update it to a newer version?

I don't understand the question. You have to use the DVR with the IPES. That's the only way to access the data. That's the whole point of the feature. A shift register doesn't make sense in the context of two loops, since it's obviously localized to only one of them. If this doesn't help, I suggest you upload a simple example which shows what it is you're doing.

Here's another sketch of my version, with some borrowed graphics:

I'm assuming the color history is kept in the INI file. Maybe you don't have write permissions to the LV folder? It should be fairly easy to check by changing a setting which is written to the INI file.

Well, this one is a shameless steal from Jim, and I'm not sure it's really practical for a shirt (and of course it's just a quick sketch), but: Also: From here (and please don't comment there. It's practically dead by now).

I thought there was some sort of legal issue there, where someone else had rights to the name. I know that NI has used "G" officially and unofficially since the beginning, so I was sure that this was the reason that NI seemed to be trying to avoid using it officially in recent years.

The OpenG VI should have "panel" in its name (and it's in the variant configuration VIs palette), so you can use the palette search feature (or Quick Drop, loadable by pressing Ctrl+Space) to search for that term. Also, this method can help you if you want to save specific controls - http://decibel.ni.com/content/docs/DOC-15349

This obviously isn't a fair question, but what method would you actually be likely to use (use number of seconds in day, create a helper time object, parse a string, have separate inputs for T/M/S, etc.) and why?

You should get used to it. Clicking the broken run arrow opens the error list window, which shows all the errors in your hierarchy and provides more details than the tool tip description. It's a tool which you should get accustomed to using (hint: the VIs which are actually broken appear at the top of the list and have red Xs next to them).

Yeah, well, flat sequences are evil. Long live the stacked sequence! I think you meant "cue Rolf". That's a bit outside my comfort zone (by about that much - ).

You can have a look at these two links: http://zone.ni.com/d...a/tut/p/id/5317 http://forums.ni.com.../503801#M240328 And then, if you want, you can also read this, which makes an important point about some of the issues.

You may need it for backward compatibility, but it should be pointed out that in recent versions the comparison palette has a shipping primitive for checking if an array is empty.