JackDunaway

Not related to the VI Clone Refs per se, but while we're on the topic... Since the User Events are created by this launcher SubVI, this SubVI must remain reserved for execution (or running) for the User Event Refs to remain valid. One common misconception is to think that keeping this VI in memory is sufficient, or that once passed to the clones the User Event Refs tie their lifetimes to that of the clones. The lifetimes of these User Events are tied to the static call chain of the diagram that creates the references. This gets tricky when clones start launching clones.

+1 for a good question. Playing devil's advocate, I appreciate LVClass, LVLib, and LVProj underlying representations as XML -- source code control infrastructure (including diff/merge) generally just work way better with text formats. (It would be super slick if all LV filetypes likewise were represented as XML, or JSON, or... not binary) In terms of editing the class definition on a diagram, can you provide some examples? Sounds neat.

Greetings Friends of LAVA, colleagues, cohorts, and partners in crime! tl;dr: LAVA BBQ tickets on sale now, limited numbers on Early Bird pricing, get your tickets here: LAVA BBQ 2013 Event Page (lavag.org/bbq-tickets) LAVA BBQ 2012 in the Scholz Garten Biergarten (Photo by Norm Kirchner) It’s that time of year -- getting NIWeek approval, booking flights to AUS, and being the first to nab your LAVA BBQ ticket! For those of you who have never been to the kind of LAVA BBQ we're putting on, it's a time to get to know “the people behind the avatars” over BBQ and beers. Everything you need to know is on the LAVA BBQ 2013 Event Page, including time, a link to a map, a checkout to buy tickets today ... but we’ll violate the SSOT principle and make a data copy of the BBQ2013.lvclass object below: Date: Tuesday, 06 August 2013 Time: 7:00-10:00pm CDT (after the NIWeek Block Diagram Party. You won’t miss any NIWeek official events) Time for @LabVIEW_BORAT (and other ISO-8601-compliant robots): <EventBeginTimestamp>2013-08-07T00:00:00.000Z</EventBeginTimestamp> Location: Scholz Garten, 1607 San Jacinto Blvd, Austin, TX 78704 (1 mile from Convention Center) Cost: $30 Early Bird (until July 5th) $35 Regular Admission (Until Aug 6th) $40 At the Door Who: Everyone is welcome, including spouses travelling to Austin with you. Even if it’s your first time, expect to recognize many faces/names from the forums and NI R&D What to wear: I’ve seen everything from flip-flops to evening gowns to... leather hats. (The vast majority leans toward casual clothes suited for the 1mile 95°F 7pm walk) If you plan to sponsor a Door Prize, there is a form field with your name on it during checkout. (See existing Prizes) If you prefer a Vegetarian option, we’d love to have you; there is a form field with your name on it during checkout. Hope to see you there! Chime in on this thread (and the comments section of the Event Page) once you buy tickets.

"Seriously.js is a real-time, node-based video compositor for the web" (from the readme on the GitHub repo), and might be of general interest to those into Machine Vision, Imaging, and especially OK GO. How to work this demo: 1) play the video, 2) toggle processing styles with buttons on the bottom of the video, 3) be amazed: http://seriouslyjs.org/ (Lyrics are colorful, perhaps not appropriate for blaring aloud at work or with your impressionable little ones -- turn the volume low, and the video is quite fun for the kids!) Raw video still, filmed in front of a green screen: British Invasion filter, applied real-time with Javascript in your browser: (Sorry IE; this demo works in Chrome/Firefox)

Stay tuned -- perhaps some of these concerns are addressed in unreleased versions and a nudge is all it takes....

The only way I've been able to do this is by cheating. I would have a horizontal splitter with only the tabs in the top pane, and the contents of the tabs in the lower pane. Highest recommendations for checking out XTab by Saphir, available for download through the LabVIEW Tools Network using VIPM. * It handles resizing of tab contents no prob, since the tab contents are just a VI * You can add/remove pages programmatically * You can re-order and even pop out tabs into new windows (à la Chrome browser) * The toolkit is free Here's a screencast that shows XTab in action: http://www.dailymotion.com/video/xmtmvf_topaze-tab-navigation_tech#.Ua4DsGRgZyE More info on the community: https://decibel.ni.com/content/docs/DOC-21668

