Leaderboard

Hi all, Just wondering what your opinions are on the 2010 integrated development environment? I'm loving some of the new 2010 features, but the stability of the IDE has left me...unsatisfied. I'm not (yet) contemplating going back to 2009 for my main development needs, but the 2010 platform leaves me a bit uneasy when I think about starting large projects on it. I only develop on two systems (XP and Win7), but they seem to persist across both platforms. One of the first things I did when I got 2010 is start to design a version 2 of a reuse library I've been waiting on. Some issues that I haven't been able to pin down but happen to me several times a day: In the project explorer, classes/libraries often complain of unsaved members when there are none. Also in the project explorer, items removed from classes/libraries get removed from the list, only to somehow stay attached to the class/lib and often reappear. Seems related to point above, often when trying to save new items (say a new method), the class will complain there are other unsaved items, I'll get prompted, and have the old item reappear in the explorer. Editing the icons of nested classes/libraries is a complete crapshoot. Pretty much have to move any item to the top project level (outside of any containing library) if I want to edit the correct icon. This does not happen with VIs, but for classes nested in libraries, editing the class icon seems impossible if the class is contained. The whole IDE has crashed several times on me while trying to save. No error reports, no investigation when starting up the next time, nothing. IDE just vanishes. Work gone. Worried I'll eventually get corrupt VIs from this. I'm trying my best to be analytical about these things so I can pin down examples of what triggers the behaviors and send examples to NI, but so far I'm coming up empty. -m

[This message was also posted here on the ni.com forums.] All of the presentations for NI Week 2010 are available in the NIWeek 2010 Community. If you attended NI Week, you should already be a member of the community. If you did not attend NI Week, click on the link and request to join the community (you will have to create a user profile if you have never used the NI Community pages ever before). Approval to join the community may take a day or so. Once you are a member of the community, you can go here to get a full copy of the "LabVIEW Classes: The State of the Art" presentation that Mike Benza and I gave, along with all the VIs used during that presentation. I spent the bulk of that presentation discussing my new Actor Framework.Many users have spent time developing mechanisms for starting up multiple top-level VIs, establishing communications among those VIs and then tearing those VIs down when the app completes. It is easy to make a system that works sometimes. It is very hard to make one that always starts cleanly (so no VI misses early messages), avoids deadlocks during communication, and actually shuts down all running processes. Very hard. Multiple users have posted their attempts to me. At the same time, I've been looking at state machines, that very common design pattern for LV programmers, and lamenting that if I build one state machine for a project and then I need that same machine but with just one more frame of the case structure in another project, I have to copy all the code. How do I build a state machine that I can inherit from and extend? These twin challenges lead to the development of the Actor Framework. It incorporates ideas from several similar frameworks developed by users (both internal and external to NI), and adds a few extras to make it really robust. I found one CLA who lives near NI to test drive the framework in a real-world application. That work is still ongoing, but so far, the framework appears to function well, with good performance and no missing functionality. More importantly, it is easy to pick up and learn -- we decided that was important since so many of the macroscale frameworks that have appeared in the last five years have a steep learning curve. The framework should not be considered "finished". The presentation includes some notes about further refinements that we have planned, and I am open to further suggestions from the community. I would like to see this develop into something that we can share next NI Week as a polished set of VIs and classes that any of our users can pick up and run with. Please post any comments you have about the framework on the community page where the framework can be downloaded. That way any conversation about it is centralized instead of being spread across the forums, LAVA and the NI Community. PS: The Actor Framework is saved in LV 2009. You do not need LV 2010 to view and use the framework.

Here's a little startup: StructToVariant.vi This VI will try to read a Typedef and return it's contents as a cluster with the right elements. Together with the Variant to Control (with which I would like to integrate this) you can convert a typedef-string into a (typedef) control file). I have tested the converter with the following typedef string: typedef struct { uint32 header_sz; uint32 width; uint32 height; uint16 nplanes; uint16 bitspp; uint32 compress_type; uint32 bmp_bytesz; uint32 hres; uint32 vres; uint32 ncolors; char nimpcolors;} bmp_dib_v3_header_t; and the following Enum struct: typedef enum { BI_RGB = 0, BI_RLE8 =3, BI_RLE4, BI_BITFIELDS, BI_JPEG, BI_PNG,} bmp_compression_method_t; It supports sparse Enum's for instance. It however does not support nested structs (reference to another), that might be something to add. If you make any changes I would like to see them here. As said earlier, have you looked at the Variant To Control tool-VI? Ton

Open the VI properties (by hitting CTRL + i) go to the "Execution" section and tick the option "Allow debugging"

Nobody has ever beaten me, and nobody ever will. Now *that's* a call out... -D P.S. - I need to have a talk with the judges next year about literal interpretation of the rules, because Robert's answer for the 7-segment display was NOT a 7-segment display. Thankfully he messed it up just a little bit, which gave me enough time to finish my real 7-segment display while he tried to fix his...