Leaderboard

So this code is not polished at all, but it was something I did as a fun pet project and realize I won't be able to finish it any time soon. It is a ribbon interface done in a way that could be scaled up. Ribbon like UIs have been done in LabVIEW here. But these UI's relied on button controls, to be configured and made a specific way, and if you needed to update tabs, buttons, or groups, it had to be done manually. So I wanted to come up with a way to make a ribbon like UI, but all that was required, was to provide the tabs, groups, and buttons, and the UI would be drawn. The end goal was to make an XControl with value change events when the user presses one of the buttons, but for now this is just a demonstration of what is possible. The idea was the XControl would also be smart enough to only redraw the parts of the image that were changed. Like if I changed the top tab background color it wouldn't have to redraw all the bottom parts of the UI. Here is a video demonstration. Here I show the default settings, then change some of the color and text settings. http://screencast.com/t/daan9D78vqV Some of the challenges that you don't really think about, that the API needs to be able to handle, is the text being of an unknown length, and number of rows. Things like the top tabs needed to be able to expand right, or down as needed, and all other tabs, and images needed to shift to compensate. Same thing when it comes to the button and group text. Here you also have the added complications with the fact that the text might fit in the space already needed, like if the button is wider than the text. Images are scaled using .NET and the GDI resize. This is also where images are combined, since some may have alpha layers, much like the included images do. I knew image scaling might take a while, and wouldn't be the type of thing I would want to redraw as a mouse moved over a button. So for that reason I draw all the button states on startup, and then just combine the appropriate images for when the mouse is over, or down on a group, button, or tab. This means a pretty fast response on the UI but means more memory is needed to hold all the button states in memory. Doing the gradients efficiently for me meant doing them natively in LabVIEW. I found some .NET code that would do it, but much slower than LabVIEW just drawing horizontal lines, and using math to determine the next color of the line. Several times images or parts of images needed to be shifted and translated. Instead of converting a picture back into image data, then performing the move, then converting back, I used the code posted by Norm here. It needed to be updated for a few opcodes but for the most part is fantastic and made the image processing quicker. Other than mashing this into an XControl, I also didn't get around to creating a way to disable or disable and grey out buttons. This would take more image manipulation magic and possibly more images to hold in memory. Since disabled buttons are probably going to be somewhat rare, I thought I might draw these on-the-fly instead of on init like all the other button states. Anyway I hope someone finds something in this helpful, because I doubt I'll be able to do anything with it for a while. Back saved to 2013, and remember this is very unfinished code, be gentle. EDIT: Attachment removed, re-uploaded with example images below.

Happy New Year to you too! I did a quick check on my machine. Was able to reproduce the problem running LV2015 32-bit on Win10x64. I created a folder called ABCD in 'C:\WIndows\System32'. A Google search led to the following link in MSDN. Do read the embedded link within the first response about file system redirector. That throws more light. I created another folder ABCD, this time within 'C:\Windows\SysWOW64'; and created an empty file there. Re-running my LV sample, which is still coded for 'C:\Windows\System32\ABCD' is now successful; and the empty file does get listed with the List Folder function call! Bottomline: 32-bit apps on Win64 will be redirected to 'C:\Windows\SysWOW64'. Hope this helps. Cheers!

I promise I haven't been working on this for over a year. I just got some new information from someone, on ways to get around the licensing limitation using native LabVIEW code. I believe I have a proper modern XNode Editor, that will create an XNode, or open an existing one, then allow you to add new abilities. These abilities are enumerated from LabVIEW, and if new ones are added, the list should show them. This means it is not version dependent, and shouldn't need updating, just to add new abilities. It also has a way to change the version, XNode library icon, and description just like the XNode Manager mentioned before. I haven't fully tested it, but it appears to do what it should. I back saved it to 2012 but I don't have 2012 to test with. New XNode Editor 2012.zip

