bjustice

I ended up copying VIPM verbatim:

• Use /\ and \/
• Make the active column BOLD

I agree that overlaid buttons are better and feasible, but would take alot of work to get correct with things like column resizing.

The VIPM solution is low effort, robust, and not thaaat bad looking.

Argh, you're right, there is a limitation.

It looks text properties (size, color, style, fontname) are global for each individual cell.  i.e. I can't have a cell with both Segoe UI font and then also some text using Symbol font in the same cell.  This means if I put Symbol arrows in a header cell, then I can't place descriptive text next to the arrow.

Oh, really?

Ok, I'll give this a try and report back any issues.

If it doesn't work, I'll just go with your /\ idea, I didn't think of that

Works!

OOooo, I think I might have a solution.

The font package "Symbols" has a bunch of symbols and arrows in it:

This font package ships with Win 10, which is the only OS this product needs to run on right now, so that should work

In many modern non-LabVIEW UIs, tables can be sorted by clicking on the header.  There is then usually a glyph to communicate this feature.  Non-LabVIEW example:

I'm trying to reproduce this behavior in LabVIEW, but I keep hitting roadblocks.  Notably:

• LabVIEW doesn't allow for symbols in table headers
• LabVIEW ascii table doesn't have any up or down arrows.  There is an up carrot ^, but not a down carrot.

I'd love to know if anyone has any suggestions or workarounds.

@jdpowell @LogMAN @Antoine Chalons @Aristos Queue

I recommend that you guys take a peak at this code.  We're not normally able to release code like this to the community, but I managed to collect approval for this particular library on grounds that it was very low level and very intertwined with other open-source community code.  (literally recursively entwined with JSONtext lol.)

A few notes:

___

This library leverages the new "LVClass Serializer" input to JSONtext:

Soo, thanks at JDP for adding this input.  Very helpful.

__

Antoine, the TOML serializer here is not yet directly consuming your LV-TOML library.  I would realllly love to make this happen though.

In order to consume LV-TOML, we'll need to add a "LVClass Serializer" input to LV-TOML in exactly the same manner as JDP added this to JSONtext.

For the moment, the TOML code in this library is a branch of the old Erdos Miller TOML library... except that I've added the code required to hook into class deserialization stuff.

__

Logman, I took a look at your recently published "JSONtext Object Serialization" library

https://www.vipm.io/package/pnr_lib_jsontext_object_serialization/

Very cool code!  Your LabVIEW composition library has been quite useful.  In fact, it's a dependency to this library!

So, a big different between your library and this Blue library is that we chose not to use composition for serializing/deserializing classes.  We had a few reasons for this, and it's actually described in more detail on the repo readme.

However, this Blue library ships with a very nifty "BlueVariantView" package.  This exports any LabVIEW data structure to a colorized tree control.  (I was inspired by the LAVA VariantProbe library, so I made my own... but better.)  I used your composition library within this tool to decompose maps, sets, and classes.  Take a look, super cool!

__

Lastly, Aristos, I'll just cryptically say that your an inspiration, and I hope this code benefits you

LAVA friends,

Do you like JSONtext?  Do you like LV-TOML?

But do you always wish that either of these libraries supported LabVIEW classes?

Well, with this library, now they do!

The more in-depth documentation can be found at the official source code repo:

https://github.com/justiceb/BlueSerialization

The VIP packages can either be downloaded here, or directly from VIPM.

On a related note, if you like the code, consider checking out the following link:

I don't understand this website.  They are pushing this whole "chat with other attendees", but there are no chatrooms?  You have to search for someone by name?

4 hours ago, hooovahh said:

Oh wow never heard of this thing, and now that I'm looking at it, it sure seems like trying to solve a problem that has already been solved with state machine templates or State Diagram Toolkit, with an RT or FPGA.

My understanding is that the functional safety editor, paired with the yellow c-series safety modules yield a SIL-3 (safety integrity level) certified hardware/software solution.  This SIL level is often a requirement for situations that could put humans at risk of harm.  Neither the LabVIEW nor NXG environments would be able to carry this rating, so they stripped out a slim version of NXG and pushed it through a bunch of verification to obtain the safety rating.

I played around with it, and it was pretty neat.  I wouldn't regard it as anything more than a smart/configurable relay capable of fitting into a c-series slot and sending data back to the controller via the backplane.

The Voyager probes are truly amazing.

The "Pale Blue Dot", captured by Voyager 1, is perhaps the coolest picture ever taken.  Some cool facts on this from NASA:

