Issue Tracker Incident #10505


Incident Category
Incident Number

Product Version
Fixed In Version

Add Spell Check to Text Entry Fields


It would be useful to have a inbuilt spell check on text entry widgets

CRM Account
Corac Group, plc

02-16-17 14:55


03/04/11 08:25mfgadmin

It would be useful to have a inbuilt spell check on text entry widgets

12/01/10 13:22mmcbride

Verified fixed in 360rc after adding English files to applications folder. Marking "test in final" to test if this works without manually entering files.

12/01/10 11:43svn

Revision: 10810
Author: techdoc
Date: 2010-12-01 16:43:34 +0000 (Wed, 01 Dec 2010)

Log Message:
docs for issue #10505, issue #12482, and other misc tweaks

Modified Paths:

09/20/10 14:06svn

Revision: 10208
Author: cryan
Date: 2010-09-20 18:05:54 +0000 (Mon, 20 Sep 2010)

Log Message:
Fixed a bug causing crash when loading plugin in designer. Issue #10505.

Modified Paths:

09/20/10 11:48svn

Revision: 10202
Author: cryan
Date: 2010-09-20 15:48:34 +0000 (Mon, 20 Sep 2010)

Log Message:
Fixed some warnings and added spellcheck to comments. Issue #10505.

Modified Paths:

09/20/10 09:10svn

Revision: 10198
Author: cryan
Date: 2010-09-20 13:09:48 +0000 (Mon, 20 Sep 2010)

Log Message:
Incorporated changes from user jstandring to add spellcheck functionality. Issue #10505.

Modified Paths:

Added Paths:

06/27/10 08:15jstandring

Attached is a new version of the modification as "".

A number of minor bugs have been fixed and a new feature added which allows the user to add to there own custom dictionary from the right click menu. In theory this should work with other languages but It has not been tested. Most forums and the qt site seem to suggest that using .local8Bit() and a codec to convert to unicode for qt is all that''s needed.

However there are a few hard coded directories and extensions for the dictionaries, which may cause issues. They have been enclosed in tr() methods to allow them to be translated.

The user dictionary get copied to homepath() + "/xtuple/user.dic" when xtuple is closed in a effort to prevent users loosing there stored words on upgrade of xtuple.

06/21/10 07:24jstandring

Thanks John.

I think I have a way of adding a user dictionary now, so I will have a look into it.



06/21/10 07:20jrogelstad


This is really something. Thanks for doing R&D on this. I think it''s something that we''ll definitely want to get into the core. 3.5.1 is on the table to go out this week and we''re just starting on the next big development cycle push. We may not be totally responsive on this topic for a while as we work through the list of things we want to get done, but I''m pretty sure at some put we''re going to get where we can pick this up and run and you''ll see a lot of activity. In the mean time if you want to continue refining the concept please keep at it. This is great stuff.



06/16/10 11:06jstandring

Thanks cryan. That''s good news.

06/16/10 10:57cryan

I just tested the latest changes on linux and everything appears to be working as intended. Very excellent!

06/16/10 04:07jstandring

With attached file I am quietly confident it will work on linux. I have tested the functionality on windows XP, the highlighter now works first time every time. This implementation is a very simple online spell check which highlights words not in the main dictionary. As it stands the user can ignore words whilst a client is open but if you wish to have a custom dictionary to add words to more work is required.

If a custom dictionary is added to each user machine it may need to be in a place where it does not get deleted on upgrade.

Apologies for the earlier poor submissions, but this was a bit of a learning project for me.

06/14/10 14:57cryan

I do see the highlighter work on windows after I open the item window a second time.

06/14/10 13:36jstandring

Thanks for giving it a try I will have a look into it and get a linux vm setup to test it with. Did you see the same thing on windows?

06/14/10 13:16cryan

With the latest code I am not seeing any crashing but on Linux I do not see the highlighter work at all.

06/14/10 12:16jstandring

I have added the line to the XTextEdit with my latest code version attached as "". This one was working when compiled.

The right click and highlighter were working. For some reason the highlighter would only work after opening an item screen of the same or a different item the second time. After which it would continue to work on all item screens. With any luck your entry suggestion will fix this. I tried adding rehighlight() call but without success. The base QSyntaxhighlighter class decides by itself when it updates the screen, so I am not sure how force it to update.

Are you intending to work on this code, or would you prefer to see it moved into the widget dll? The interface is now all set to "const" and seems to work stably .

Note there were some crashes caused by the way populated the right click menu that have now been fixed.

Thinking back I decided that the guiclient would be a good place for hunspell because an instance can be created easily when entering running the client. We also need to destroy the instance on leaving the client to save the added words. Do you think this is as easily to do in the widgets dll? Is there some kind of global constructor/ed-constructor for the dll, which get run at the write time.

06/14/10 12:00cryan

Adding the following line to your XTextEdit constructor will fix your crash problem.

_highlighter = 0;

06/14/10 10:04jstandring

Hi John. Your right Hunspell it could go in with the widgets.

I guess because I was having difficulty with the getting debug information and I over looked it. I have been using the scripting to test hunspell.

