Leaderboard

I just drop it on the Block Diagram of another VI and open it from there. It doesn't run when opened that way. That variable is from the JKI State Machine, from which I refactored this VI because not everybody uses it.

I also have described similar situations (I think on the NI forums). The main takeaway was that the function is in fact named Request Deallocation, so I guess "Request denied!" is a valid response. Actually I looked at it in some detail at the time and I seem to recall it worked like this: string arrays are stored as an array of handles to the individual strings. RD dutifully returns the memory used by the handle array immediately but the memory used by the individual strings is not freed. I could troll AQ and discuss the LV garbage collector, but there is not one so that memory is not going to be freed in the normal sense. I seem to recall that the memory is reusable by LV so it is not completely lost, but LV can be the RAM roach motel, bytes check in but they don't check out. The quick and dirty solution I have used the few times this has been an issue is to put the offending code into an executable which I can then run dynamically in its own context. Either as a one-shot process or as a daemon. Reclaiming memory was as simple as shutting down the process and restarting.

I was off on vacation. But I got the info I needed -- this is a used feature so don't muck with it. Thanks, all. Oh. I just saw the raft of posts asking why I'm asking this. It's mostly so I know where the bounds of brainstorming are when trying to improve communication systems. I've always thought it was kind of dumb that we enabled multiple event structures within one VI because of the static registration of events, and it was just one more axis I have to worry about if I do anything in that area. I can't answer the question "what would we be getting in return" because I'm not sure -- I don't have a firm proposal at this time. I needed to know if it had intrinsic value at all because it simply does not in any programming I've done. Indeed, my first instinct when I've seen code that does this is to say, "I'm guessing your bug is here, and I bet it gets fixed if we refactor to remove that second event structure." Y'all highlighted some reasons why you like it. I'll keep those in mind.

CLA Summit 2014 Theme: You Call It We're going to try something different this year for the 2014 CLA Americas Summit. There was no clear winner in the topic selection voting, so we want you to present on whatever topic you're most interested in! From the presentation abstracts that are submitted, we'll look for common topics and schedule them together to form mini-tracks. Depending on the number of volunteer presenters, we'll either select those that receive the most likes on the forum, or we may decide to schedule tracks in parallel. See full post here: https://decibel.ni.com/content/message/62947#62947 Can't see the page? Please join the NI CLA Community page! As presentation abstracts are submitted, feel free to "like" them so we can gage community interest. Thanks for stepping up to present! I can't wait to find out what you have in store for the next CLA Summit. Should be exciting! Nate

I looked up your crash report and it seems to be crashing in agtrmsimulate.dll, which looks like a 3rd party driver dll. Hopefully that helps you narrow it down. I would double check how you are calling the driver.

Is it very reproducable? Can you make it crash every time? If so this makes life a little easier. I'd recommend disabling large parts of the code and see how it effects the crashing. This can help narrow down what code is causing the issue. If I had to guess I would say it is likely a bad DLL call, or a .Net function that isn't being used properly.

Posted Today, 02:41 PM Val Brown, on 09 August 2011 - 03:26 AM, said: An event is an event and, while each event will have a timestamp, none are polled but all are received -- regardless of the action taken by the structure. Exactly! Val Brown, on 09 August 2011 - 03:26 AM, said: An unregistered event is STILL an event -- and can't NOT be an event. I agree with that, as long as I can change it to: Val Brown misquoted by crelf said: (Hey! I did NOT say that the damn IDE did) An unhandled event is STILL an event -- and can't NOT be an event. My comments begin here: I think what you might mean -- to be precisely accurate linguistically -- is that an event is STILL an event -- and can't not be an event. AND a REGISTERED event is not JUST an event. It is an event that has an additional component (viz the "registration") and should, therefore, expect some additional response, such as to be received by some event handler in a way that doesn't just get "lost in cyber hell" if the programmer falls asleep at the wheel. Yes, I understand that argument and it's the basis for a great architectural discussion -- one that already happened about 30 years ago in some circles, but that's another story for another time (if you're not already yawning....). Now regardless of that history, it is exactly that extension that I object to -- because an event is an event. Even registering an event shouldn't have an influence on the event per se, nor it's overall construct unless it's an object and being an object becomes an intrinsic attribute of an event; or else the default IDE behavior should be to populate a case SOMEWHERE that explicitly receives that (now) registered event and forces an error if not explicitly handled by the programmer. Now the argument could be made that the event handler could have some other facility for handling registering events that do not have an explicitly declared interface; and essentially that is what is being argued here by those saying "isn't this a bug?". And perhaps that is an attribute that even should be integral to a well designed IDE but I'm not so sure about that -- at the conceptual level. And, yes, all of these various ideas would make life easier in some ways. So, in the end, it's frequently expediency that prevails.I just think that the philosophical issue -- history aside -- remains important, regardless of how it is answered in a particular IDE like LV. OK, back off the soap box and time for more beer...ah actually single malt. FWIW as a user I say: NI make it easy for us. At another level though I think these various changes are a problem waiting to happen down the line because they break (OK bend) the purity of the IDE at the abstract level.

I see a new future for an "Obfuscated LabVIEW" contest! This feature (of course with misleading documentation) could send a code maintainer on a round-robin chase that could last for weeks if not months I think I understand the discussion - Here' what I think I'm reading 1) the event is registered (associated with a structure) 2) it is never handled explicitly in that structure 3)The event fires (somewhere) 4)The event case with no explicit handling implicitly handles the event (which resets the timeout timer) 5) as long as that event keeps getting fired faster than the timeout value, the timeout never executes even though it appears the event structure is sleeping and not handling any events If this is correct, I have to come down on the side of allowing the user to require the event structure to explicitly handle each event (I think that's what crelf proposed, if I'm following all this) just like removing the default value from case structures requires the user to explicitly implement all cases. I have to have a good, well considered reason to include a default case and I would want a good, well considered reason to have an event case that doesn't explicitly handle an event that I register for. Mark

Probably is if you are talking to architects and experienced clds. But "most" labview programmers aren't and the limit of IPC conversations tends to go as far as a producer consumer loop with queues and that's about it.. I've yet to see a student, electrical or electronics engineer (LabVIEW is still seen as a secondary skill in many companies eyes) talk about IPC and messaging systems. And I've worked, and interviewed many. And those are exactly the apps that can fall fowl of this "feature". I've commented many times about how I feel that events have been neglected. So you are preaching to he the converted here. Well. Actually, in the strictest sense, Events shouldn't have a timeout at all. An event is either signalled or is not not. No other language I know of has event time-outs and if a programmer wants to time-out if no event is received within a time-frame, then he has to create a timer that gets reset when an event fires. This is probably why the event case is as it is. The windows forms message callback (Wndproc) just has a timer that gets kicked on entry. As for not registering unless you need to react. that is only applicable at design time. What if you have configurable alarms? You will still need all the cases on the off-chance that a user will want to register it and receive feedback. thats one of the more useful (but rarely seen in LabVIEW) uses for events. Unfortunately, I don't think it is "cool". At best it's unexpected behaviour and explains (IMO) a lot about problems people have seen with xControls.

I'm in on the Justin and JG bandwagon. (not very crowded yet ) Doesn't anyone else think that a "timeout" that can never time out is in the least bit strange in concept? Sure you can find a use case for it. But I bet there is far more instances of head-scratching and cries of WTF. On the shoot yourself in the foot scale of 1-10. It's a bit of an 11. It's also one of those "issues" that you come across from time to time where the whole app just doesn't work, but when you try to debug. Everything works fine in isolation (or if you slow it down).