(１)エラーをタップしてジャンプするとき、その行が画面に出てこない
これはiOS８のバグだと思います。
エラー行をUITextView:scrollRangeToVisible:というメッセージを使い画面内に入るように画面スクロールさせていますが、このスクロールが途中で止まってしまうことがあります。そうなった時はもう１回タップしてください。たいがいは２回もタップすると表示される範囲にスクロールされます。
(２)エディタの「編集」と「リスト」を切り替えた時、両者の表示位置が一致してない。
基本的にはUITextViewに自由に行スクロールする機能がないことが原因ですが、(１)のバグも一因ではあります。
UITextViewではないエディタモジュールがあればいいのですけど。まあ、エディタの問題は、これからはprogloaderがあるので、外部エディタを使っていただければとm(_ _)m。
（３）fopen()のリターン値がX-BASIC/68と異なる
X-BASIC/68のプログラムを移植した時、fopen()でエラーが出る場合の原因は間違いなくこれです。
iOS版は正常が>=1でエラーが0ですが、/68は正常が>=0でエラーが-1です。
開発時に参照した文献が間違っていたことと、その後テストのために移植したプログラムがリターン値でエラーチェックをしていなかったため発見が遅れ、その間にサンプルでこのリターン値で数多く作ってしまった為、現状そのままになってしまっています。
（４）ファイル名またはディレクトリ名にサロゲートペア文字を入れると正しく処理されない
Objective-Cライブラリの問題であり、表示と違ってめったにありえないことなので対処しないことにしました。おそらく、Mac/iOS上でフォルダの指定を可能にしているほとんどのプログラムが同様の問題を抱えていると思います。
以下は不具合です。すべてV3.10で修正済みです。
（１）改行コードが&h0dのBASICプログラムが読み込めない。
テストしたファイルの中にこれがなかったので確認出来てませんでした。
XcodeというかMac上は&h0aだし、X68/Windowsは&h0d,&h0aなので。 X1で作られたものが&h0dのみでした。
とりあえずの回避方法は、何かしらのプログラムで改行コードを置き換えてください。 たいていのエディタは改行コード指定ができるでしょう。 V3.10で修正済みです。
なお、freads()はちゃんと&h0dに対応しています。
（２）freads()で、最大文字列長を超える文字列を読み込んだ時に落ちる(と思う)
（３）freads()で、EOF(&h1a)を読み込んでも読み取りが終了しない
なので、&h1aの後ろにデータが有った場合、それも読み込んでいた。
(&h1aは単なる１バイトデータとみなされていた。)
（４）freads()で改行なしでファイルが終了する場合のリターン値が/68と異なっていた
「例」TEST&h1aというファイルを読んだ場合
/68 st="TEST",リターン値=-1(エラーが返る)
iOS st="TEST",リターン値=4(読み込めた文字列長が返っていた)
次回のfreads()で-1が返った。
freads()は/68でも細かい仕様が未公開だったので、この際調べたら差異がありました。
（２）UTF16で４バイトになる文字が正常表示できない
これはiOSというかObjective-Cライブラリのバグに近い仕様が原因です。例えば
♣▒🐓🍅
という絵文字群は、UTF16で前２文字が２バイト、後ろ２文字が４バイトです。
（後ろ2文字は環境によっては表示されないかもしれません。）
（Objective-Cの内部文字コードはUTF16です。）
それぞれのlengthを取ると([@"〜" length]）,全て１になるべきが、
| 文字 | length | UTF8 | UTF16 |
| ♣ | 1 | E2 99 A3 | 26 63 |
| ▒ | 1 | E2 96 92 | 25 92 |
| 🐓 | 2 | F0 9F 90 93 | D8 3D DC 13 |
| 🍅 | 2 | F0 9F 8D 85 | D8 3C DF 45 |
これらはサロゲートペアという文字です。サロゲートペアは一部の文字を４バイトに拡張することで扱える文字範囲を拡大したものだそうです。先のlengthやcharacterAtIndex、substringWithRange:NSMakeRange(i, 1)はそれに対応できていません。
このため、それらを使って１文字づつ表示しようとしているX-BASICの内部処理では正常に表示できませんでした。
なお、X-BASIC for iOSのutf8Mid$()など文字列切り出し関数群やutf8Len()は正しく動作しています（これらは独自に開発した処理を使っている）。
（３）font()で等幅でないフォントを指定した時＝全角を含め１文字１桁のとき、幅が広いフォントを表示した時文字が重なってしまう
サロゲートペアで表示される文字の中には、普通の文字に比べ幅広い文字が存在していました。最も幅の広そうなフォントで計算するようにしました。
（４）同指定時、文字を重ねた時に、前の文字の一部が残ることがある。
１文字分の領域幅を消さなければいけないのに、フォントの幅で処理してました。
ただし、縦幅に関してはV3.00で対応したディセンダーの問題でもあるので、width()でディセンダーを有効にすることで対処できます。
→これに関してはV3.10でも完全に修正しきれてません(横方向は直ったけど縦方向が)。(5)の修正を急ぐためです。
（５）RUN直後に落ちることがある
外部関数設定処理に問題があり、ワークを破壊してました。動いていたほうがむしろ奇跡です。次バージョン開発中にこれが顕著になり、散々調べた結果ようやく原因が特定出来ました。malloc()で確保したワーク内の破壊はProfileでもわからないので時間がかかりました。
（６）keyRepeatTime()でリピートなし及び即時リピートの設定ができない
引数の処理に問題がありました。
（７）font()でpointSizeの指定が無視されている
これも引数の処理に問題がありました。常に省略時と同じになってたはずです。
特に（５）が致命的なので、これを直した＋αのV3.10を公開しました。また、fopen()のリターン値もX68に合わせて変更しました。fopen()を使ったプログラムを作成されている方は、ご注意ください(互換モードは用意してあります）。
0 件のコメント:
コメントを投稿