There are four ways to turns on scroll bars: 1. VI Properties (CTRL+I) >> Window Appearance >> Show vertical/horizontal scroll bar 2. Context Menu of an existing scroll bar: 3. Context Menu of a splitter between two panes: 4. And as a property node of Pane (also shown, a lesser known fact -- you can show, customize, then hide the Labels on both Splitters and Panes to be more descriptive than Pane, Pane 2, Pane 3, Pane 4...) A mistake I oftentimes make is to search for Pane settings under the Panel class -- Class Browser (CTRL+Shift+B) helps remind.

Coming from a different angle, I have some ideas on how to take some magic away from the original design:

For clarity -- and don't let me put words in your mouth! -- but for clarity i think you mean to avoid "Scale all Objects with Pane" (because, it almost never does what you want) -- and you typically *always* want to enable "Scale Objects While Resizing" because hardware is more capable today than it was in the 1900's. :-) This is typically the setting you'll want for Panes:

The whole splitter business shouldn't even be necessary -- if I understand your original request, the features you describe are native. (this demo uses LabVIEW2012 12.0.1F1 32-bit) Inspect settings on the two VIs attached (Container.vi and Containee.vi -- save them in the same directory) and check the 25sec screencast below to see if it demonstrates the behavior you're trying to achieve: http://screencast.com/t/84aalWkNw Containee.vi Container.vi

I'm currently using precisely this technique (private App method and all) for a commercial product. It has worked great in practice for end-user plugin devs. The key is approachability for plug-in developers. A "safer" but significantly less approachable alternative is to write this metadata as Tags to the VI. (I investigated and rejected using Tags for this task; it's conceptually far easier to explain Title/Description editing, and does not require custom tooling/APIs to edit data that should be readily editable by devs). Lowering barriers for plug-in development has far more value than eschewing "the dirty feeling you get from overloading the meaning of fields". Go for it.

The BD is rendered with the Web Safe color palette. Mapping from your 24-bit icon editor to this Web Safe palette appears to be based on RGB least squares rather than an HSV match; for this reason, it's probably best to attempt to design your icons starting with the Web Safe palette, because the matching for dark shades often misses the mark for Hue (as shown in your first post). This also means converting bitmaps to the Web Safe palette prior to importing into the Icon Editor, since the color matching routine of your image editor is likely to produce better results. You're in for a treat if you're into pastels, with this palette. (image search for the Web Safe palette: https://www.google.com/search?q=web+safe+palette&tbm=isch)

All the buzz i've caught on this topic the past couple months have Feedly and Newsblur as the top contenders. I've casually used Newsblur for a year or so, and would recommend it. Even if I were making this decision post-Reader-axing-announcement, would probably choose Newsblur again (just based on the guy behind it)

Everything works now, here's what I've learned: LabVIEW is using a list of trusted authorities from the file: "%ProgramFiles%National InstrumentsSharednicurlca-bundle.crt" If your Certificate Signing Authority is not in that list, you will receive Error 363507 - LabVIEW could not verify the authenticity of the server. In order to avoid this error, either find a new Certificate Signing Authority, or you can specify your own Trusted Certificate Authorities using ConfigSSL.vi (shown in the screenshot below). When you distribute your application, ensure to include this file with the distributable. When you download your certificate from your CA, through the management console you can probably also download the Root Certificate of the CA -- this is the file that you wire into CA certificate file of ConfigSSL.vi. (This file might even be included as a zipped certificate bundle when you download your cert.) This file will look like the following if opened in a text editor: -----BEGIN CERTIFICATE----- MIIFB...LinesAndLinesOfBase64....== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIED...LinesAndLinesOfBase64....== -----END CERTIFICATE-----

