Handwriting component of language bar not loading

[Guest]

I am trying to get the Handwriting support working in my image. (This is
with Office 2003 installed) We do not use the standard shell so I cannot use
the language bar directly.

On a regular PC I can do the following:

hr = langBarItemMgr.CoCreateInstance(CLSID_TF_LangBarItemMgr);
DWORD numItems = 0;
hr = langBarItemMgr->GetItemNum(&numItems);

TF_LANGBARITEMINFO *pInfo = new TF_LANGBARITEMINFO[numItems];
DWORD *pdwStatus = new DWORD[numItems];
ITfLangBarItem **ppItem = new ITfLangBarItem *[numItems];


langBarItemMgr->GetItems(numItems,ppItem,pInfo,pdwStatus,NULL);
for (int i = 0; i < numItems; i++)
{
TRACE(_T("Item %d: %S\n"),i,pInfo.szDescription);
}

On my xpe image I cannot get the handwriting component.


I will see the Handwriting item in this list. I can see that the
Handwriting services are installed as an input service in the regional
settings control applet.
Oddly, the box that says Turn off advanced text services remains checked no
matter how many times I try to uncheck it.

Any ideas?

 

[KM]

John,

I am trying to get the Handwriting support working in my image. (This is
with Office 2003 installed)

Did you mean you got Office 2003 installed on your XPe image?
Be aware about legal restrictions of using Office on XPe.

We do not use the standard shell so I cannot use
the language bar directly.

On a regular PC I can do the following:

hr = langBarItemMgr.CoCreateInstance(CLSID_TF_LangBarItemMgr);
DWORD numItems = 0;
hr = langBarItemMgr->GetItemNum(&numItems);

TF_LANGBARITEMINFO *pInfo = new TF_LANGBARITEMINFO[numItems];
DWORD *pdwStatus = new DWORD[numItems];
ITfLangBarItem **ppItem = new ITfLangBarItem *[numItems];


langBarItemMgr->GetItems(numItems,ppItem,pInfo,pdwStatus,NULL);
for (int i = 0; i < numItems; i++)
{
TRACE(_T("Item %d: %S\n"),i,pInfo.szDescription);
}

On my xpe image I cannot get the handwriting component.

It may help if you:
- Mention what error (hr result) you are getting from the
[Co]CreateInstance above.
- Verify that on your XPe image the appropriate CLSID
(CLSID_TF_LangBarItemMgr) is registred.

KM

 

[Guest]

Hi KM,

We understand the legal restrictions. That has been successfully addressed.

Sorry, I don't think I was clear. I can create the LangBarItemMgr and
enumerate through items. However, if I do this on a regular PC I get about 9
items including two handwriting related pieces. If I do it on the XPE system
I only get 3 (help, keyboard, and options).

thanks,

John

 

[KM]

John,

We understand the legal restrictions. That has been successfully
addressed.

If you are allowed, could you please elaborate on that?
It would be interesting to some folks here to hear how you were able to
address the legal issues with installing Office on XPe?

Sorry, I don't think I was clear. I can create the LangBarItemMgr and
enumerate through items. However, if I do this on a regular PC I get
about 9
items including two handwriting related pieces. If I do it on the XPE
system
I only get 3 (help, keyboard, and options).

AFAIK, there is only Japanese, Korean and Taiwan handwriting software
components in the XPe database.
Which one you added?
What locale is your image for?

KM

 

[KM]

John,

I forgot to ask..
Does your Config include "TSF Shared Candidate User Interface Service" and "Primitive: Msctf" components?
(the latter is likely there since you were able to use the LangBarItemMgr interface)

KM

PS. Just to investigate the problem, you can build a sample TSF service, register it at run time and see if it appears in the
LangBar item enumeration.

 

[Guest]

We understand the legal restrictions. That has been successfully

If you are allowed, could you please elaborate on that?
It would be interesting to some folks here to hear how you were able to
address the legal issues with installing Office on XPe?

The key point in the licensing is that Office on XPE is not allowed for a
general purpose machine. In other words, you can't just be able to fire up
Word and write a letter to Mom. In our situation it is embedded in a larger
framework where office becomes a small percentage of the overall
functionality.

AFAIK, there is only Japanese, Korean and Taiwan handwriting software
components in the XPe database.
Which one you added?
What locale is your image for?

Office 2003 has handwriting software components for English.

Does your Config include "TSF Shared Candidate User Interface Service"
and "Primitive: Msctf" components?
(the latter is likely there since you were able to use the LangBarItemMgr interface)

The first was not there - a new image shows the same problem.

PS. Just to investigate the problem, you can build a sample TSF service, register it > at run time and see if it appears in the LangBar item enumeration.

I guess I'll have to try this one.

