View Issue Details

IDProjectCategoryView StatusLast Update
0001514NoesisGUIC++ SDKpublic2019-07-18 21:23
ReporternikobarliAssigned Tosfernandez 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.2.3 
Target Version2.2.4Fixed in Version2.2.4 
Summary0001514: [TSF] Candidate window is always shown even if the focus is not on TextBox or any input related control
Description1. Create any window with empty XAML e.g.

<Grid></Grid>

2. Enable Japanese Input
3. Type some text
// Candidate window is shown on top-left corner of the screen (see attachment)

I expect that the candidate window is not shown, because we are not focusing to any input element.

TagsNo tags attached.
PlatformAny

Activities

nikobarli

nikobarli

2019-07-04 08:54

reporter  

TSFCandidateWindow.PNG (171,765 bytes)
TSFCandidateWindow.PNG (171,765 bytes)
sfernandez

sfernandez

2019-07-05 17:19

manager   ~0005810

Last edited: 2019-07-05 17:20

View 2 revisions

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.

nikobarli

nikobarli

2019-07-09 10:55

reporter   ~0005816

Last edited: 2019-07-09 10:56

View 2 revisions

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)

sfernandez

sfernandez

2019-07-09 14:24

manager   ~0005817

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?
nikobarli

nikobarli

2019-07-09 14:56

reporter   ~0005818

Last edited: 2019-07-09 14:56

View 2 revisions

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 'か'.

sfernandez

sfernandez

2019-07-09 15:56

manager   ~0005819

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'?
nikobarli

nikobarli

2019-07-10 06:50

reporter   ~0005835

Last edited: 2019-07-10 06:51

View 2 revisions

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 ?

sfernandez

sfernandez

2019-07-11 12:54

manager   ~0005840

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.
nikobarli

nikobarli

2019-07-12 01:25

reporter   ~0005844

Hi Sergio,

Ok, thanks for the support.

Issue History

Date Modified Username Field Change
2019-07-04 08:54 nikobarli New Issue
2019-07-04 08:54 nikobarli File Added: TSFCandidateWindow.PNG
2019-07-04 14:57 jsantos Target Version => 2.2.4
2019-07-04 14:57 jsantos Description Updated View Revisions
2019-07-04 14:57 jsantos Assigned To => sfernandez
2019-07-04 14:57 jsantos Status new => assigned
2019-07-05 17:19 sfernandez Status assigned => feedback
2019-07-05 17:19 sfernandez Note Added: 0005810
2019-07-05 17:20 sfernandez Note Edited: 0005810 View Revisions
2019-07-09 10:55 nikobarli Note Added: 0005816
2019-07-09 10:55 nikobarli Status feedback => assigned
2019-07-09 10:56 nikobarli Note Edited: 0005816 View Revisions
2019-07-09 14:24 sfernandez Status assigned => feedback
2019-07-09 14:24 sfernandez Note Added: 0005817
2019-07-09 14:56 nikobarli Note Added: 0005818
2019-07-09 14:56 nikobarli Status feedback => assigned
2019-07-09 14:56 nikobarli Note Edited: 0005818 View Revisions
2019-07-09 15:56 sfernandez Status assigned => feedback
2019-07-09 15:56 sfernandez Note Added: 0005819
2019-07-10 06:50 nikobarli Note Added: 0005835
2019-07-10 06:50 nikobarli Status feedback => assigned
2019-07-10 06:51 nikobarli Note Edited: 0005835 View Revisions
2019-07-11 12:54 sfernandez Status assigned => feedback
2019-07-11 12:54 sfernandez Note Added: 0005840
2019-07-12 01:25 nikobarli Note Added: 0005844
2019-07-12 01:25 nikobarli Status feedback => assigned
2019-07-18 21:23 sfernandez Status assigned => resolved
2019-07-18 21:23 sfernandez Resolution open => fixed
2019-07-18 21:23 sfernandez Fixed in Version => 2.2.4