問題タブ [uitextinput]

私は UITextInput プロトコルの selectedTextRange プロパティと beginOfDocument プロパティを使用してこれを行ってきましたが、以下の記事で学んだように、UITextField は iOS 5 で UITextInput プロトコルにのみ準拠し始めているため、私のアプリは iOS 4.3 でクラッシュします。iOS 4.3 でこれを行う別の方法が必要です。

UITextField および UITextView の UITextInput プロトコルを使用して選択結果を管理すると、クラッシュが発生します。

これが私が今やっていることです（selfは私のUITextFieldサブクラスです）：

を使用して自分でカスタムのオートコンプリートを行っていますが、オートinsertText:コレクトの提案が表示されている場合、ビューは奇妙な状態になります。

を使用する[textView unmarkText]と、自動修正ポップアップが閉じられますが、自動修正は受け入れられます (これは悪いことです)。オートコレクトの提案をプログラムで拒否する方法はありますか?

私の現在の「解決策」は機能しますが、それはひどくハッキーであり、将来も機能し続けると想定する理由はありません. これを行うより良い方法はありますか？

Core Textのオープンソースの再実装UITextViewと使用はありますか？UITextField

AppleのSimpleTextInputwithとclassesがあり、これは明示的に次のように述べていますSimpleCoreTextView。EditableCoreTextView

言い換えれば、それは例えばアラビア語を処理せず、非効率的です。

UITextInputCore Textと一連のプロトコルに基づいて、編集可能なテキストフィールドまたはテキストビューを完全に実装するための代替手段はありますか？

UITextInput プロトコルを実装するカスタム テキスト エディターを備えたアプリがあります。iOS 6 では、Apple は 1 つの新しい必須メソッドをプロトコルに追加しました。

これを実装しましたが、それをトリガーする方法が見つからないようです。少なくとも私のアプリの動作では、テキスト システムによって呼び出されることはないようです。何に使われているか分かる人いますか？

リッチ UITextView (iOS 6) の属性付きテキストの一部またはすべてを変更し、ユーザーが変更を元に戻せるようにしたいと考えています。

NSUndoManager documentationを読んだ後、最初の方法を試しました：

元に戻す操作は次のように単純であると予想していました:
このメソッドを宣言します:

次を呼び出して、UITextView のテキストを変更します。

しかし、それを行った後、NSUndoManager は元に戻すことができないと言います。

だから私は2番目の方法を試しました：

これを宣言します。

テキストを次のように変更します。

その後、NSUndoManager も元に戻せないと言います。

なんで？

属性付きテキストを変更するコードをトリガーするとき、ユーザーは UITextView を編集していることに注意してください。

回避策は、UITextInput プロトコル メソッドを介してテキストを直接置き換えることです。次のメソッドは非常に便利ですが、NSAttributedString に相当するものは見つかりませんでした。私はそれを逃しましたか？

ここで提案されているハックは、貼り付け操作をシミュレートすることです。可能であれば、これを避けたいと思います（理由はまだありません。後で噛まれないようにするには、あまりにも汚いと感じているだけです）。

私はコアテキストを使用してiOSで独自のテキストエディタを作成しています。1つの例外を除いて、ほとんどすべてがうまく機能します。テキストドキュメントが「大きい」場合、スタッフは実際に速度が低下し始めます。私は、iOSが選択の変更を含むすべての変更でドキュメントテキスト全体を要求していることを発見しました（少なくとも、選択の変更をUITextInputDelegateに通知するとき）。問題の一部は、ドキュメントを段落に分割し、変更された段落のみをレンダリングすることで、CoreTextコードをすでに最適化していることです。ただし、これを行うと、ドキュメント文字列（はNSAttributedString）が個別の「段落オブジェクト」に分割されます。そのため、iOSがテキストドキュメント全体を要求する場合、それらすべての文字列を1つの文字列に結合する必要があり、これには時間とメモリがかかります。

私の解決策は、iOSにとメソッドに誤ったを与えUITextPosition、beginningOfDocumentそれらendOfDocumentの位置を現在の選択と交差する段落に制限することです。これは実際には非常にうまく機能しています。iOSは現在、変更の現在の段落のみを要求しているため、速度低下は完全に解消されています。

これまでのところ、とても良いですが、これが何かを壊すかもしれないのではないかと少し心配しています。私はこれを少しテストしましたが、何も壊れていませんが、テキストエディタはテストするのが難しい場合があります（エッジ状態で壊れるかどうかは誰にもわかりません）。

私は2つの質問があります：

1. iOSは、変更のたびにドキュメントテキスト全体を要求する必要がありますか？そうでない場合は、おそらく私のUITextInputプロトコルメソッド内の他のメソッドが間違った値を返し、iOSがドキュメント全体を要求する原因になっている可能性があります。
2. これが実際に何かを壊すかどうか誰かが知っていますか？

これは私にとって何年もの間ジレンマでした、私が尋ねるべきであることがちょうど起こりました。

に文字数制限がある、inputまたはtextareaユーザーが最大文字数を入力するのに十分な表示領域を許可したいとします。

制限：10

iiiiiiiiii

対。

wwwwwwwww

最初は、ロラムまたはランダムなテキストに基づいてサイズを推測します。

