|
|
|
Rank: Member
Groups: Registered
Joined: 3/28/2017
Posts: 12
Location: Graz, Austria
|
Hi,
This time a remark/question to rapidspell
I ended up with the following code intializing my rapidspelldialog
rapidSpellDialog = new RapidSpellDialog
{
GUILanguage = LanguageType.GERMAN,
LanguageParser = LanguageType.GERMAN,
CheckCompoundWords = true,
UserDictionaryFile = config.PathUserDictionary,
DictFilePath = config.PathDictionary
};
rapidSpellDialog.CheckerEngine.LanguageParser = LanguageType.GERMAN;
rapidSpellDialog.CheckerEngine.CheckCompoundWords = true;
rapidSpellDialog.CheckerEngine.DictFilePath = config.PathDictionary;
rapidSpellDialog.CheckerEngine.SetUserDictionary(new UserDictionary(config.PathUserDictionary));
My question now is : Why does Checker Engine keep their seperate properties? Is there any reasoning behind that?
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
You shouldn't need these lines Code:
rapidSpellDialog.CheckerEngine.LanguageParser = LanguageType.GERMAN;
rapidSpellDialog.CheckerEngine.CheckCompoundWords = true;
rapidSpellDialog.CheckerEngine.DictFilePath = config.PathDictionary;
rapidSpellDialog.CheckerEngine.SetUserDictionary(new UserDictionary(config.PathUserDictionary));
The checker engine (RapidSpellChecker) has those properties too because you can use the engine by itself, and the RapidSpellDialog control has those properties because we wanted them to be exposed to the visual designer in VS. But internally we map the control properties to the engine. -your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 3/28/2017
Posts: 12
Location: Graz, Austria
|
well yes, i shouldn't need those lines but i somehow needed them - that's the point of the post. :) I rechecked. The menitioned internal remapping doesn't work.
I'm using your Net4 dll, version 5.4
Best regards!
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
Maybe I misunderstood your post, I understood your question as "why did you design it this way?" and my answer was "we didn't". My presumption was that you'd assumed it needed to be coded that way. It works OK here, so I'd ask; 1. If you omit those lines, what does it do differently? Does it still load the dictionary, for example? Or is there only 1 specific property that doesn't work. 2. If you test it in our demo projects, or a fresh project, does it work OK? One other point, although it shouldn't affect your test code above, the user options do have mirrors in the control properties, but the user options override the properties. Best Jim -your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 3/28/2017
Posts: 12
Location: Graz, Austria
|
Excuse me i wasn't clear with my subject - reading it again I indeed wasn't.
It affects all featured properties.
I could reproduce it at a fresh project.
1.) Place Rapid Spell Dialog
2.) Set LanguageParser-Property to "DUTCH"
3.) Set A breakpoint after initialization
Run:
when reaching breakpoint, examine object:
4.) rapidspelldialog.LanguageParser == "DUTCH"
rapidspelldialog.CheckEngine.LanguageParser == "ENGLISH"
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
Thanks, I see the issue now. The properties are only set in the checker engine after you call rapidSpellDialog.Check. I think I know now why this is an issue for you, it's because of how you're using the spell checker with DevExpress. You're trying to reuse the RapidSpellChecker instance for the Devexpress as-you-type event handler, but that's not actually safe to do (for other reasons mostly, that you've seen in my email to you). Using a separate instance will solve both issues. Let me also thank you publicly for sending through the DevExpress integration project, I'm going to post it as a KB article soon. -your feedback is helpful to other users, thank you!
|
|
|