The QLineEdit seems to be a restrictive in terms of highlighting and I couldn''t get it to work with the QSyntaxHigherlighter Object. So as a result I have just removed this code.

06/14/10 09:22jrogelstad

We''ve been looking at this. Wasn''t able to get anything working with previous commit, but maybe with this one we''ll see something.

We were wondering why the hunspell functions need to reside in the guiclient at all. Wouldn''t it be simpler just to make a hunspell class in widgets? Then you can avoid all the complexity and indirection with the interface. That class could probably also be written in a way so that xlineedit and xtextedit could share a lot more of the code.

06/14/10 08:00jstandring

Still Not able to upload medications, so as the changes are minor from the they are listed below.

after line 548 insert
XTextEditHighlighter::_guiClientInterface = VirtualClusterLineEdit::_guiClientInterface;

remove comment marks form line 61 and replace with
_highlighter = new XTextEditHighlighter(this);

06/14/10 02:11jstandring

Finally got there with this one. Form the last comment forgot to add a connection to the guiclientinterface for the higher lighter class.

The attached code "" v5 is stable and has both highlighting and rightclick menus working. The highlighing starts working on the second instance on an item though not sure why.

Can not figure out how to get the xtuplewidgets.dll from the updated code I have. This would help as only the item screen has a hard coded spellenable setting in the .cpp file. Other screens will need this in the ui file.

***Have trouble uploading the file will try later***

06/13/10 17:38jstandring

Had another play with this today and managed to sort out the guiclientinterface so that it does not crash. However I am now getting crashes when the qsyntaxhighligher class has an instance created and used.

In the attached "" I have disabled the highlighter on line 61. The crash seems to occur on line 172 when it is enabled. Any thoughts on why would be great?

With the highligher disabled right clicking on a incorrect words gives a list ta the bottom of the context menu and a Add Word menu item.

It looks as if the QSyntaxHighlighter is only usable with QTextEdit so I have remove the code on the XLineEdit.

Some how the highlighter worked before but now it crashes every second open of the item screen after compile.

06/11/10 12:06jstandring

For the spell check to be enabled the following must be true

1. Dictionary files English.aff and English.dic are in the App Dir (Which you have)
2. Preference check box set in user perferences (which you have)
3. SpellEnable Property set in each widget which at the moment is in the constructor for item.cpp
4. Widget is enabled
5. Widget is not read only.

The crash occurs when right clicking on the widget so the the context menu is shown. The higherlighter was working before when I have the methods defined as "const" but only after the first run or the application. This may be to do with the guiinterfaceinterface.

I am trying to compile at the moment with the method changed to

const int hunspell_suggest(QStringList & slst, const QString word);

This returns the size of the QStringList and I think a reference to the QStringList in passed back?.

I have also down graded for Hunspell 1.2.11 to 1.2.9 in the code sent because there were some forum mentions of it crashing with KDE office.

06/11/10 11:43cryan

I was able to compile the changes after a small fix. I however am not seeing the functionality working. I enabled the spell features in preferences and it gave me the message to download the English.aff and English.dic files. I found and downloaded them into the correct location according the messages. Restarted for good measure and went to the item screen. I tried entering text into the Descrip 1, 2 and notes fields mspeeling awlsowts o stoof but didn''t see the spell checking functionality at work. Do I need to do something that I have missed?

06/10/10 17:29jstandring

Getting Close to Finishing this modification just stuck on passing a QStringList via the GUIClientInterface. I get an memory error when I try to run the

QStringlist Hunspell_suggest(const QString)

Method. I originally had a

const Qstringlist Hunspell_suggest(const QString)

Method, which ran the first time after compile and the spell check work well on the XTextEdit. Then the second run the application would crash on with a memory reference error. So I changed this method to removing "const" thinking this would solve the problem.

Now I am out of ideas any suggestion would be appreciated.

The attached "Hunspell_Mod" is based on 351RC.

05/28/10 16:52jrogelstad

For an exmple of how to use the GUIClient interface class look at the documents.h, documents.cpp and guiclient.cpp files. The interface is used there so the documents widget can open windows from the client. It''s also used to implement a new file watcher function for embedded files.

05/28/10 16:10cryan

You are trying to include and reference the GUIClient class in the widgets directory which you can not do directly. You have to use or set up something similar the XTupleGUIClientInterface which abstracts the functionality you need and then that interface is expanded to do the actual work in the guiclient folder and the widgets initialized with the appropriate values.

I noticed too that the code you are using is not the most recent. This made it difficult for me to diff and test the changes without pulling it all apart. I would suggest that you update your code to the latest, at least prior to submitting any work, to make it easier for us to use it.

05/28/10 14:24jstandring

I have added the following include to XTextEdit.h as I need to call the spell check methods from with the guiclient.cpp.

#include "../guiclient/guiclient.h"

I am using the "omfgThis->" to call hunspell methods from within XTextEdit.cpp but on compile I get errors such as below. Any Ideas where I am going wrong. sample code Attached.

