HTML Control

[DFGray]

I would like a control/indicator which supports HTML formatting for display and documentation.  There have been a couple of previous similar requests, here and here, but nothing specific to HTML (although jlocanis has been consistent in his comments on these previous requests asking for HTML formatting).

I would envision a control where you enter HTML and can change the display from the HTML to the rendered text easily, similar to the multiple modes available on current text controls.

Why HTML and not just more formatting options?

1. Why reinvent the wheel.  HTML has been around for decades and works well.
2. You can mix fonts, localizations, superscript/subscript, symbols, etc. within HTML, allowing much more flexibility when documenting front panels.
3. HTML is platform agnostic

As has been said in other requests, extending HTML support to captions, labels, etc. would also be nice, but secondary.

[Darin.K]

Not that anybody around here is uptight about capitalization, it is actually LaTeX.    For modern applications, an XML compliant alternative (MathML) is probably preferable.

Before long it will be easier to get LV into your browser than get a browser into LV. 

The more I think about it, I would settle for better Unicode support (covers most of the symbols, especially with the right fonts installed), and a less-painful way of applying and retrieving formatting than the Sel.Start Selection.End gymnastics we have now.

[Underflow]

Just to see how it would work, I wrote a couple of proof of concept markup vi's.  They're over at LAVA at http://lavag.org/topic/14700-lvmark-format-markup-for-string-controls/.

I prefer the markup format (like Markdown, where possible).  It's easier to write in-line formatting, without some of the oddities of HTML, and the insanities that occasionally creep into XML.

Of course, better Unicode display support is a must for the symbols.

[TCPlomp]

I'm with Aristor on this one.

It would require immense strength, and it just would not be good.

The page wouldn't be like 'IE' or 'Chrome' or 'Opera' or 'Firefox'

It wouldn't be HTML 5 complient. It wouldn't support CSS etc. etc. etc.

[MGiacomet]

I *HATE* when AristosQueue (an NI person) plainly overrides a customer's request like this...

The original poster is just asking for simple formatting using HTML (not reiventing a full browser). In fact, NI already has some of that code it in the Documentation section of the controls/indicators, for example <b>

Kudos!

[AristosQueue (NI)]

> I *HATE* when AristosQueue (an NI person) plainly overrides a customer's request like this...

If you believe I overrode the request, I need to clarify my post then. 2011 I wasn't as explicit when I posted to the Idea Exchange in different modes.

You'll note that the idea is still open, not closed. I post sometimes as a member of LV R&D and sometimes as a LV user (I use LV extensively outside of work for my personal programming projects). In this case,  I wasn't clear about which hat I was wearing. My comments are as a user. As a user of any software, I prefer that all of my software vendors focus on what they do best and do not try to recreate an entire mini-product. I see this happen all the time: database software that suddenly decides to be a full GUI builder, or document editor that starts acquiring a full-bore image editing system. Those mini-apps are off-the-main-goal of the software and, as such, become resource sinks. More on that in a moment.

To give you a clear example of the difference between my hats: I as a user didn't think NI should be investing in a new icon editor and trying to build a full graphics system there (I would have simply worked on making the interop between LV and a third-party image editor stronger). But once it was decided that NI should take on the weight of maintaining an icon editor, I was the technical lead for making it happen and tried to make it as solid as I could.

The icon editor is a prime example of a large block of code that isn't in the core of NI's mission. It is a fairly complex bit of functionality, and it is one where endless tweaking and improving is possible: almost like it was its own product. Because it is a secondary mission, bug reports against it often get downgraded in priority. I've worked in with enough software projects both within NI and elsewhere that I've become leery of requests that are essentially new mini-applications. They either start sucking up significant developer resources to keep them polished and up-to-date with the latest real applications in their domain or they get ignored over time and degrade. The result for me as a user of the software is that either it becomes a clunky add-on or it takes away from other features that I do want added.

> The original poster is just asking for simple formatting using HTML (not reiventing a full browser). 

Except that he didn't. He asked for HTML formatting, without putting any particular limits on it. And various customers over the years have asked for a lot of HTML, including embedding movies, which is part of HTML5.

You note that we already have the <b></b> tag in the VI documentation. That's true. That's a far cry from general HTML formatting. Give me a specific list of the tags that you think should be supported and I'll contemplate it. Ask for HTML in general and I push back -- as a user, not as a member of R&D. As a member of R&D I look at it and say, "Well, if that's what customers think we should be spending our time on, and they're willing to pay more money for LV if it has this capacity, I am open to staffing the project (weighing it against all the other projects that customers ask us for, obviously)."

When we start talking about formatting panels and laying in HTML, my preferred solution would be a control that embeds a web page in the panel. The ActiveX control can do this today. Is it clunky? Yes. It would be nice to have a cleaner interface to the world. I would focus efforts there rather than try to build a control into LabVIEW that has an HTML parser and tries to replicate the functionality of HTML.

Does that all make sense?

[X.]

Allow defining Tab locations in a string control (kind of the way that works in Word, but without the graphical gizmo, just some basic tab location definition, in pixel, passed through a property node or in the Properties dialog).