This post is quoted during Jeff Meisel's keynote presentation (@9:39 in the video). Jeff emphasizes the importance of NI collaborating with the community to build key API access into the LabVIEW platform, and how the efforts of community leaders have paid off in the past several years. Link to the presentation: http://www.infoq.com/presentations/National-Instruments-API

Upgrade Code, Product Code, and Package Code are three terminologies used by Microsoft Windows Installer (MSI) to identify the three dependencies your application installer is missing -- read more about what they mean here: http://blogs.msdn.com/b/pusu/archive/2009/06/10/understanding-msi.aspx (There are many explanations, this is just one good one) It sounds like you're on the right track using virtual virgin machines to test your distributable. Quick question -- if you install the distributable on your dev machine, will it run without the three errors about missing dependencies? I'm guessing the answer is yes. In this case, you can query your dev machine for those three Upgrade Codes to see if they exist as installed products in the registry. This reverse-lookup should point you to the actual name of the product needed, not just a GUID. Another option is inspection of the MSI (google "free MSI editor"). Using a tool like this, sleuthing for the three Upgrade Codes likely reveals the name of the dependent MSIs. Finally, I would recommend inverting your distribution building process. First, just build an installer with nothing but your application and the LV RTE, and install this on a staging machine. Of course it will fail, but then manually run app-specific driver installers on the staging machine, until you have finally satisfied dependencies of the application. This technique is way more agile than including dependencies into your installer to test, since you don't have to rebuild each iteration. (Full disclosure -- my company provides products and services with a laser-focus on LabVIEW application deployment)

Generally, I like what you're suggesting. I don't have a particular opinion on Variant behavior when deserializing/validating, but I strongly agree for other stringly-typed composite data structures (XML, JSON...). The reason I don't have a strong opinion about Variant behavior is we're typically talking about intra-application communication; the reason this is so important for XML/JSON is that now we're talking about interoperability beyond an application instance, where strict validation is oftentimes more of a hindrance than an asset. For those participating to the LabVIEW 2013 Beta, there's a discussion on that forum about this topic -- search for "validation on deserialization" and weigh in.

I'm drooling over this slick physics simulation of a cloth/fishnet curtain in JavaScript. You can interact with the kinematics of the canvas and tweak the source code live in your browser: http://codepen.io/stuffit/pen/KrAwx Left mouse button dragging moves the curtain; right mouse button dragging cuts through the curtain. The power and simplicity of the software engineering tech stack shown here is.... beautiful. Inspiring. (tested in Chrome and IE10; YMMV for <IE10)

To be fair, this must be qualified by "inability to use in arrays using conventional, discoverable techniques" :-)

(emphasis added above) Maybe, you're confusing Reentrancy with Dynamic Dispatch? A Dynamic Dispatch method requires class control input and output to be on the outermost diagram, and will generate the following compiler error if either is placed inside a structure: "Dynamic front panel input and output terminals cannot be placed inside structures. This ensures that they will be read from and written to exactly once so that LabVIEW can guarantee the run-time type safety of the diagram. An exception to this rule is made if the dynamic input terminal is inside a structure node and the VI has zero dynamic output terminals. In that case, the VI is not broken."

Over the past 5 years, each year, approximately: B -> C -> A -> B -> B tl;dr -- does not solve sufficiently painful problems efficiently enough. A few inconveniences that come to mind: Inability to designate an XControl as a view of an LVOOP class Inability to expose VI Server API of composed elements, other than through a naked ref getter on the XControl API, or re-implementing a wrapper Inability to override VI Server API methods/properties of composed elements Handler in Façade does not actively handle incoming User Events (just VI Server events) It feels like they were both released and EOL'd the same day (this is just perception, yet it plays a substantial role considering ROI in this technology) They're still super cool, and I would not recommend against developing an XControl. (I've developed perhaps a dozen?) It's just one of those tools in the toolbox that's not rusty, yet not often reached for.

It was an honor meeting many of you in person for the first time (including all on the thread so far, except I don't recognize the pseudonym Tyler Durden... even if I did, the first rule would be not to talk about it). Consider my calendar booked for Europe for next year, and in the meantime i hope you're able to make it out to Austin for NIWeek.