crelf

This is analogous to wiring up an enumeration to a case structure, where a value is not handled.

Hmmm. I understand your analogy, but I don't think it's completely appropriate in this case (pun intended). It would be true if the event structure was analogous to a case structure, but it's not - it's an event structure, not a case structure. For yout analogy to hold true, we would only be able to have user events, and not FP events.

...I'd say it should stay the way it is for no other reason than precedence has already been set.

I don't think one case really qualifies it as a precedence. (well, less than one, as described above).

There may be issues with this approach, and it may not be intuitive, but if I can quickly come up with a use case like this, it means that someone out in the world may have used this same idea for an actual realworld VI, which would make it hard to mutate away.

It think it could be incredibly useful, especially in cloud computing. We have a reuse architecture that uses something very similar, and are in discussions on how we could use this newly discovered functionality (yes, that's what I'm calling it) to simplify part of that architecture. I don't know why you'd remove this feature of user events because its behavior is inconsistant with FP events - they're two different kettles of fish that just happen to be handled by the same structure IMHO.

We register for Front Panel events by creating event cases for them, and events that don't have cases don't interrupt the timeout. Why would we not expect User Events to work the same way?

I don't think so - user events and FP events aren't the same thing, so neither of them should be limited by the capabilities of the other.

It's virtually impossible to detect when this is happening in your code. In the attached example, the event structure looks like it should be timing out, and in a complicated application it's almost impossible to tell why it's not.

Then you should either lower the complexity of your code, or document it better. That iIt might be difficult to work with in complex code isn't a reason to limit functionality IMO - imagine what other LabVIEW features would be removed if we reviewed everything against this standard.

I agree it would be clearer if LabVIEW were adding one case per dynamic event to the event structure when the register event node is wired to the structure.

Perhaps LabVIEW should note it as a warning (you're registered for an event that you don't handle), because we all have warning reporting turned on, right?

Hey, you stole that from me, in our Skype chat!

Think of it as a tribute. Actually, I think I spent more time correcting spelling and grammar mistakes that it would have taken me to type it out myself

Unintuative = yes, bug = no, should it be the default behavior = yes.

Let me explain: I agree that it's unintuative, but I do not agree that it's a bug. Most people would expect that they'd need to write an explicit case for that event to be handled, but the event structure is *receiving* the event, and that resets the timeout - whether it's handling it or not is irrelevant. Try not to confuse "firing events" with "handling events".

Put simply: you registered for an event, the event occured, the event structured saw it - that resets the timeout, irrespective of whether it does something with the event. It's totally the corrrect behavor - the only argument can be whether it's intuative.

Now, should you be able to register and not handle events from the user interface? That's another question The "problem" really is that it's not clear what *registration* means, because we don't have explicit "registration" for normal FP events: we just implicitly register for those by creating cases. I still don't think it's a bug though - just because two types of events (and they really are two types) can be registered in a different way doesn't make either of them wrong.

Do the need to be in a DLL, or are you just trying to have them appear in an ActiveX-like interface? If the latter, put them in a class - then you can access them (they're in a class now, so let's call them "methods") through property nodes.

For some reason it appears that my Event Structure was locking the Front Panel. This is confusing since, according to LV's dataflow, this Event Structure should be done executing.

Well, if the event structure is reached, it needs to either wait for an event, or timeout. I'm wondering if the loop you have isn't stopping, and it goes around again? Can you give us a screenshot? Or upload your code?

...a temper chamber...

I know a few people that could do with one of those

That's great advice!

I wouldn't expect language like that from you of all people, Crelf.

It's a folksy term of endearment, I promise

Are you going to give yourself a warning?

If I did, wouldn't that be a type of self-abuse, so to speak?

http://www.youtube.com/watch?v=q8mCUyYA1qE

Congrats on the 1000 and the missus François!

I use hyperterminal You can copy it from a PC with an OS that it comes with to the other PC, and just run the exe.

You can also set DAQmx channel names, and even apply configurations to MAX at runtime (look at loading nce files).

We're thinking of you!

Let me start by saying that I know this shouldn't irk me, but it does. Someone left a bad reivew of my book over on amazon.com. Normally, it wouldn't worry me, as from reading the review it's obvious that the reviewer wasn't the intended target, but what gets me is that it's the only review there If you've read my book (and you liked it ), or even if you've leafed through it, I'd really appreciate it if you wrote a supportive review and/or a comment on the negative review that's already there.

...and let me end by saying that I know this shouldn't irk me, but it does.

Yer, it's pretty similar.

That's good to know. When I did my CLA it was 10 essay questions, where I had to write (yes, hand writting) responses on a peice of paper (PCs were banned from the room). I have poor hand writting, so I made sure key words were printed (INSTANTIATE, ENCAPSULATE, MODULARIZE, DYNAMIC, etc).

I found the toughest thing about the CLA was the length but I managed to finish just enough to pass.

TWSS.

Works for me

I would like to capture video (30Hz, 24bit color, 640x480) in sync with some DAQmx channels. My question is what hardware is recommended to support the video portion of the system. I am planning on a cameralink interface that has hardware triggering but am not sure if I will need any special RAID hardware for the streaming to disk.

I'd probably use a PXIexpress camerlink card and one of these (there are other modles with more space) so you can get the data straight to disk without going through the processor or PC infastructure.

The data needs to be streamed to disk and retrieved back to display in realtime with data.

Use DIAdem - it does all the work for you (video example here).

http://www.ni.com/swf/demos/us/diadem/vidsync/vidsync.swf

As an aside - little know feature (due to accessing it IMHO): right-click on a front panel's horizontal scroll bar and select "properties" - now you can set a static background.

I'm not a Perforce guy, but setting your whole drive as your workspace sounds like a mistake to me. Why do you want to include <instr> and <vi.lib> as dependancies? Sounds like you need to take a look a VI Package Manager.

The old VIE LabVIEW Advanced Architectures Course (that was subsequently purchased by NI and rebadged as the LabVIEW Advanced course) had an example in it where there was an engine that did all the interesting stuff, and there were 2 UIs that just handled events from the user (well, they weren't event-events, since the event structure didn't exist back in the ol' days ) as well as handing a reference to the VI back to the engine which would then update the UI using "Set Control" by-name methods. I'm not saying it's necessarily the best solution, but I recall it working well, and if you added in a true event structure then I'm sure it would be sufficient.

But on second thought, maybe that is not what Chris was hinting at.

Not at all Ben, not at all. I wasn't really hinting at anything specific, but I'm sure that the oneandonlyjim would find a good home at DSA

PS: you should list here: http://lavag.org/forum/31-job-listings/

FYI: Steve said:" Nobody knows how to program with 'multiple core'." and Bill:"All the S/W nowadays have to deal with the 'parellel' problem."

I think someone needs to get that pane on a tshirt

Hazaah!

I've found the best mentors as those you work beside - there's something to be said for working with people that are better than you: you're always challenged, and it's the best way to improve. So, looking for a mentor is a good idea, but looking for a company that is full of mentors is even better!

In general I agree with you. However, LV disallows more than just editing when a vi is locked. I can't copy-and-paste code or controls from a locked vi to the vi I'm working on. I can't right-click >> Find All Instances of a locked vi.

Two excellent ideas, but I think they're out of the scope of the idea I'm suggesting. That said, I think what you're saying is important, so I've created Allow copying of FP and BD elements from locked VIs (that one really irks me too) and Allow "Find All Instances" on a locked VI.