An interesting thing I noticed though is that if I go into the TextServices
Advanced tab, the "Turn off advanced text services" *is* checked. I can
uncheck it all I like but each time I go back it is enabled. I tried to use
file and regmon on loading this dialog but no apparent missing dependencies.


John

 

[KM]

John,

The key point in the licensing is that Office on XPE is not allowed for a
general purpose machine. In other words, you can't just be able to fire up
Word and write a letter to Mom. In our situation it is embedded in a larger
framework where office becomes a small percentage of the overall
functionality.

Thanks for the input. That is valuable info.

...
Office 2003 has handwriting software components for English.

True. So you were referring to the Office handwritting, not XPe "standard".
This all goes to the next question - how did you install the Office on your image? Manually, or did you componentize it?
Please keep in mind that for the Office to properly function on the system it has to replace some system Dlls. So you may want to
make sure all Office files are installed on the top of other component files.

The first was not there - a new image shows the same problem.

You will also need the following components:
"Active IMM Library"
"Text Services Framework" (likely in your image now, right?)
"Speech Text Services v1.1" (this may seem to be optional but I think Office will require a proper registration of the
Sptip.dll).

I guess I'll have to try this one.

I also recommend you to give it a try with XPProEmulation image (www.xpefiles.com) as it mayquickly answer your questions about
missing dependencies.

An interesting thing I noticed though is that if I go into the TextServices
Advanced tab, the "Turn off advanced text services" *is* checked. I can
uncheck it all I like but each time I go back it is enabled. I tried to use
file and regmon on loading this dialog but no apparent missing dependencies.

