 |
TSFCandidateWindow.PNG (171,765 bytes) |
 |
The problem was that TSF was not initially disabled when initialized. You can change TSF::Init to use disabled document manager on start:void TSF::Init()
{
if (gInitCount++ == 0)
{
V(CoInitializeEx(NULL, COINIT_APARTMENTTHREADED));
V(CoCreateInstance(CLSID_TF_ThreadMgr, 0, CLSCTX_INPROC_SERVER, IID_ITfThreadMgr,
(void**)&gThreadMgr));
V(gThreadMgr->Activate(&gClientId));
CreateTextBoxDocument();
CreatePassBoxDocument();
CreateDisabledDocument();
ConfigureJapaneseIME();
V(gThreadMgr->SetFocus(gDisabledDocumentMgr));
}
}We will update our code for next release. |
|
|
Hi, the fix you mentioned avoid the candidate window appearing on initial application startup. But, if I deactivate -> reactivate the window, the candidate window appeared again although the behavior is different (only appears when I typed the first alphabet, disappears when two or more alphabets completes a construction of one katakana/hiragana) |
|
|
There was another disable code missing in TSF::MoveWindow:void TSF::MoveWindow(void* hWnd)
{
NS_LOG_TRACE("MoveWindow(hWnd=%p)", hWnd);
if (gCurrentWindow == hWnd && gThreadMgr != 0)
{
NS_ASSERT(gTextBoxStore != 0);
if (gTextBoxStore->IsEnabled())
{
V(gThreadMgr->SetFocus(gTextBoxDocumentMgr));
gTextBoxStore->OnLayoutChanged();
}
else if (gPassBoxStore->IsEnabled())
{
V(gThreadMgr->SetFocus(gPassBoxDocumentMgr));
gPassBoxStore->OnLayoutChanged();
}
else
{
V(gThreadMgr->SetFocus(gDisabledDocumentMgr));
}
}
}This should fix it, could you please confirm it works as expected in your application? |
|
|
Hhhmhh, it fixed the scenario I mentioned above. But now I cannot perform kanji conversion because anytime the alphabet sequence I input forms a valid hiragana/katakana, the hiragana/katakana is immediately recognized as the final input (the candidate window immediately disappears). For example, normally I can type 'kanji' which will be shown as 'かんじ', then I use space key to select how I convert those hiraganas into a kanji e.g. 漢字 or 幹事. But now, I don't have the chance for conversion because at the point I typed 'ka', it immediately fixed my input into hiragana 'か'. |
|
|
I can't reproduce your scenario, I can type the whole 'kanji' word and the candidate window does not close. Are you getting a call to TSF::HideKeyboard after typing 'ka'? |
|
|
No, TSF::HideKeyboard is not being called. If I removed the line V(gThreadMgr->SetFocus(gDisabledDocumentMgr)); from TSF::Init() and let the following lines in TSF::MoveWindow() else { V(gThreadMgr->SetFocus(gDisabledDocumentMgr)); } then it works. Maybe the gThreadMgr->SetFocus() shouldn't be called at the Init() timing ? |
|
|
TSF::MoveWindow would always be called when the application starts and activates the main window because we found that enabling a TSF document was not working while handling the WM_ACTIVATE message so we forced a WM_EXITSIZEMOVE message to do that. I guess then that it is safe to leave the Disable code only in the MoveWindow function if it is working for you that way. To be honest Text Service Framework documentation is so minimal and horrible that developing this is mostly by try and error if you are not able to find a similar example in the web. We will update our application framework as you suggested, thanks a lot for the feedback. |
|
|
Hi Sergio, Ok, thanks for the support. |
- Anonymous
