JackDunaway

"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.

No. Just as Dynamic Dispatch has 'Must Override' and 'Must Call Parent', a static method could specify 'Must Implement' and 'Must Call Parent'. Note that 'Must Call Parent' has essentially the same semantics for Static and Dynamic Dispatch. Yet 'Must Implement' might be loosely analogous to a less-stringent 'Must Override'. Sorry for muddying the waters between 'Must Implement' and 'Must Call Parent' -- i see these going hand in hand in the context of, e.g., the LapDog.Messaging ctors.

Yeah; that's the motivation for shipping the parent with a unit test and a well-intended admonition. :-) For now, this seems like the best solution.

Could you push the mask down the stack from the UI layer down into the logic layer? Like, before writing to "masked sensor data" colorbox array indicator, replace masked values in a for loop? Or are there specific reasons to keep the mask at the UI layer?

Nope; nowhere near what i was originally looking for. The opposite, rather. Static methods, called by an application that statically constructs a child class. It's all very static on purpose -- no dynamic run-time decisions, because the problem domain does not call for dynamic or double dispatching or dependency injection or any other flavor of dynamic run-time ability. Taking this into the LapDog.Messaging domain: Consider a process that needs to send a string to another process; it's going to construct the message using LapDog.Messaging.v2.NativeTypes.lvlib:StringMessage.lvclass:Create StringMessage.vi. This problem domain would never require run-time selection of another ctor, whether through dynamic dispatch, double dispatch, etc. -- because the caller needs to send a string. Now, taking a look at all of the message ctors in LapDog.Messaging.v2.NativeTypes.lvlib, they all call RenameMessage.vi. -- yet I would suggest it's better if they called Message.lvclass:Create Message.vi, their "prototype", the ctor that exists in the parent -- bear with me; this is not a criticism, it's what I see as a great candidate for "Must Implement": For a moment, consider the calling of this particular function essential to the construction of a Message object for it to be viable within the framework. Further, even though this is just one function, consider it representative of "the collection of all the essential functions" that must be called in the construction of a Message object. (One very real upgrade we might want to perform in this case is timestamping the message, and we would not want to go into each of the concrete implementations to ensure they call Apply Timestamp.vi) What I'm suggesting is that each of the concrete Message ctors calls Message.lvclass:Create Message.vi instead of calling Message.lvclass:RenameMessage.vi. With this strategy, we allow the parent to templatize the sequence of essential constructor functions. If Message.lvclass were able to specify 'Must Implement' and 'Must Call Parent Implementation', we formalize the definition of Create StringMessage.vi as implementing -- which is discretely different but having traits in common with overriding -- the functionality of the parent class method Create Message.vi. Further, we guarantee the parent method called in order to perform the essential tasks that construct a well-formed message object. And we get the unique ConPanes we desire in the concrete implementing method. I've mentioned previously (post #13), and AQ brought up again (post #132: It may not be proper to even specify the function name (i.e. one might have "Write Boolean.vi" and another have "Write Double.vi")), that this "Must Implement" feature is gated by an inheritance relationship defined through a GUID private to the class rather than filenaming conventions of the method; this is evidenced with the desire for StringMessage.lvclass:Create StringMessage.vi to implement Message.lvclass:Create Message.vi yet not have its same filename. With these features and contracts in place, if a developer decides to subclass LapDog.Messaging.v2.lvlib:Message.lvclass by creating myArbitraryStructureMessage.lvclass, we can be guaranteed that it both implements and calls the parent implementation of the essential ctor Message.lvclass:Create Message.vi, yet is able to give it any name deemed fit with any conpane necessary to construct the specific object. The prime motivation here is inverting inversion of control; would one call this taking control? It's an exercise acknowledging that statically composed applications, when the problem domain allows, is superior to dynamically composed systems, in terms of ease of development and troubleshooting and maintenance. I think it would be handy to have language features such as 'Must Implement' that acknowledge the merits of subclassing without necessarily leveraging dynamic run-time abilities. Thoughts?

Gotcha. Yeah, that's a potential code smell -- stringly-typed rather than strongly-typed prototypes. Now, your ctors and methods are subject to run-time errors.

Will you elaborate?