NI Days - Right Click Spell Checker

[alecjcook]

Hi,

   At NI-Days in the UK yesterday, A girl did a demo at one of the keynote speeches where she demonstrated a right click spell check. Does anyone know what this was ro how to get hold of a copy. I would really like a spell checker for LabVIEW, it would help people not to think less of me if I could find one and find out how to use it!
Many thanks, Alec

[crossrulz]

Sounds like somebody make a new Shortcut Menu Plugin.  A bunch of community made plugins were posted here, but I don't think I've seen a spell check one.

[Darren]

This is a demo from the presentation Stephen and I gave at NIWeek 2015 regarding the new right-click plugin feature in LabVIEW 2015. You can get the slides for the presentation, along with all the demos (including the spell checker), and a demo script, here:

 

http://www.ni.com/lvmenus

 

Note that the spell check right-click demo requires that you have the VI Analyzer Toolkit for LabVIEW 2015 installed, as it uses the dictionary provided by the VI Analyzer's Spell Check test.

[ShaunR]

Hmmm. Do we really not have a spell checking solution apart from VI Analyzer? (which isn't really a solution ).

[hooovahh]

Hmmm. Do we really not have a spell checking solution apart from VI Analyzer? (which isn't really a solution ).

I understand your version situation, but the VI Analyzer is now free with LabVIEW Professional 2014 or newer.

[ShaunR]

I understand your version situation, but the VI Analyzer is now free with LabVIEW Professional 2014 or newer.

 

Not a version issue. Maybe I put my surprise in a wrong thread since the only references my foul-fu could find were for VI analyzer and this was the only one I could find on Lavag.org for spell checking.

 

What I meant was "do we still not have a spell checking function we can use in LabVIEW?". Shipping VI anayzer with the application just for spell checking is a bit silly, IMO.

Edited March 10, 2016 by ShaunR

[hooovahh]

I know of no other spell checker like functionality in LabVIEW.  There are several ideas on the idea exchange for this, none seem to have much traction but this is the highest one I see.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Spell-Check/idi-p/982762

 

That being said I doubt NI would work on making a spell checker in LabVIEW, since VIA does works for finding spelling errors in source, which I believe is the most common use case.

[ShaunR]

I know of no other spell checker like functionality in LabVIEW.  There are several ideas on the idea exchange for this, none seem to have much traction but this is the highest one I see.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Spell-Check/idi-p/982762

 

That being said I doubt NI would work on making a spell checker in LabVIEW, since VIA does works for finding spelling errors in source, which I believe is the most common use case.

 

No. I want a spell checker that I can use in applications on any text - not just in the LabVIEW IDE.That's very short-sighted.

 

Time to write a wrapper for Hunspell, I suppose  

[CopperD]

I always copy and paste my vi descriptions into google and see what it thinks. This with a non-modal description editor would save a lot of time. Who would've thought that someone would like to look at the code while documenting it.

[JKSH]

No. I want a spell checker that I can use in applications on any text - not just in the LabVIEW IDE.That's very short-sighted.

 

Time to write a wrapper for Hunspell, I suppose

 

To be honest, I don't really see a spell checker fitting in with NI's core offerings, i.e. tools that enable/simplify the work of scientists and engineers. This seems more like a job for 3rd-party developers.

 

(Having said that, since VIA already has a built-in spell checker, it might make sense for NI to make VIA spell checker a standalone library, and let both LabVIEW and VIA link to it).

 

May I ask what your use-case is?

[ShaunR]

To be honest, I don't really see a spell checker fitting in with NI's core offerings, i.e. tools that enable/simplify the work of scientists and engineers. This seems more like a job for 3rd-party developers.

 

(Having said that, since VIA already has a built-in spell checker, it might make sense for NI to make VIA spell checker a standalone library, and let both LabVIEW and VIA link to it).

 

May I ask what your use-case is?

 

I have four use cases.

 

1. Add spellchecking to "Project Probe" and integrate the "VI Documenter" with auto correct.

2. Spell check readme and changelog files.

3. Create an Xcontrol (string control) with "as you type" spell checking built in.

4. Add spell checking to a report generator someone has asked me to create.

 

So far. looking good.

[hooovahh]

So sorry it took this long to realize you were talking about at run-time, my bad.  Here is an idea exchange for that.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-Spell-Check-For-String-Control-in-Run-Time/idi-p/1661466

 

And no, I can't think of any other solution.  Is there some kind of external spell check library that can be called?  Still sounds like a pain.

[ShaunR]

So sorry it took this long to realize you were talking about at run-time, my bad.  Here is an idea exchange for that.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-Spell-Check-For-String-Control-in-Run-Time/idi-p/1661466

 

And no, I can't think of any other solution.  Is there some kind of external spell check library that can be called?  Still sounds like a pain.

 

No. It's my bad. The thread is about IDE spell checking through a right click plugin so my use case is a super-set. It was just the only Lavag thread that was about spell checking.

 

There is an external spell checking library (scroll up for link). It works very well. The problem is it's LGPL.GPL or MPL (have a choice) but they all burden the distribution of binaries with source (for a couple of years).

 

So I'm umming and arring about not supplying the binaries and just supply the LabVIEW code as BSD3.Then whoever wants to can build their own binaries or find pre-built ones elsewhere . The problem there is that it will make it almost unusable for many LabVIEW people who are using 64 bit if I don't supply them..

[ShaunR]

Mission accomplished!

Edited March 13, 2016 by ShaunR

[JKSH]

Mission accomplished!

 

That was quick!

 

I thought I'd give it a test drive, but the Hunspell DLLs depend on some MinGW DLLs which aren't bundled. (I tried dropping in my own version of libgcc_s_dw2-1.dll and friends, but that crashed LabVIEW)

Edited March 14, 2016 by JKSH

[ShaunR]

That was quick!

 

I thought I'd give it a test drive, but the Hunspell DLLs depend on some MinGW DLLs which aren't bundled. (I tried dropping in my own version of libgcc_s_dw2-1.dll and friends, but that crashed LabVIEW)

 

Not really. There isn't much too it.

 

The build  environment was imported from a VC++ workspace into CodeBlocks so I'll go through it so that external dependencies aren't required - I thought that was too easy...lol.

 

In the meantime you can get a 32 bit binary from here to play with (rename it to libhunspellx32.dll) or with a bit more google-fu you can find others. They are all 32 bit, though. If there were 64 bit available, I wouldn't have bothered distributing them with the API.

[ShaunR]

That was quick!

 

I thought I'd give it a test drive, but the Hunspell DLLs depend on some MinGW DLLs which aren't bundled. (I tried dropping in my own version of libgcc_s_dw2-1.dll and friends, but that crashed LabVIEW)

1.0.1 has been released with the dependency removed. You should be good to go!

[JKSH]

1.0.1 has been released with the dependency removed. You should be good to go!

 

Yep, works great!

 

The Suggestions API returns a 2D array where the first column is the incorrect word, and the other columns are the suggestions. However, the row length depends on the entry with the highest number of suggestions. This means, if the callers want to know how many suggestions there are for a particular incorrect word, they would need to manually search for empty array elements in that row. Would it make sense for the API to return an array of clusters instead? Each cluster would have 1 string (incorrect word) and 1 1D array of strings (suggestions).

[ShaunR]

Yep, works great!

 

The Suggestions API returns a 2D array where the first column is the incorrect word, and the other columns are the suggestions. However, the row length depends on the entry with the highest number of suggestions. This means, if the callers want to know how many suggestions there are for a particular incorrect word, they would need to manually search for empty array elements in that row. Would it make sense for the API to return an array of clusters instead? Each cluster would have 1 string (incorrect word) and 1 1D array of strings (suggestions).

 

There's probably a few improvements that it could benefit from. The Hunspell library only checks individual words so the regex I used to split text may need tweaking, for example. As long as there are no show stoppers; leave it a month for people to play and make suggestions like yourself. then I'll revisit.