locked
TSF's user data and registry in Metro RRS feed

  • Question

  • I am developing a TSF that have to save data for user input habit and setting, but I find that Metro app have to use "ApplicationData::Current->LocalSettings" and StorageFile. My questions are that.
      • How to call ApplicationData and StorageFile from TSF in C++?
      • Is there any better way for TSF in C++ to save data and setting?
    Monday, September 17, 2012 3:54 AM

Answers

  • These were the location options listed in the document. Can you use any of those locations?

    • Dictionary Files   Frequently, IMEs have read-only dictionary files to map user input to specific characters. To access these files from inside an app container, your IME must place them under the Program Files or Windows directories. By default, these directories can be read from an app container, so IMEs can access dictionary files that are stored in these locations. If your IME must store the dictionary file somewhere else, it must explicitly manipulate the Access Control Lists (ACL)  of the dictionary files to allow access from app containers.
    • Internet Updating   If your IME needs to update its dictionaries using data from the Internet, it can't reliably do so inside an app container, because Internet access isn't always permitted. Instead, your IME should run a separate desktop process that's responsible for updating the dictionary files with data from the Internet.
    • On-the-fly learning   If an IME is running in an app container that has Internet access, there's no restriction on the endpoints that the IME can communicate with. In this case, an IME can use a cloud server to provide on-the-fly learning services. Some IMEs download and upload user input on the fly, while the user is typing. Since Internet access is not guaranteed in an app container, this may not always be allowed in Windows Store apps.
    • Sharing information between processes   IMEs may need to share data about the user’s input preferences between apps that are in different app containers. Use a web service to share data between Windows Store apps.

    David Lamb

    • Proposed as answer by Jesse Jiang Thursday, September 20, 2012 7:51 AM
    • Marked as answer by Jesse Jiang Monday, September 24, 2012 2:51 AM
    Wednesday, September 19, 2012 2:40 AM
    Moderator

All replies

  • anyone help?

    Eric Siu

    Tuesday, September 18, 2012 4:10 AM
  • I've asked the our IME / TSF team for the recommended guidance in this area. Should hear something soon.

    Thanks!


    David Lamb

    Tuesday, September 18, 2012 6:43 PM
    Moderator
  • I heard back from the IME team. They believe the published Guidelines and checklist for IME development (Windows Store apps) document and Input Method Editor (IME) sample should answer your question. Let me know if your question isn't fully addressed after reviewing those resources.

    My read on it tells me you would want to store that type of data in a single system wide location.


    David Lamb


    Tuesday, September 18, 2012 11:07 PM
    Moderator
  • The sample is almost same as I got from MS Taiwan. It will load IME input table from install folder but I cannot find how to store user habit table a location.

    Eric Siu

    Wednesday, September 19, 2012 1:52 AM
  • These were the location options listed in the document. Can you use any of those locations?

    • Dictionary Files   Frequently, IMEs have read-only dictionary files to map user input to specific characters. To access these files from inside an app container, your IME must place them under the Program Files or Windows directories. By default, these directories can be read from an app container, so IMEs can access dictionary files that are stored in these locations. If your IME must store the dictionary file somewhere else, it must explicitly manipulate the Access Control Lists (ACL)  of the dictionary files to allow access from app containers.
    • Internet Updating   If your IME needs to update its dictionaries using data from the Internet, it can't reliably do so inside an app container, because Internet access isn't always permitted. Instead, your IME should run a separate desktop process that's responsible for updating the dictionary files with data from the Internet.
    • On-the-fly learning   If an IME is running in an app container that has Internet access, there's no restriction on the endpoints that the IME can communicate with. In this case, an IME can use a cloud server to provide on-the-fly learning services. Some IMEs download and upload user input on the fly, while the user is typing. Since Internet access is not guaranteed in an app container, this may not always be allowed in Windows Store apps.
    • Sharing information between processes   IMEs may need to share data about the user’s input preferences between apps that are in different app containers. Use a web service to share data between Windows Store apps.

    David Lamb

    • Proposed as answer by Jesse Jiang Thursday, September 20, 2012 7:51 AM
    • Marked as answer by Jesse Jiang Monday, September 24, 2012 2:51 AM
    Wednesday, September 19, 2012 2:40 AM
    Moderator
  • Thanks, I think I will try Option 1.

    Eric Siu

    Wednesday, September 19, 2012 3:18 AM