c:/qt/2010.02.1/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: :0: syntax error
./tmp\dll\xtextedit.o:xtextedit.cpp::-1: error: undefined reference to `omfgThis''
./tmp\dll\xtextedit.o:xtextedit.cpp::-1: error: undefined reference to `GUIClient::hunspell_get_dic_encoding()''

05/26/10 08:32jrogelstad

There should be no need to store anything new in the locale. The current locale table joined with the lang and country tables should be sufficient to find the right dictionary.

The idea of using one instance of hunspell is great. Could we not set spell check as a global user preference that is set to "On" by default?

Use of "this->" is optional. We simply choose not to qualify local functions and variable this way in our coding style. If you''re getting stuck on something, maybe providing a more specific example would help.

05/23/10 11:48jstandring

I have managed to get a little bit of this done integrating the hunspell libary. I just wanted to run how I intend to implement spell checking by someone because my experience of virtual classes and integrating library''s is limited. I intend to use hunspell as suggested, because there are some reasonable examples out there of how to use the library.

1. Include hunspell library into guiclient.cpp and guiclient.h with methods which access the library methods in hunspell.h.

2. On logging into the client a setting stored in the locale will determine which dictionary hunspell will be initialised with. If that dictionary is missing then spell checking will be disabled. Spell checking will only run if the widget instance is visible and enabled.

3. Only one instance of hunspell will be created within the client which will be used by all xTextEdit and XLineEdit with spell check enabled.

4. all XTextEdit and XLineEdit spell check will be disabled as default. To enable them the user can right-click and click on enable spell check and right click again and click "disable spell check. Settings will be store for each instance of XTextEdit and XLineEdit.

5. On exiting the client all words added or ignored will be committed to the directory.

I am a little stuck with virtual XTextEdit as the examples I am working too have lots uses of the "this" keyword. Any tips on how change code form a standard class to work with a virtual class.

05/14/10 08:29jrogelstad

I wouldn''t load this stuff into tables. That would require building something from scratch. As I mentioned before I''d find a library to accomplish this. It''s been done so many times before it would be crazy to write and maintain another spell checker. The big pre-requisite is that the spell checker library would have to be written in C++, open source LGPL , and work on all operating systems. The hunspell one on my first note seemed promising, but I''m sure there are other choices. We generally don''t like to include libraries outside of Qt, but I think we''d make an exception in this case because Qt doesn''t have an answer and this would be a very powerful and useful addition to the application.

Might look at what KDE does to solve this problem in KOffice and other apps. KDE is written in Qt, so they''ve already solved it one way or another. I doubt they built their own spellchecker. I bet they are using one off the shelf too. Hopefully whatever they are using is LGPL. (KDE itself is GPL, so if the spellcheck is also GPL, it won''t work for us.)

Adding this into XLineEdit and xTextEdit with a signal/slot mechanism makes sense to me. Probably need a property to turn it on and off with default to off.

05/14/10 04:55jstandring

My initial thoughts are a follows

1. I am torn between Having the ability to load the dictionaries into database tables, update them and link them to locales or simply have the dictionaries stored with the application locally.

2. Add new methods within connected to slot xLineEdit xTextEdit connected to slots which check individual words as you type or the complete document when requested.

I think this is likely to be quite a bit of work which needs a bit more investigation. Do you have any thoughts ideas on the implementation?

05/13/10 16:53jrogelstad

Wow. That''s great you''re taking this on. Could you give us some insight on how you plan on implementing it?

01/27/10 02:43jstandring

I think on this basis having some option settings would be a good idea. We were interested mainly in the fields which end up on purchase orders and other similar documents. As these are sent out to suppliers and customers.

01/26/10 21:24lcartee

It might be nice in some places but I believe the item description fields, and any fields with proper names such as customer name, supplier name, user name, employee name, contact name, etc should be excluded as I believe it would be of little value.

The proper name exclusion should be obvious and with all the industry specific abbreviations and and acronyms users put in inventory descriptions it wouldn''t make much sense to spell check them.

Even in various note and comment fields abbreviations and cryptic notes probably makes spell check of dubious value.

01/26/10 15:30jrogelstad

That would be really cool. I don''t know of any Qt support for spellchecking. We''d have to find a C++ spellcheck library to tie into our Qt framework. It would have to be open source LGPL. This one might work:



Related Documents

Incident5144Alpha3 - Tax Detail - Amount Field NarrowRelated to
Incident5147Screens lose focus after Item # enteredRelated to
Incident5159S/O - Freight Tax - Tax Detail - Amount Entry Allowed - Correct?Related to
Incident5167Quote Line - Create Order Reset to False on EditRelated to
Incident5169CRM- Create Prospect - Tax Auth Does Not SaveRelated to
Incident5177Some forum topics missingRelated to
Incident5198double "Issue Items Using Bar Code"Related to
ProjectXTUPLEAPPSPorted From Mantis


You do not have permission to view subscribers.

Incident History

01/30/17 14:25adminFound In: -> 3.4.0
01/30/17 14:25adminFixed In: -> 3.6.0Beta2
02/16/17 14:44adminCharacteristic Patch Added: "Y"
02/16/17 14:55adminSeveritySeverity Changed: Patch -> Normal