Attached is a beta version of the latest 1.6 version of SQLite Library, for anyone who like to give feedback. A major addition (not yet well tested) is “Attributesâ€, modeled on Variant Attributes or Waveform Attributes, but stored in any SQLite db file. The idea is to make it easy to store simple named parameters without much effort. See the example “SQLite Attributes.viâ€. A more minor upgrade is making “Execute SQL†polymorphic, so as to return data in a number of forms in addition to a 2D-array of strings. See the upgraded example “SQLite Example 1 — Create Table.vi†which uses the new polymorphic VI, including showing how to return results as a Cluster. For Attributes, I had to make some choices in how to store the various LabVIEW types in SQLite’s limited number of types. The format I decided on is: 1) all simple types that already have a defined mapping (i.e. a “Bind†property node) are stored as defined (so strings and paths are Text, DBLs and Singles are Float, integers (except U64) are Integers. 2) Timestamps are ISO-8601 Text (the most standardized format of the four possibilities) 3) Enums are stored as the item text as Text, rather than the integer value. This seems the most robust against changes in the enum definition. 4) LVOOP objects are stored flattened in a Blob. 5) any other LV type is, contained in a Variant, flattened and stored in a Blob. Using a flattened Variant means we store the type information and LabVIEW version. drjdpowell_lib_sqlite_labview-1.6.0.51.vip LabVIEW 2011-2015 The Attribute stuff grew out of a project where SQLite files held the data, one for each “Runâ€, and the Runs had lots of small bits of information that needed to be stored in addition to the bulk of the data. When and where the measurement was taken, what the equipment setup was, who the Operator was, etc. I purpose-made a name-value look-up table for this, but realized that such a table could be made into reusable “attributesâ€.

Oh so sorry I missed that, tiny light green wire is hard to see on white background.

The second option. PS> I’m a bit stuck on this at the moment because of a problem with “Variant to Data†being too “dumb†when it comes to child classes. If one has a Variant containing a Parent-class datatype holding a child-class object, and you attempt to use "Variant to Data" to cast this to a Child-class wire, it throws a type mismatch error, even though such a conversion is easily possible. This is a problem when the library-user want to use clusters containing their own child classes. There are a couple of work around but both are ugly.

Absolutely right, however you can disable that behavior for a calling thread. To do so just call Wow64DisableWow64FSRedirection and Wow64RevertWow64FsRedirection when you are done. Make sure to call both methods in the same thread (I have used the UI thread in the past)! In between those calls you can access the System32 directory normally. Very important: All calls to the System32 directory must be executed in the same thread as the DLL calls! EDIT: You might be interested in reading this explanation to the File System Redirector: File System Redirector

Note: I’m thinking of putting in an abstract parent class with “To JSON†and “From JSON†methods, but I’m not going to specify how exactly objects will be serialized. So Charles can override with his implementation (without modifying JSON.lvlib) without restricting others from creating classes than can be generated from different JSON schema. I could imagine use cases where one is generating objects from JSON that is created by a non-LabVIEW program that one cannot modify, for example. Or one just wants a different format; here’s a list of objects from one of my projects: [ ["SwitchRouteGroup",{"Connect":"COMMS1"}], ["DI Test",{"IO":"IO_ID_COMMS_1_PRESENT","ON=0":false,"Value":true}], ["Set DO",{"IO":"IO_ID_COMMS_1_EN","ON=0":true,"Readable?":true,"Value":false}], ["Wait Step",{"ms":2000}], ["DMM Read Voltage",{"High":2,"Low":-2}], ["Set DO",{"IO":"IO_ID_COMMS_1_EN","ON=0":true,"Readable?":true,"Value":true}], ["Wait Step",{"ms":500}], ["DMM Read Voltage",{"High":13,"Low":11}], ["AI Test",{"High":3600,"IO":"IO_ID_COMMS_1_V_SENSE","Low":3400}], ["SwitchRouteGroup",{"Disconnect":"COMMS1"}] ]

The easiest way by far is to use the [un]Flatten to XML primitives, which can take objects and variants as arguments, and convert the XML to/from JSON. with simple regex/search/replace. Why they didn't make the native JSON ones like the XML is beyond me

Hey that's pretty neat. It remind me of one of my favorite XControls the Variant Probe, where a variant can be displayed in a colored tree.