Leaderboard

I thought we could start listing some of the things others have used successfully to convince their bosses to send them to the CLA Summit. Here are some of the links I recommend: The official NI page: www.ni.com/cla-summit says some of the advantages are that you get the opportunity to: " Network and exchange best practices with other CLAs, NI executives, and engineers Preview and influence the LabVIEW roadmap and unreleased product features Meet one on one with NI R&D developers Recertify as a CLA for free " Also, Justin Goeres did a great blog post with the 5 reasons you shouldn't miss the CLA Summit And Chris Roebuck, Europe CLA Summit chair has his own variation of the 8 reasons you shouldn't miss the CLA Summit Any other ideas out there? I hope I get to see all of you who are already CLAs there. Regards, Fab

Primitives are not stored as an entity on disk, but are directly created by code residing in LabVIEW.exe. The LabVIEW menu palettes then hold links to those pirimitives. Creating primitives not made availabe through the menu palettes is a function of the Create Object primitive that is part of the scripting palette extension. This node has a ring input that contains all the primitives and controls, the LabVIEW executable contains internally.

Vea lo fácil que era!

Indeed.My brain shuts down contemplating Daklu

Can I work for you please? The Euro summit is in Paris this year

Before the summit started I was not the least bit interested in obtaining any certifications. It's fair to say the summit was the only reason I did pursue my CLA. (Though now that I have my own business there are other reasons to maintain it.) What kind of "sponsorship" are you referring to? If it's just someone to pay the fee, I took all of my certification exams free of charge. They were offering CLAD exams free at a local Dev Days, and my local reps comp'd me the CLD and CLA exams for doing user group presentations. Seriously... Architectural Summit >> NI Week.

Fab, You could just bribe yours with a Jalapena Margarita at zTajas....

Addmission to the summit is free for CLAs.

If you like Markdown, I have created a library to use the LabVIEW report toolkit. See at Bitbucket Ton

Okay, I found some code from a couple years back we can pick apart. It contains some extra complexities, but it's real code--I wrote it originally intending to eventually release it--so maybe it will give us some more insight into the issue with Must Implement. I'll let you decided if it's close enough to your use case to be worth discussing. The attached project (LV 2009) contains one of my early exploratory attempts at creating a List collection for LapDog. Lists behave similarly to arrays, but they don't allow or require the same level of detailed control so they can be easier to work with. The goal was to permit end users to customize both the implementation (to improve run-time performance) and the interface (to permit strong typechecking) independently of each other. The List class (and its future subclasses) is the interface the client code would use. The default data type for Items in the list is LVObject. I had hoped to be able to subclass the List class to support different native data types so client code wouldn't get cluttered up with boxing and unboxing. The ListImp class (and its future subclasses) contain the actual data structures and implementation code. The default implementation class, ListImp-Array, uses a simple array as its data structure. Subclasses could implement a buffered array, a queue, a hash, binary tree, or whatever data structure necessary to fit the specific requirements. Users select which implementation they want to use when the List collection is created. (Dependency injection FTW.) I don't think the ListImp class is terribly relevant to this discussion. (FYI, List and ListImp do not have a parent-child relationship.) I was aiming for a high degree of flexibility--I wanted users to be able to mix and match an arbitrary type-specific List subclass with an arbitrary implementation-specific ListImp subclass. You can see a few of the List method names have "(LVObject)" appended to them. That's an indicator that those methods either accept or return an Item. These methods are type-specific. Suppose I create a List-String subclass designed to handle string Items instead of LVObject Items. Obviously List-String.Insert cannot override List.Insert because it will have a different conpane. I adopted that naming convention so child classes could create a non-overriding Insert method that won't have a name collision with the parent class. ("List-String.Insert(String)" or something like that.) Does that work? Mechanically, yeah, it works. Does it gain anything? **shrug** I don't think it's a very good solution, but I guess that's what we're discussing. How would you use Must Implement to solve this problem, and are there any better solutions you can think of? (I do have a redesign plan in mind, but I'd like to see what other people come up with.) Collection-List v0.zip [Note: This code is not intended for production use. While I hope to add collections to LapDog someday, the attached project is exploratory code and is not be supported.]

I save as previous version here as LV8.6 MultiColumnwithURL.vi