Grampa_of_Oliva_n_Eden

Same here when it comes to ActiveX. I would start dropping and wiring invoke nodes and property nodes and wiring them to the ActiveX wire and look for something that looks good or you could try the help for those properties to get a clue. A very long time ago it was possible to get the VBA version of the help for MS stuff by doing an advanced install of the MS stuff and make sure that "Help for VBA" is checked. It will not give you LV code but it will give you VBA examples that can be used as inspiration in LV. Ben

ActiveX stuff runs in its own world so you will have to poll to see if it still running of generate an event when the vieo comletes. Ben

In theory yes, but in practice we should keep in mind the nautre of LV and not "drink the kool-aid" and expect LV to do our thinking for us. Performance! There are code construct that will absolutely freak out LV's inplaceness algoithm in which case it exercises the default rule "if not sure copy the buffer". Complex clusters seem to encounter these issues more often than the simple data structures and as LV evolves, where the in-placeness freaks, can change from version to version. So putt large data structures in a cluster in a SR and passing it in and out of sub-VI's can bite us. Two branches off that idea: "The key the key and nothing but the key so help me Codd." LVOOP LVOOP first. It seems that Aristos and his team but some excellent thought into the LVOOP data strutures. Mainitaining a class instance in a SR and invoking methods on the wire really "feel" like they are pointers. Confesion time! I screwed up in one of my apps and cast (using type cast) a LVOOP class as an array of the class by mistake. I was baffled by LV crashing and passed it to NI as a bug in the TDMS functions. After Aristos traced down MY ERROR, I fixed the code and all ws fine but what really clicked on the light bulb for me was that improperly cast wire ran through a mile of code with out causing a sinlge issue and it was only when it came time to actually acces the data inside the class wire (down in the TDMS functions) did the actual data make a difference. This bug experience should me just how little the LVOOP stuff is touched. Now back to Codd. I have never officially studied Normalization rules, but I have learned some from my wife. I have tried to keep some of those idea in mind when I design my clusters thinking about the clusters as if they were tables. Applying normaliztion rules help me sperate data that has nothing to do with each other while grouping those that do. (part of this can overlap with OOP ideas I suspect). now returning to a point I made early in this thread, if a data structure is only used in a small fraction of the states, move that data to an AE so that it is not being carried around with other data that it has nothing to do with. So yes, SR are the standard approach and seem perfect for LVOOP, but if you have a performance challenge staring you in the face, special attention should be given to who where and when they are touched. Just trying to firm up my ideas, Ben

My little time with LV 10 under XP did NOT show any delays. I don't have auto-save turned on. Mybe I just didn't notice the delay or maybe the VI wasn't large enough. Ben

I agree with most of what you posted and tend toward keeping the number of cases low (in state machines) but the number is not the critical factor but rather the State Transition Diagram (STD) that is realized by the code. I suspect someone out there knows the theory behind it but the point at which STD get confusing is when it can no longer be drawn in a single plane, i.e. the transition lines have to cross over others. That is what I concider my "stop and re-write" point durring the design process. But before I let the diagrams get to that point I will start creating sub-STDs with a cohesive function and replacing the calling STD's code with the new "state". These are generally characterized by "single line in... single line out" structure in my STDs. But that is off-topic now so I should stop. Cat, Yup. That is what the double smiley-back at you was all about. Ben

I've had that tee-shirt for years and little did I supect that with it I could have built the tower of Bable, get Steve Jobs and Bill Gates on the same page, and adjusted my own eye glass perscription. Maybe it would have been obvious to me if I had an Add tatooed on my hand and could fly. Was that LV 7? Ben

Sure, as long as I don't have to support the code. Does your definition of "Pure mess-reduction" completely ignore performance and ease of support? If so I agree whole-heartedly. :P Ben

Thank you. Ben

And for every customer you trick talk into signing up, you get another increment of free storage. Ben

Similar to what I teach my people. If the SR's are well designed clusters (only related data is grouped) then you can quickly spot which SR to move into the AE's by clicking through the states looking for a SR that only gets touched in a handful of places. Ben

A couple of ideas come to mind. 1) Judging by how often the titles people have change the competion could sneak in and lift the needle off the record* and let everyone scramble for a new chair. 2) Put an offical looking sign out front that reads "Nobody that appears to be older than 30 permitted beyond this point." Ben *Well that is how we played musical chairs when I was a kid.