よく考えてみると、最大サイズはテキスト内のサイズ変更された文字の数に基づいてemいます。

そこで、表示フィールドの最小サイズx文字制限を作成する段階を経ましたが、「w」と「m」だけで構成される文を作成することは不可能であり、テキスト領域emがばかげて大きくなるため、これは明らかにばかげています。

だから私の質問は：あなたがおそらく文に入れることができる絶対的な最もサイズの大きい文字は何ですか？ em

または、この情報をどのように見つけますか？開発者として私はここに質問をしましたが、知っている言語-人-オーバーフローはありますか？

ウッドチャックはそれでしょうか？：

ウッドチャックが木材をチャックする場合、ウッドチャックはどのくらいの木材をチャックしますか？ウッドチャックが木をチャックする場合、ウッドチャックは彼がチャックできるすべての木材をチャックします。

ここでの割合は、14(ems)/155(chars)たとえば10％弱です。

これを判断するためのより技術的な方法はありますか？これを10％以上超えるような異常値の状況はありますか（www.www.comなど）？

うまくいけば、この情報を使用して、入力/テキスト領域を必要な大きさにすることができます。小さくはありません。

UITextInputCoreText を使用し、プロトコルに準拠するカスタム UITextView (EGOTextView に基づく) を実装しています。1つの厄介なことを除いて、ほとんどすべてが正常に機能しています（うわー！）。オートコレクトの提案テキストは垂直方向にミラーリングされ、そのハイライトはわずかに右に移動します。外観は次のとおりです。

テキスト フィールドに「helo」と入力すると、「help」に自動修正されます。ご覧のとおり、オートコレクト テキストは垂直方向にミラーリングされていますが、その背景はミラーリングされていません。また、水平方向に右に ~7pt オフセットされています。

2 番目の問題 (水平オフセット) に対処するために、firstRectForRange:メソッドが正しい を返すことを確認しましたCGRect。私はこれを2つの方法で行いました。UIMenuController最初は、 a を表示すると正しい場所に表示されることを視覚的に確認することでした(表示されます)。CGRect2 つ目は、返された byの周りに輪郭を描くことfirstRectForRange:です。CGRectこれは、アウトライン化された同じテキストです。

ご覧のとおり、正しい領域の輪郭が描かれていますが、オートコレクトは間違ってマーク/強調表示されています。

どんなコードでも喜んで共有しますが、それは巨大なクラスであり、今ではかなり困惑しています。どんなポインタでも大歓迎です！

編集:ソース コードは、このリポジトリの Experimental ブランチで入手できます: github.com/cbrauchli/EGOTextView。

iOS アプリで日本語入力を微調整する方法に関して、次の問題があります。わかりやすくするために、この投稿に画像を含めます (以下を参照)。

ご覧のとおり、入力テキスト フィールドに「や」と入力すると、キーボードの上に一連の選択肢 (や 役 矢 訳 や 焼き …) が表示され、変換が可能になります。

知りたいことは次のとおりです。図に示されている選択肢は、特定のアプリでは意味がありません。ユーザーに提供される可能な変換を自分で設定できるようにしたいと思います。この場合は（山形県山口県山梨県）となります。どうすればこれを達成できるか知っている人はいますか？

つまり、キーボードの上に表示される一連のデータを処理する方法を見つけようとしています。

関連情報をお寄せいただきありがとうございます。

UITextInput を実装するビューがあり、元に戻すのサポートを追加しました。現在、個々のキー ストロークまたはバックスペースは、取り消し可能なイベントとして記録されます。

イベントをグループ化できることと、最初のキーストロークで元に戻すグループを開くことができることを知っています。しかし、どこに行ってグループを閉じるのでしょうか? ユーザーがデバイスを振ったときにグループが開いていると、例外が発生します。元に戻すときにグループを開くことはできません。

NSUndoManager インスタンスがアクション メニューを表示する直前に、何らかの形で開いているグループを閉じる必要があります。

そのために NSUndoManager をサブクラス化する必要がありますか? または、アクションの前に入力元に戻すグループを閉じる方法を知っている人はいますか?

注: 元に戻すアクションを表示する場合、ファーストレスポンダーは辞任しません。

実際、通常のテキスト入力では、入力グループが何らかの形で開いたままになっているように見えます。元に戻す/やり直しアラートをキャンセルすると、入力を続けることができ、その後すべてのキーストロークをまとめて元に戻すことができるからです。

アクションをグループ化するタイミングと、グループを閉じる必要があるかどうか、いつグループを閉じる必要があるかがわかりません。

更新: 以下が機能していることがわかりました: 開いているグループの数を追跡する NSUndoManager のサブクラスを作成しました。-undo で、例外を回避するために開いているすべてのグループを閉じてから呼び出します[super undo]

段落スタイルの変更など、新しい操作が開始されるたび[self.undoManager closeAllOpenGroups]に、入力の元に戻すグループを閉じる呼び出しを呼び出します。

-deleteBackward:メソッドとメソッドで-insertText:、新しい入力ブロックを開始する必要があることを知っています。

これは余分なコードではありませんが、DTUndoManager の独自のサブクラスを操作する必要がないようにしたかったので、提案をお待ちしています。