Could be because of the missing components (see above).
Also, make sure the ctfmon.exe is running in background. (http://support.microsoft.com/kb/q282599/)

KM

 

[Guest]

Hi KM,

True. So you were referring to the Office handwritting, not XPe "standard".
Yes.

This all goes to the next question - how did you install the Office on your image? Manually, or did you componentize it?
Please keep in mind that for the Office to properly function on the system it has to replace some system Dlls. So you may want to
make sure all Office files are installed on the top of other component files.

I installed it manually.

"Active IMM Library"
"Text Services Framework" (likely in your image now, right?)
"Speech Text Services v1.1" (this may seem to be optional but I think Office will

I added these (TSF was already there) as well as CUAS IME. I also realized
office was unable to register the typelib for ven2232.olb without
msctfime.ime and stdole.tlb (the latter doesn't seem to be in any xpe
component?)

Also, make sure the ctfmon.exe is running in background.

Hmm. Its not. Its in the registry to start though. Running it manually
simply exits immediately. Filemon and regmon show no obvious dependencies.
Is there a way to spy on CoCreateInstance failures?

 

[KM]

John,

I added these (TSF was already there) as well as CUAS IME. I also
realized
office was unable to register the typelib for ven2232.olb without
msctfime.ime and stdole.tlb (the latter doesn't seem to be in any xpe
component?)

The stdole.tlb is not in XPe Repository. You will have to copy over this
file to your runtime manually from XP Pro machine. You will also need to
"register" properly this type lib. Easiest way - to grab relevant
reg.entries from XP Pro machine. I think most of them will be around 16-bit
Ole automation registry keys.
Btw, IIRC, this type lib is required by Office.

Also, just in case, add the following components:
"Ole Automation"
"Legacy COM Support Library (16 Bit)"

Hmm. Its not.

Then the text input service support won't probably work for any active
window.
I don't think, though, the TSF on the XPe has been much tested around ctfmon
(MS Office was not inteded to run on XPe anyway). You may want to check it
out on XP Pro first with DependencyWalker Profiler to see what gets loaded
for Ctfmon.

Its in the registry to start though. Running it manually
simply exits immediately. Filemon and regmon show no obvious
dependencies.
Is there a way to spy on CoCreateInstance failures?

Well.. It depends on what exactly you are wanting to spy on.
If registry access failure - Regmon, if file access failure - Filemon.
HR error code would probably be helpful too. With Filemon you would know
what Dlls needed to be loaded for particular COM object. Easy to compare to
the same log from working XP Pro machine.
Personally, I like Dependency Walker profiling feature - very informative.

Other than that I don't know any other useful tool to use to spy on COM
calls (maybe also Apimon but not as useful as others).

One more thing for you that may help narrowing down Office Install issues on
XPe. Make sure to clear up "Do not copy help files for ..." opton in the
Configuration settings and for all [related] components like TSF and etc. It
may be important as TSF, for instance, brings the langbar.chm (it's been
known some help files are required to run some components).

KM

 

[Guest]

I'm still looking into this more but it seems to be related to imm32.dll and
msctf.dll.
When I run depends profiling on the xpe system, a number of GetProcAddress
calls (from msctf into imm32) all fail. The imm32.dll is apparently not
loaded as the library handle is null. However, there is no failed
LoadLibrary either (which explains why filemon didn't show anything). This
all makes sense as the imm32.dll seems to be what implements the Cicero
window class which is used by the handwriting tools.

John,

I added these (TSF was already there) as well as CUAS IME. I also
realized
office was unable to register the typelib for ven2232.olb without
msctfime.ime and stdole.tlb (the latter doesn't seem to be in any xpe
component?)

The stdole.tlb is not in XPe Repository. You will have to copy over this
file to your runtime manually from XP Pro machine. You will also need to
"register" properly this type lib. Easiest way - to grab relevant
reg.entries from XP Pro machine. I think most of them will be around 16-bit
Ole automation registry keys.
Btw, IIRC, this type lib is required by Office.

Also, just in case, add the following components:
"Ole Automation"
"Legacy COM Support Library (16 Bit)"

Hmm. Its not.

Then the text input service support won't probably work for any active
window.
I don't think, though, the TSF on the XPe has been much tested around ctfmon
(MS Office was not inteded to run on XPe anyway). You may want to check it
out on XP Pro first with DependencyWalker Profiler to see what gets loaded
for Ctfmon.

Its in the registry to start though. Running it manually
simply exits immediately. Filemon and regmon show no obvious
dependencies.
Is there a way to spy on CoCreateInstance failures?

Well.. It depends on what exactly you are wanting to spy on.
If registry access failure - Regmon, if file access failure - Filemon.
HR error code would probably be helpful too. With Filemon you would know
what Dlls needed to be loaded for particular COM object. Easy to compare to
the same log from working XP Pro machine.
Personally, I like Dependency Walker profiling feature - very informative.

Other than that I don't know any other useful tool to use to spy on COM
calls (maybe also Apimon but not as useful as others).

One more thing for you that may help narrowing down Office Install issues on
XPe. Make sure to clear up "Do not copy help files for ..." opton in the
Configuration settings and for all [related] components like TSF and etc. It
may be important as TSF, for instance, brings the langbar.chm (it's been
known some help files are required to run some components).

KM

 

[Guest]

At this point I'm pretty sure the fact that ctfmon won't load (which in turn
seems likely to be a result of msctf.dll failing to load imm32.dll) is root
of the entire problem.

Normal dependency and resgistry monitoring doesn't yield useful information.
Unfortunately, without any more clues I can't justify spending any more time
on this right now although I hope to get back to it someday.

If anyone wants to take up the challenge I'd love to hear about it.

John

I'm still looking into this more but it seems to be related to imm32.dll and
msctf.dll.
When I run depends profiling on the xpe system, a number of GetProcAddress
calls (from msctf into imm32) all fail. The imm32.dll is apparently not
loaded as the library handle is null. However, there is no failed
LoadLibrary either (which explains why filemon didn't show anything). This
all makes sense as the imm32.dll seems to be what implements the Cicero
window class which is used by the handwriting tools.

John,

"Active IMM Library"
"Text Services Framework" (likely in your image now, right?)
"Speech Text Services v1.1" (this may seem to be optional but I think
Office will

I added these (TSF was already there) as well as CUAS IME. I also
realized
office was unable to register the typelib for ven2232.olb without
msctfime.ime and stdole.tlb (the latter doesn't seem to be in any xpe
component?)

The stdole.tlb is not in XPe Repository. You will have to copy over this
file to your runtime manually from XP Pro machine. You will also need to
"register" properly this type lib. Easiest way - to grab relevant
reg.entries from XP Pro machine. I think most of them will be around 16-bit
Ole automation registry keys.
Btw, IIRC, this type lib is required by Office.

Also, just in case, add the following components:
"Ole Automation"
"Legacy COM Support Library (16 Bit)"

Also, make sure the ctfmon.exe is running in background.

Hmm. Its not.

Then the text input service support won't probably work for any active
window.
I don't think, though, the TSF on the XPe has been much tested around ctfmon
(MS Office was not inteded to run on XPe anyway). You may want to check it
out on XP Pro first with DependencyWalker Profiler to see what gets loaded
for Ctfmon.

Its in the registry to start though. Running it manually
simply exits immediately. Filemon and regmon show no obvious
dependencies.
Is there a way to spy on CoCreateInstance failures?

Well.. It depends on what exactly you are wanting to spy on.
If registry access failure - Regmon, if file access failure - Filemon.
HR error code would probably be helpful too. With Filemon you would know
what Dlls needed to be loaded for particular COM object. Easy to compare to
the same log from working XP Pro machine.
Personally, I like Dependency Walker profiling feature - very informative.

Other than that I don't know any other useful tool to use to spy on COM
calls (maybe also Apimon but not as useful as others).

One more thing for you that may help narrowing down Office Install issues on
XPe. Make sure to clear up "Do not copy help files for ..." opton in the
Configuration settings and for all [related] components like TSF and etc. It
may be important as TSF, for instance, brings the langbar.chm (it's been
known some help files are required to run some components).

KM