登录
Microsoft.com
 
Microsoft
 
 
 

none
[windows8]是否可以用API开发输入法，是否仍旧兼容IME/IMM技术，如果是，有什么改进和变化? RRS feed

 > 

  • 常规讨论

  • Discussion
    登录进行投票
    0
    登录进行投票

    我十分关心[windows8]中的输入法支持技术，是否仍旧可以用API开发输入法，是否仍旧兼容IME/IMM技术，如果是，有什么改进和变化，或者需要特别注意力的地方?

    对于你们公司推出的TSF输入法框架，我十分不喜欢，太麻烦、太复杂，希望在windows8中去掉TSF。

    TSF推出很多年，市场上根本没有公司用，就知道TSF有多么失败。

    从TSF来看，你们根本没有为用户着想，只想显示自己的技术多牛X。

    请公开更多的输入法技术方面的资料和文档。

    2012年3月19日 6:47
    |

全部回复

  • Discussion
    登录进行投票
    0
    登录进行投票
     

    请参看 Windows 8 Consumer Preview and Windows Server 8 Beta Compatibility Cookbook http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27416  Third-Party Input Method Editors (IME) 那一节。   不是市场上没有，而是国内XP用户群太大，导致很多厂商一直不投入在TSF上。 TSF的高扩展性，和面向64为的特性，保证了他能够在Windows 8上服务于不同类型的应用程序。 在Windows 8下，只有支持使用了TSF才能在Metro App下使用。


    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    2012年3月20日 2:52
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票

    感谢你的回复。看了你提供的资料，十分郁闷：

    1、老式的输入法不能运行在windows8的metro界面下，只能运行在原来的Desktop界面下，是部分兼容的。

    2、老式的输入法能够运行的话，也可能会遇到一些问题，为了安全，windows8可能会阻止它们运行。

    但是我觉得：

    1、metro界面非常不友好，我不喜欢，这将是windows一个错误的改进。

    2、以安全为由推广TSF输入方法，是不能成立的。因为在TSF出现以前，事实证明，老式的输入法没有一个windows下的输第3方输入法给windows系统或者其它应用程序本身造成了安全。

    另外，文章中提到“See the Windows 8 IME Guidelines for more information.”

    我想知道Windows 8 IME Guidelines在哪里。

    希望提供了windows8中输入法的SDK中的TSF输入法的例子资料。

    你们的MSDN，我用它总是什么资料也找不到，搜索也找不到。但是你们自己却能轻易的找到很多资料。

    2012年3月20日 3:48
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    Windows 8 IME Guidelines  还在构建过程中，请耐心等待。  补充一句， Metro Style 主要是面向移动设备，平板等。所以他所肩负的功能不能够于桌面程序相比。

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    2012年3月20日 3:57
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票

    你说的这句话： Metro Style 主要是面向移动设备，平板等。

    ---->你说的非常好，所以我觉得PC和平板电脑不应该共用一个OS，应该为平板电脑开发单独的OS，我觉得你们MS这次的行为是有重大失误的，会害死Windows系统。

    还有，你说：“不是市场上没有，而是国内XP用户群太大，导致很多厂商一直不投入在TSF上。 TSF的高扩展性，和面向64为的特性，保证了他能够在Windows 8上服务于不同类型的应用程序。 在Windows 8下，只有支持使用了TSF才能在Metro App下使用。”

    ---->请问：如果TSF很简单、容易、并且没有问题，为什么厂商不去投入呢？我自己研究的结果表明，TSF复杂、麻烦、容易出问题，必须用C++语言，需要COM技术，还有线程管理、文档管理、编辑上下文管理、注册等等一堆接口，程序弄出来以后，还可能产生同步锁死的问题，比起API的方式麻烦的不是一点半点，哪个公司会愿意搞它。MS越来越喜欢搞大统一，这好象是独裁者的通病，你们把把文本输入、语音输入法、手写输入等等都搞在一起，完全没有必要，各用各的多好。每当看到你们搞大统一的平台设计，弄出一堆复杂的东西出来，都感觉你们是为了炫耀自己的技术牛X而搞的，不是为了用户的方便和需要而搞的。对你们很失望。我还是建议你们删除TSF，Metro界面，这些都是不好的设计。让开发者非常讨厌。

    2012年3月20日 9:26
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    感谢你的一些建议和反馈. 不过MSDN论坛上是很难让我们的产品部门听到你的声音的。 如果你对产品有任何意见和建议，我们还是希望你能够在Connect Site 提交反馈 https://connect.microsoft.com/，或者通过 User Voice站点：http://windows.uservoice.com/forums/152905-general

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    2012年3月20日 9:43
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票
    我相信这些建议我不是第一个提出来的，在全球范围内，你们MS收到这样的建议应该非常多，但是你们没有接受。多我一个不多，少我一个不少，我没有必要多此一举。现在的MS和以前不一样了，找不到方向，病急乱投医的感觉。你们把技术搞的太复杂，脱离了为消费者服务的初衷，情况会越来越糟。
    2012年3月20日 9:55
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    版主你好，请问windows7 sdk 中自带的TSF输入法源代码放在哪里，我怎么都找不到呵。
    2012年3月22日 6:59
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    下载安装 Windows SDK 7.0 http://www.microsoft.com/download/en/details.aspx?id=3138 后，在C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\winui\tsf   ， 这里也有例子：http://archive.msdn.microsoft.com/tsf 

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    2012年3月22日 7:25
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票
    版主你好，那个东西需要安装软件界有史以来最差、最恶心、最垃圾的.net 运行环境，一看到这个.net我就会呕吐的，还有它非常大，我安装不了。你把那个winui\TSF目录整个打个包发给我吧。我的邮箱dvdtdvd@gmail.com。谢谢你了。最后面的那9个例子，我看过了，不能完整的使用，还是需要SDK中的例子。
    2012年3月22日 9:46
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    版主，大好人，收到了，谢谢你。祝你钱途无量+前途无量。
    2012年3月23日 4:02
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    无意中搜索到这个帖子，解决了自己对METRO下IME的一些困惑。谢谢版主，并顺便说几句。

    TSF框架很好，也不是“太复杂、太繁琐”，只是因为大家不熟悉，所以才会有这样的感觉。一旦从原来IMM的API转到新的TSF，那将是一片全新的天地，会实现一些IMM时代无法实现的神奇功能。本人很幸运地过了这一道新的“门槛”，新版的IME也因为TSF而增色多多。

    以一个人的力量来评价或抵制TSF和METRO，显然是徒劳的。微软不是傻子，我们绝大多数人的水平显然不足以对它的水平和决策评头论足。或者，即便它真的是傻子，我们也必须乖乖地遵循它制定的各种规则。这是一个基本的事实。

    再次感谢版主提供的信息。关于“Windows 8 IME Guidelines  还在构建过程中，请耐心等待”，是否可以透露一下预计完成的时间？或者，是否可以提前透露一点其中的内容？本人的TSF IME可以在最早的开发者预览版下切换并勉强工作，而在消费者预览版下则完全不能切换了，实在有点着急。

    2012年3月25日 6:54
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    无意中搜索到这个帖子，解决了自己对METRO下IME的一些困惑。谢谢版主，并顺便说几句。

    TSF框架很好，也不是“太复杂、太繁琐”，只是因为大家不熟悉，所以才会有这样的感觉。一旦从原来IMM的API转到新的TSF，那将是一片全新的天地，会实现一些IMM时代无法实现的神奇功能。本人很幸运地过了这一道新的“门槛”，新版的IME也因为TSF而增色多多。

    以一个人的力量来评价或抵制TSF和METRO，显然是徒劳的。微软不是傻子，我们绝大多数人的水平显然不足以对它的水平和决策评头论足。或者，即便它真的是傻子，我们也必须乖乖地遵循它制定的各种规则。这是一个基本的事实。

    再次感谢版主提供的信息。关于“Windows 8 IME Guidelines  还在构建过程中，请耐心等待”，是否可以透露一下预计完成的时间？或者，是否可以提前透露一点其中的内容？本人的TSF IME可以在最早的开发者预览版下切换并勉强工作，而在消费者预览版下则完全不能切换了，实在有点着急。

    很遗憾，文档目前属于产品研发部门，无法得知具体内容和时间。 我们对外的技术支持只能得知那些是有的那些文档还没有。

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    2012年3月25日 7:34
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票

    无意中搜索到这个帖子，解决了自己对METRO下IME的一些困惑。谢谢版主，并顺便说几句。

    TSF框架很好，也不是“太复杂、太繁琐”，只是因为大家不熟悉，所以才会有这样的感觉。一旦从原来IMM的API转到新的TSF，那将是一片全新的天地，会实现一些IMM时代无法实现的神奇功能。本人很幸运地过了这一道新的“门槛”，新版的IME也因为TSF而增色多多。

    以一个人的力量来评价或抵制TSF和METRO，显然是徒劳的。微软不是傻子，我们绝大多数人的水平显然不足以对它的水平和决策评头论足。或者，即便它真的是傻子，我们也必须乖乖地遵循它制定的各种规则。这是一个基本的事实。

    再次感谢版主提供的信息。关于“Windows 8 IME Guidelines  还在构建过程中，请耐心等待”，是否可以透露一下预计完成的时间？或者，是否可以提前透露一点其中的内容？本人的TSF IME可以在最早的开发者预览版下切换并勉强工作，而在消费者预览版下则完全不能切换了，实在有点着急。

    你的是什么输入法，可否告之，给个网址。TSF框架我也弄得很清楚，所以我才说它很难、很复杂。你感觉不是“太复杂、太繁琐”，是因为你有了一些软件编程专业的基础，特别是懂了C++语言。我说它“太复杂、太繁琐”是有根据的。大多数的输入法发明人，或者是爱好者，是计算机专业以外的人：1、掌握C语言本身就是件难事，2、还要学习C++，类、构造函数、析构函数、继承、纯虚函数、保护、派生、私有等等。3、从面向过程转到面向对象，这个思维模式转换本身就是很难的，很多人做不到。4、理解接口是怎么回事。5、学习windows API编程。6、学习windows下的COM基础知识。7、TSF框架在实现一种简单的同时，造成了另一种复杂，就是程序运行的复杂，架构的层数多、速度慢，占用资源，并且会发生同步锁死。TSF编制出来的输入法没有原来API的高效、速度快、功能强大，可定制性也差。对于一个行外人来说，以上这些每一步都是困难和麻烦。 最直接的说，TSF框架大大抬高了外行人接触输入法的门槛，并且把开发人员更死的绑在windows的平台上，很多内行人都不一定学习和明白COM技术。使输入法完全变成了专业人士才能做的东西，这是非常不好的。象你我这样能把它学通的，是非常非常少的。相比较之下，MS如果更透明、更详细的公开原来API方式的编程，并且指出一些注意点和规避之处，那么很多问题都可以在原来的范围内解决，而不必弄出一个TSF来。我不同意这种主要为了商业利益，而搞大一统的解决方法。在这一点上，我十分不同意MS的做法。对于你的话，我想说两句，你学会了，才感觉到很容易。但是你忘记了你学习过程中的麻烦和艰难吗？你不应该这么快就忘记掉的，即使是为了显示你的牛X。你更不应该用自我的感觉来判断别人的看法。对事物要有一个客观公正的评价和看法才好。事实胜于一切，我还是那句话，看市场的反应，市场上的反应是对一个技术最好的评价，市场上根本没有公司搞TSF输入法，除了MS它自己之外。所以用事实说话，用市场说话，TSF框架不是个好东西，至少大多数人和公司的观点是相同的。
    2012年3月26日 10:44
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    这几天比较忙，刚看到这个帖子，简单回复两句。

    我的输入法在这里：http://www.pkucn.com/viewthread.php?tid=231477&extra=&page=1。这是2007年完成的上一个版本，IMM API接口的。使用TSF接口的新版本已经基本完成，尚未公布下载。该输入法的重要特征之一，就是努力以各种可能的方式，从既有的自然文本中提取出正在输入的“生词”，比如机器中保存的文档，或者从网页中复制的文字等。因为有了这些与用户的知识面相同的、海量文本的支持，那些不可能被任何输入法收录的各种人名、术语、专有词汇等，在这个输入法当中都会成为现成的词组，即便是第一次输入，它也已经提前存在－－－其实，它是在输入的同时才从那些自然文本中提取出来的。

    显然，这种技术极大地扩充了词组的来源，几乎涵盖了用户可能用到的所有词组，与常见的那些以庞大词库为支撑的输入法有着本质的区别。然而，因为早先的IMM API接口“看不到”正在编辑的文本，所以，当打开一篇包含生词的文档进行编辑时，虽然那些生词已经在文档中，但输入法却依然“不知道”，所以在输入的时候它还是“不存在”……使用TSF接口之后，输入法软件可以通过TSF的内在机制直接“看到”正在编辑的文档内容，并非常自然地“学会”其中的生词。更极端地一点，当用QQ聊天的时候，对方打过来一串生词，这边的输入法马上就可以“学会”并打出。显然，这一特征对于一些经常接触外来文档的用户而言是非常有价值的。对软件的试用发现，TSF带来的好处远远不止这些。个人非常欣赏TSF的这些新特征，这也是当初要坚决转移到TSF框架下的原动力。

    本人并非业内人士，也没有受过任何的专业训练，只是因为对输入法的喜爱才“无奈”地被绑架上了微软的大船，无论是IMM还是TSF，都是“自学成才”的结果。软件最早的版本诞生于1995年的UCDOS／CCDOS时代，开发工具是MASM汇编语言，它诞生不久WIN95即面世，为了软件的生存，又无奈地从零开始学习C语言和IMM API框架，并在1996年完成Windows版，此后一直修修补补，直到2007年完成上面链接的最后一个IMM API版本。此后，一直在观望和评估 TSF，直到去年国庆节正式尝试，一个假期的时间刚好使得TSF能够勉强运转起来。此后，用了3个月左右的业余时间，基本完成新版本的开发。 所有的TSF资料，均源于微软提供的那些，包括DEMO代码。

    学习的过程显然是“麻烦和艰难”的，对于一个没有同事可以交流、没有圈子可以学习、没有网络可以查找资料、看英文也不利索的菜鸟而言更是如此！幸运的是，无论多么的艰难，本人也居然摸爬滚打地混过来了。这个世界上没有一劳永逸的事情，特别在这个高速发展的时代更是如此。能做出一点成绩的人，一般都有了一定的岁数，学习的热情和动力都不是那么饱满，但无论是为了生存还是发展，不断的学习是必须的！不止是用户，微软自己也在不断地学习，相信它也不是那么的情愿。

    其实，升级到TSF框架，也不过像是医学上的“器官移植”，任何输入法的算法就像是现成的器官，无非是把它安置到一个新的人体上，通过手术接上几根必要的血管、神经而已，相比输入法复杂的内部算法，对这些接口的手术应该还是简单了许多。 当然，对那些几乎没有智能的输入法而言，与操作系统的接口也可能就是最难或者最繁琐的工作。

    至于TSF框架是不是一个“好东西”，一个人或者一群人的评价似乎都不重要，最重要的一点，如果没有TSF框架，METRO界面根本就不让你存活…… 如果没有更好的收益，相信微软自身也不会简单地淘汰掉IMM而换成TSF，TSF框架绝对不是为了折腾开发者。就个人而言，虽然对TSF只是肤浅地认知、并做了一点针对性的工作，就已经收到了令人欣喜的结果，相信别人会有更大的收获。

    关于国内输入法的圈子，本人多少也有一点了解，就此多说几句。坦白地说，国内研究输入法的个人或者小圈子，真正有水平的几乎没有，绝大多数的人还在以干掉五笔为目标、试图以某种更加独特的“编码”去实现更低的重码、更高的某些其他指标，取五笔而代之。这些人别说是编程，其实连输入法最根本都东西都没弄明白，他们的那些眼花缭乱的方案本身就是误入歧途的表现。或者换句话说，正是因为有了XP时代几乎没有任何门槛的“码表生成器”才造成了“千军万码”的乱象。从这一点上讲，TSF的高门槛倒未必全是坏事，至少可以让输入法的市场多一份清静。

    软件开发已经告别作坊时代，一个优秀的输入法也不是某个人拍脑袋可以攒出来的。真正有价值的思想，即便本人无法实现，也一定会有其他人对此有兴趣并使之实现；真正有生命力的输入法，一定能越过TSF的门槛！

    2012年3月28日 14:29
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    最重要的一点，如果没有TSF框架，METRO界面根本就不让你存活……

    ---->这个观点，我赞同，这就是我说的MS把开发人员更死的绑定在它的平台上。

    如果没有更好的收益，相信微软自身也不会简单地淘汰掉IMM而换成TSF，TSF框架绝对不是为了折腾开发者。

    ---->赞同这个观点：MS当然是为了更好的收益。MS使用TSF，就是为了增加计算机的资源消耗，让OS占用的内存更多些，然后促使用户升级计算机，卖内存等硬件的厂商就会跟着赚钱。从windows3.2开始到windows 7的历史，所有的升级过程都是这样，windows的体积不断变大，更占用资源越来越多，然后逼迫用户不断买新计算机。从这个角度看TSF的出现，是为了折腾开发者。好在MS这个鬼把现在玩不下去了，有了平板电脑出现，有了Android,ios,Chrome，linux出现，windows已经不是唯一的选择，我一直在想什么时候可以淘汰这个人类有史以来最大的计算机病毒程序。

    国内研究输入法的个人或者小圈子，......绝大多数的人还在以干掉五笔为目标......，取五笔而代之。

    ---->对于这样的目标，不是坏事情，新的淘汰旧的是进步是好事情。希望真的有人做到，相信那个时候，输入法的又一个春天会来到。

    从其它OS的情况来看，没有TSF框架，输入法运行的一样很好。其它的OS：Android,ios,Chrome，linux输入法使用的都是API编程，没有发现什么实现不了的功能。看了你的输入法的贴子，我没有发现那个功能有什么意义，我和很多人的观点一样，实现那样的功能没有用处。并且，在原来的API范围内不能实现的原因，并不是原来的API做不到，而是MS没有公开这方面的资料，这不是API编程的错，是MS故意捣蛋的错。

    XP时代几乎没有任何门槛的“码表生成器”才造成了“千军万码”的乱象。从这一点上讲，TSF的高门槛倒未必全是坏事，至少可以让输入法的市场多一份清静。

    ----我不赞同。相比之下，我更喜欢万紫千红、万马奔腾的、你所谓的“乱象”。我更憎恨只有一个皇帝的说了算、其它人都不能说话，一说话就是死罪的、独裁式的“清静”。

    软件开发已经告别作坊时代，一个优秀的输入法也不是某个人拍脑袋可以攒出来的。

    ---->对于大型的软件开发，确实是作坊做不了的。但是我觉得小型的软件，有兴趣的人，在任何时候都是可以在作坊中做出自己的软件的。软件作坊并没有被淘汰，你自己写程序不就是相当于一个软件作坊吗？

    2012年3月29日 0:48
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    无论观点是否相同，我们各自持保留意见吧。

    坦白地说，虽然实现了TSF框架的输入法，但并没有严格弄明白TSF。虽然费了不少周折，但还是没觉得TSF有多么的复杂，它仅仅是一个接口而已，对输入法的核心基本不造成影响，至少在我的方案中没有太大影响。软件的核心还是原来的代码，只是为了适应接口做了一些相应的调整，工作量不算很大；又因为接口提供了更具吸引力的功能，所以相应地为软件增加了一些功能。仅此而已。

    每个系统都有自己独特的体系，虽然Windows之外的其他系统都是API接口，看起来更简单，但本人还是没敢去折腾那些中的任何一个。感觉上，相对于从IMM到TSF的转变，软件开发体系的改变更是麻烦。本人只是能在Windows的体系下勉强做一点事情，可以预期的未来恐怕也仅仅是这样。

    还有一点。使用TSF可以很顺利地过渡到64位的系统，仅仅是将代码编译成64位的版本、并在系统中注册一下而已，非常非常简单。不知道IMM的API是否有过渡到64位的能力？本人以前曾经试验过，没成功。
    • 已编辑 laozuo 2012年3月29日 11:29
    2012年3月29日 11:26
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    [Bob Bao]版主,你好。你给我发的例子中的tsfapp目录中缺少readme.txt文件，其它目录中都有这个文件，这个目录中没有。还有，我该用哪个编译器来编译目录中的文件。我用codeblogs，使用vc2003,vc2005,vc2008,vc2010的编译器都没有通过，有一个函数的第2个参数不能转换，我加了强制转换，然后编译器通过了，但是链接不成功。不知道是什么原因.下面是提示信息:

    link.exe /nologo /LIBPATH:H:\G_codebolks\build\vc\lib /out:bin\Debug\win7_SDK.exe obj\Debug\context.obj obj\Debug\dataobj.obj obj\Debug\funcprov.obj obj\Debug\persist.obj obj\Debug\propldr.obj obj\Debug\test.obj obj\Debug\textstor.obj obj\Debug\tsfapp.obj obj\Debug\tsfedit.obj obj\Debug\tsfwnd.obj obj\Debug\tsfapp.res /DEBUG
    funcprov.obj : error LNK2019: unresolved external symbol __imp__SysAllocString@4 referenced in function "public: virtual long __stdcall CTSFEditWnd::GetDescription(wchar_t * *)" (?GetDescription@CTSFEditWnd@@UAGJPAPA_W@Z)
    persist.obj : error LNK2019: unresolved external symbol __imp__CreateStreamOnHGlobal@12 referenced in function "public: void __thiscall CTSFEditWnd::_SaveToFile(char *)" (?_SaveToFile@CTSFEditWnd@@QAEXPAD@Z)
    propldr.obj : error LNK2001: unresolved external symbol __imp__CreateStreamOnHGlobal@12
    persist.obj : error LNK2019: unresolved external symbol __imp__SetWindowTextW@8 referenced in function "private: void __thiscall CTSFEditWnd::_Load(struct IStream *)" (?_Load@CTSFEditWnd@@AAEXPAUIStream@@@Z)
    tsfedit.obj : error LNK2001: unresolved external symbol __imp__SetWindowTextW@8
    textstor.obj : error LNK2019: unresolved external symbol __imp__GetWindowTextLengthA@4 referenced in function "public: virtual long __stdcall CTSFEditWnd::QueryInsert(long,long,unsigned long,long *,long *)" (?QueryInsert@CTSFEditWnd@@UAGJJJKPAJ0@Z)
    tsfedit.obj : error LNK2001: unresolved external symbol __imp__GetWindowTextLengthA@4
    textstor.obj : error LNK2019: unresolved external symbol __imp__SendMessageA@16 referenced in function "public: virtual long __stdcall CTSFEditWnd::GetSelection(unsigned long,unsigned long,struct TS_SELECTION_ACP *,unsigned long *)" (?GetSelection@CTSFEditWnd@@UAGJKKPAUTS_SELECTION_ACP@@PAK@Z)
    tsfedit.obj : error LNK2001: unresolved external symbol __imp__SendMessageA@16
    textstor.obj : error LNK2019: unresolved external symbol __imp__GetCaretPos@4 referenced in function "public: virtual long __stdcall CTSFEditWnd::GetSelection(unsigned long,unsigned long,struct TS_SELECTION_ACP *,unsigned long *)" (?GetSelection@CTSFEditWnd@@UAGJKKPAUTS_SELECTION_ACP@@PAK@Z)
    textstor.obj : error LNK2019: unresolved external symbol __imp__VariantCopy@8 referenced in function "public: virtual long __stdcall CTSFEditWnd::RequestSupportedAttrs(unsigned long,unsigned long,struct _GUID const *)" (?RequestSupportedAttrs@CTSFEditWnd@@UAGJKKPBU_GUID@@@Z)

    .........

    2012年4月10日 9:26
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    我直接nmake就好了，请问你是否安装了Windows SDK， 因为在Windows上开发，很多的库都是需要SDK支持的，也就是说SDK提供了这些，本身不做开发的话，Windows并没有提供。

    P.S.  这里有更多的例子 http://archive.msdn.microsoft.com/tsf 

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us


    2012年4月10日 10:24
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票
    [Bob Bao]版主,你好。我没有安装SDK，太大，我的计算机配置不好，安装以后运行起来很慢。谢谢你的回复，我知道是什么原因，该怎么办了。
    2012年4月11日 0:16
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    您好，laozuo,您说 使用TSF可以很顺利地过渡到64位的系统，仅仅是将代码编译成64位的版本、并在系统中注册一下而已，非常非常简单。能不能将具体的步骤说一下？

    1.如何编译成64位的版本。

    2.如何在系统中注册一下？和32位注册是一样的吗？ 我用vs2005做的TSF输入法。非常感谢！

    2012年4月12日 8:45
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    您好，laozuo,您说 使用TSF可以很顺利地过渡到64位的系统，仅仅是将代码编译成64位的版本、并在系统中注册一下而已，非常非常简单。能不能将具体的步骤说一下？

    1.如何编译成64位的版本。

    2.如何在系统中注册一下？和32位注册是一样的吗？ 我用vs2005做的TSF输入法。非常感谢！

    以为这个帖子没人回复了，所以好久没再回来看看。今天刚看到你的问题。

    用TSF做64位的输入法真的很简单，因为它已经天然地具备了相应的能力。要实现这一点，大约只需要两个简单的步骤：1.编译成64位版本；2.在系统中注册成功。

    1.编译。我用的是VS2010，在项目／属性／配置管理器（在属性页界面右上角有一按钮）／活动解决方案配置。。。的选项中增加“X64”选项，并编译成功。64位编程有一些特殊的要求，比如数据类型、指针的转换等需要多加留意。只要32位版本能成功编译并运行，那么64位版本也基本就靠谱了。

    2.注册。这个跟32位系统下是一样的，都是用regsvr32.exe，将输入法的DLL文件向系统注册。在64位系统中，需要将32位及64位的DLL版本各注册一次，使其分别对应32和64位的应用。在windows8下面，需要指定DLL文件的绝对路径，regsvr32.exe也需要管理器权限运行。

    这一篇文章给了我很大的帮助，也建议你看看：http://www.pkucn.com/viewthread.php?tid=189370&extra=&page=1

    没用过VS2005，不知道是否有X64的选项。如果有，那么就应该可以开发64位的TSF输入法。

    以后多交流。祝你好运！


    • 已编辑 laozuo 2012年4月16日 14:47
    2012年4月16日 14:46
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    Bob Bao 版主，你好，我看了你们的 Windows  8 Release Preview Metro style app samples -  C++,源代码。
    竟然没有看到Text Serverice Frame Input  sample  只看到一个：Input Touch keyboard text input sample。
    我这个东西是TSF输入法吗？看了看里面的代码和TSF的也不一样呵？

    以前的TSF接口没有用到，这是什么新技术，需要学习什么新知识？哪里可以找到这些知识？

    下面这些代码是什么意思？

    //
    // MainPage.xaml.cpp
    // Implementation of the MainPage.xaml class.
    //

    #include "pch.h"
    #include "MainPage.xaml.h"
    #include "App.xaml.h"

    #include <collection.h>

    using namespace Windows::UI::Xaml;
    using namespace Windows::UI::Xaml::Controls;
    using namespace Windows::Foundation;

    using namespace Platform;
    using namespace TouchKeyboardTextInput;
    using namespace CppSamplesUtils;
    using namespace Windows::UI::Xaml::Navigation;   //Windows::UI::Xaml::这是什么用法，??
    using namespace Windows::UI::Xaml::Interop;        //Windows::UI::Xaml::这是什么用法，??
    using namespace Windows::Graphics::Display;        //Windows::UI::Xaml::这是什么用法，??
    using namespace Windows::UI::ViewManagement;   //Windows::UI::Xaml::这是什么用法，??

    MainPage^ MainPage::Current = nullptr;

    .......


    2012年6月15日 3:21
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    TSF是系统应用开发，并不是Metro风格程序开发，这个例子包里面都是Metro风格程序的例子，没有输入法的。 （输入法做成Metro风格，占全屏幕运行？ 似乎不对吧。）

    而你说的那些Windows::UI::Xaml:: 都是WinRT的库，用于Metro风格程序的UI和提供功能的。河泥输入法无关。 你提到的Input Touch keyboard text input例子是举例怎么在Metro应用中使用软键盘输入，与输入法无关。软件盘是一个在没有物理键盘下的触摸设备提供输入，他和输入法是无关的，你既可以用它在开启中文输入法是输入中文，也可以输入日文等。 

    TSF更新的内容依旧还是在 Windows 8 RP and Windows Server 2012 RC Compatibility Cookbook 文档中描述，只是更为详细一些：http://www.microsoft.com/en-us/download/details.aspx?id=27416 。目前没有Win 8 TSF输入法例子。

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    2012年6月15日 3:55
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票
    谢谢版主,对于你说的我一点也不了解,但是现在知道了一点。我实在是讨厌Metro风格，好象为了保证这个风格，把其它的都耽误了，竟然还没有Win 8 TSF输入法例子。
    2012年6月15日 8:05
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    Windows 8 IME Guidelines和win 8 tsf的例子出来了没有？
    2012年6月26日 3:55
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    顺道问一下，能否使用除了c++之外的语言实现tsf，比如js
    2012年6月26日 3:57
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    Windows 8 IME Guidelines已发布： http://msdn.microsoft.com/en-us/library/windows/apps/hh967425.aspx

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    2012年7月11日 12:34
    |
    版主
  • Discussion
    登录进行投票
    0
    登录进行投票
    Windows 8 IME Guidelines已发布： http://msdn.microsoft.com/en-us/library/windows/apps/hh967425.aspx

    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    已看到，谢谢版主分享！

    不知是否有现成的例子？或者能否提供一点有关创建Metro风格窗口的代码？现在还完全不明白Metro编程的套路。

    2012年7月14日 16:02
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    有个问题在这里问下，WIN8中使用IMM的部分程序兼容性问题。

    WIN8系统自带微软拼音显示为“已禁用IME”，无法使用，而第三方输入法都正常，请问下该如何解决。

    2012年7月14日 19:32
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    请教一个问题，我用tsf做了一个输入法，安装之后，在记事本中可以正常使用，但在win8的ie10中，没有任何反应。win7的ie8也没有问题。

    你们的微软拼音是可以在ie10中用的，我在tsf的DllMain中加了一个MessageBox，也没有弹出消息，也就是这个dll根本没有被加载。

    可能是什么问题？


    • 已编辑 周永 2012年8月29日 14:27
    2012年8月29日 14:26
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    史上最有耐心的版主！

    张瑞森

    2012年9月6日 6:56
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

     我的编译没过，难道要用cygwin?

    有没有完整的编译，安装步骤？

    2012年9月26日 7:27
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    我的编译没过，难道要用cygwin?

    有没有完整的编译，安装步骤？

    2012年9月26日 9:27
    |
  • Discussion
    登录进行投票
    0
    登录进行投票

    请问TSF的示例如何安装运行的？我在regsvr32这一步卡住了。

    我下载了TSF的示例，在vs2008里的命令行工具里使用nmake。然后看到生成的文件夹里有TextService.dll这个文件。

    使用regsvr32注册这个dll，为什么总是不成功呢？

    系统是win7

    2012年11月5日 3:10
    |
  • Discussion
    登录进行投票
    0
    登录进行投票
    hello bob，最近在做一个textbox，需要IME跟随，在win8 desktop下始终词选窗口在左上角，后来发现Sublime也有同样情况，后来据说MSPinYin同时实现了IME和TSF，但通过IME API不能控制CompositionPosition，其他IME输入法都ok，想问问是什么情况，另外我对TSF本身也不反感，但MSDN归在legacy user interaction features，想问问后续TSF发展计划如何?是如何规划的?
    2014年1月9日 16:13
    |