https://solarsystem.nasa.gov/news/1175/10-things-you-might-not-know-about-voyagers-famous-pale-blue-dot-photo/

Thanks LogMAN, great library

Correct.

Ahh, I typically only read the files.  But yeah, the writer portion of the code doesn't in-place edit a file, so yeah, the comments would be lost.  Good point.  I'm not sure of the way around this.

How is JDP handling this?  I assume that he's going to have the same issue with JSONtext (since he added comments in the latest JSONtext release)

I've found that comments in the original LV-TOML library seem to work pretty well.

That issue ticket that you linked has been the only bug related to comments that I've found

Does anyone know if it's possible to compose/decompose map/sets in LabVIEW?

@LogMAN wrote a fantastic "LabVIEW Composition" library which is able to :

• compose/decompose LabVIEW classes
• decompose maps
• decompose sets

However, there is no support for composition of maps/sets.
(Link: https://github.com/LogMANOriginal/LabVIEW-Composition)

@jdpowell and @Antoine Chalons had an interesting discussion on a JSONtext issue ticket about this subject:

(link: https://bitbucket.org/drjdpowell/jsontext/issues/74/add-support-for-maps-set)

However, it doesn't look like there has been resolution yet?

Thanks for any input/insight

in "TOML to LabVIEW.vi"

Here are the mods that I made.
Those cyan VIs are from the JDP utility VIPM package that ships with JSONtext

Now is the time to do it, TOML just released a v1.0 spec.
I, for one, would buy you a beer at NI week

Yep!  TOML is like INI file syntax learning how to do everything that JSON can do... with comments.  I'm a fan.

I've also been using the Erdosmiller library.  I've found a few bugs, it's not full-feature, and it's not TOML 1.0 compliant. (TOML just 1.0'd recently).  It's the best I've found thus far though, and it's been working well enough for me.

Correct, they don't sell licenses anymore.

Just trying to be helpful and provide another datapoint.  I'm in the same boat at the moment - looking for a good Python/LabVIEW integration solution, but there doesn't seem to be anything that has been able to eclipse the capabilities of the Enthought toolkit.

I've been a big advocate for the Enthought Python integration toolkit in the past.  Unfortunately, the product was discontinued when LabVIEW introduced the native python node.
I'm still scraping by on this product as I've not found a good alternative, and the built-in LabVIEW python node doesn't meet my needs.
Under the hood, the Enthought product was just a TCP link to Enthought's flavor of python called Canopy... which has also been discontinued. 
This product was fantastic for a few reasons:

• Canopy environment could be packaged into a lightweight Python runtime engine, which can be zipped up and passed around with LabVIEW executables.  Made it easy to deploy the code to many machines.
• 32/64 bit LabVIEW compatible
• fast read/write of large data to/from Python

Relevant link:
https://support.enthought.com/hc/en-us/articles/360035630192-Toolkit-End-of-Life-Porting-to-LabVIEW-s-native-Python-support

I recognize that this probably isn't helpful... but a datapoint

Ahh, I did not realize that they were located there.  Thanks!

Thanks, great thread!

Does anyone know how I might be able to get ahold of, or export all of these cool symbols as BMP files?
It looks like all of the extended symbols in the special MCL are stored as "built-in symbols" for the MCL.  As such, I can't seem to export them using the method:
Custom Item Symbols:Get Symbol.  (This method returns an empty data array.)

Kudos, this is very cool

2 minutes ago, LogMAN said:

This was meant as a proof of concept to see if it can be done and if it's something worth investigating. I should probably mention that this branch has a few bugs that I haven't fixed yet.

Certainly not something I would use in production right now but still, I believe there is some value in this - especially for general-purpose libraries like JSONtext. Anyway, I'll back save and upload when I have access to LV. By the way, the details are explained on the Wiki: LabVIEW Object - LabVIEW Wiki

I haven't found a better way to do this without adding (or scripting) methods to every class. The only function that currently breaks encapsulation natively is Flatten To XML, which has its own limitations.

Ha!  I now feel silly for responding to your first post with a link back to your own JSONtext branch.

Did you encapsulate your object (de)composition into a reuse library of sorts?  Or is it pretty entangled in your JSONtext branch?
I read through your code and did indeed find that wiki page.  Very cool stuff.
There are certainly large benefits to doing it the way that you did things in your JSONtext branch.  You don't have to inherit from a base class, so all classes become inherently serializable.  And there is no need for scripting or creation of data member accessors to allow for the library to do its job.

Yeah, we noticed some pretty big limitations to the "Flatten to XML" primitive as well.  This tends to leave out fields in the output XML if they are default value in the object.