if there are different widgets hanging off that visa ref that talk different languages then differnt sub-VI are used. If we don't know the nature of the widget.... Ben

Intead of using the invoke node on a VI that does what you want, set-up a background VI that will do the same thing but without the "invoke node" whenever it is told to do so. In my case I use queues to send the message to thew background VI. But that was only a suggestion on how to get er done without using invoke node with the assumption that the UI thread was slowing you down causing timeouts. I did a lot of specualting to help give you ideas. If they help, only you can judge. Ben

I don't think I ever got a straight answer but I have this suspicion that "Call by ref" runs in the UI thread, so couple that possiblilty with some of those old serial wdget being impatient about comm time-outs... 1) Can you make it worse by run a parallel VI set to run in the UI thread that gobbles up CPU (to confirm)? 2) Can the timeout on the laser be extended? 3) Run the laser code as an active object then interact with it to do the laser work for you? That's all that comes to this mind, Ben

2011 is only going to be as good as the Beta testers make it. That da#$ EULA for the Beta's (paraphrasing now... if you run into trouble with the beta code, please report the issue but don't count on us to help..) keeps all of the serious development testing out of the picture until the official release. As long as there is just a bunch of people poke around the theri spare time on toy projects. G-Story One of the most solid version of LV was LV 6.1. AS i understand the back story, Albert Gevens really beat that Beta version up. His work was so important in version 6.1 that NI recognized him for his efforts and made him a ... MVP or a Featured Developers or some such. What I feel would fix the buggey releases: Cash. NI should go through thier records of bug reports and find a core set of bug-hunters and approach them about paying them to develop in the beta version, AND back them up with a commitment to fix any bug they find prior to the offical release. From where I sit I am still seeing the same pattern repeateded over and over. "dot-zero" version released and I sit back and wait for the bug reports. I avoid upgrading except where my customers have selected the blue pill and I am forced to take the dive into the hole with them. The I go into a routine where I am calling support almost daily with conversation that end with "Well senf me an e-mail with the CAR number and I have a hrad time believing anyone who knows what they are doing actually tested this!". 2010 story NITS here in Pittsburgh, I was selected to do the Darren routine about the new features in LV 2010. So blew through his material in about 15 minutes and started answer random questions from the crowd when I found myself trying to edit the icon while they watched. Little did I realize the "New and degraded" icon editor was busting full of bugs ( ctrl-V double paste, no drag after select argh!!!). I don't think any of the crowd realized I was dealing with a bug because I stopped and "Pulled a cake out of the oven" to show the final results. As a consultatant I also find the bugs particulary frustrating because I have to deal with customers asking "Why do you like LabVIEW so much if they are shipping crap?" I did not expect this post to turn into a rant but I guess it did. Ben

Wiki-leaks nominated for Nobel Peace Prize http://www.foxnews.com/scitech/2011/02/02/wikileaks-nominated-nobel-peace-prize/ Ben

About 20 years ago I was sticking around late in the office to teach myself C. One of the hard core Fortran Cobol types asked "Why bother?" ... it is so cryptic etc. I think there was a similar thread about switch over from horses to automobiles. My appraoch is sorta symbolized by Jim's avatar. Technology is a wave were you have to stay on the leading edge. Failure to do so will result in a wipe out and you will have to start all over again. Ben

I was refering to the terminal on the icon connector. Ben

clcicking on the icon terminal should give you marching ants arounf the selected object. I guess that is not workin for you? Ben

Ditto that. Ben

I wonder if this issue can be tracked back to the OS and virtual memory. From what I understand (other jump and fix my errors please) LV force a page fail on all of the code when it loads a VI to avoid pagefail waits while running. While the OS is handling the page faults and mapping virtual memory for the app, it is running in kernal mode (show kernal times in the task manager) to do the memory managemnt work. While in kernal none of the normal tasks are even concidered unti lthe memory mapping is correct and complete. Loading other code (i.e. opening Excel) while LV is running has always had this affect. SO that all makes senes to me. THe only hole I see for LV to escape thru is "in what thread do the menus run?" and there maybe some hook keeping menus in the UI thread. The above is a lot of speculating on my part. Take it with a grain of salt. Ben

Like he said. Ben See here