APLNEWS 2007年1月号

 

1.新年にあたり(On the new year)

 

APLNEWSも2005年8月からはじめてから18号目になりました。この間新しいAPLに関してさまざまなことをお伝えしてまいりました。新年を迎えるにあたり今年こそAPLの正しい認識が広まり、C言語やVBAを勉強する時間のない人でも、多少理屈っぽい人であれば、それなりに業務上の、またプライベートなプログラム要求を、楽しみながら短時間で満足させることができることが本当であると理解されることを願っています。(This is the 18th issue since the APLNEWS began in August, 2005. During that time, we have tried to talk to the Japanese audience on very many topics regarding APL. As we face the new year, we pray that it becomes the year when the correct understanding of APL is spread widely and people will experience  APL as really the tool to help individuals with the tendency for logical thinking, but having no time to study C or VBA, to program business problems as well as private ones in reasonably short times.)

 

これまでに出版されているAPLの解説書は(IBMなどベンダーの解説書を除いて)ことごとくAPL言語の文法書であり、そのシステム環境に依存した周辺機能についての記述がなく、APLという非常に生産性の高い、適用範囲の広い、使いこなしやすい、プラグラム作成のための道具である点についての解説ではありませんので、非常に具体性に乏しく、一般の人々の実用的な利用を喚起するものではありません。APLは数値上の実行速度を第一義的に考えられたものではありませんが、プログラム全体の生産性を最重要視して作られたものです。今後ともこの点を考慮しながら、この記事を長く継続できたらと願っています。(Practically all APL related publications (except for those by the vendors) are more or less the grammatical exposition of the language and lacks the description of the system dependent part, which makes the language really productive, adaptive, easy to use tool for programming. Therefore they have failed to arouse public interest to use it for practical applications. APL is not designed for the numerically measured performance. Instead it takes overall programming productivity as the primary consideration. We hope we could continue to talk to you with such considerations.)

 

2.APLとWindowsとの接点(Border between APL and Windows.)

 

APLのもとでのUnicodeによる漢字のサポートがIBMの手により着々と進行しています。2006年4月にIBMより配布されたAPL2V2サービスレベル8(=CSD8)で非常に不思議な現象に遭遇しました。それは私の使用しているノートブック(Epson Endeavor NT900 Pro)でのみ起きる現象で、IBM大和研究所も巻き込んで解明に当たる体制をとりましたが、ほかのパソコンではまったく正常に機能していましたので、それ以上の追求はとりあえず止めました。(Work to officially support Kanji characters under APL2 is progressing by the hands of IBM. While I was testing APL2 V2 service level 8 (=CSD8), released in April, 2006, I experienced, among other things, a phenomenon that I couldnt explain to myself well. This occurred only when I was using my notebook (Epson Endeavor NT900 Pro). Since it didnt occur on other machines I owned, nor any machines on which IBM had tested the same problem, I gave up pursuing it any further then.)

 

11月にサービスレベル9が配布され、前回にもお伝えしましたようにAPLと漢字同時使用のためのFontの問題が解決され、Unicode化がますます現実味を帯びてきました。したがって、今年4月に予定されているサービスレベル10の配布開始までにこの問題を解決しておきたいと考えました。遭遇した問題とはAP145で設計した文字入力画面(Entry FieldやMLEなど)上のカーソルの位置を判定するコマンド(=SELECTION)がまったく見当違いの値を返すことでした。(When the service level 9 (=CSD9) was released last November, I firmly believed that it has cleared most of the difficult problems including that of APL-Kanji font. Therefore I once wanted to bring up the unsolved mysterious problem that I had experienced. The problem was that the AP145 SELECT command for text entry field such as Entry field and MLE returned incorrect values.)

 

この現象を克明に分析した結果、次のことが判明しました。すなわち漢字および一部のAPL文字はUnicodeであるにもかかわらず1文字としてではなく、ASCIIコードの2文字として計算されていることです。1行の入力行で構成されているEntry Fieldの場合はこれのAPLによる修正は簡単です。しかし複数の入力行で構成されるMLE(=Multiple Line Entry)では行を移動するにつれ次第にずれが生じてきてAPLではうまく修正できないことがわかりました。(As I analyzed the problem in detail, I found that the SELECTION command counts kanji and some Unicode APL characters as two characters instead of one. I found that it was easy to correct the problem if it is a one-line entry field, but with the multiple line entry fields (=MLE) the problem was more complicating, because it starts miscounting the character positions as the cursor is moved up and down across lines randomly.)

 

またこのような修正はわたくしのNote Bookを含む1部のPCでのみ発生するものですから、そのようなPCを判別する手段が必要で、あまり意味のあることでだと思われませんでした。したがって今回もう一度大和研究所でこの現象を確認してもらった上で、再度IBMのAPL開発グループに支援を求めました。その結果原因が見つかったようで、その確認のためのコードが送られてきました。(Besides, if the correction logic is found, we still have to have the means to tell the devices, to which the correction is applied or not. Therefore I renewed the abandoned request to look into the problem by the APL development group, after I have obtained confirmation of the phenomenon at IBM Japans Yamato Lab. As a result IBM development seemed to have found the reason and sent me an APL test program.)

 

すなわち下に示すように‘SELECTION’コマンドの代わりにWin32 APIの“SendMessageW”を使ってみてくださいとのことでした。(This sample program used Win32 API SendMessageW command by way of APLs LOAD API and CALL API as shown below)

 

   sv½‘AplGetProperty’ h1 ‘SELECTION’‘’‘EN’

 

   カーソルのポジション½3 4ã½sv

      (Cursor position)

 

  でなく(Instead of using the above, use the code as shown below)

 

   sv½‘AplLoadService’‘SendMessageW’‘User32’

 

   T½sv

 

   sv½‘SendMessageW’ h3 176(AF 4æ)AF 4æ) 

 

   カーソルのポジション½256éã[]AF¨3Çã½sv

      (Cursor position)

 

下記に示す図はIBMから送られてきたテスト・プログラムですが、Unicodeでは倍角の文字と半角の文字とを目で区別をすることが困難でありますが、この場合最後の‘abc’は半角で、そのほかはすべて倍角文字ですから、‘日本語’の後‘a’の文字の位置はASCII文字で判定する‘SELECTIN’コマンドでは27ポジション目ですが、Unicodeで判定する‘SendMessageW’では14になります。(The picture shown below is the sample program which IBM has sent to me. We cannot distinguish by sight between Unicode double-byte alphabet and single-byte alphabets, but the first 13 characters are double-bytes and the last 3 characters (abc) are single-byte. Thus the reading of 14 in Unicode for the third characters from the last is correct, while SELECTION command returns the value of 27.)

 

 

この方式はどのパソコンでも正しい値を返すことがわかり有効な解決法であることが証明しました。IBMは‘SELECTION’コマンドをこの方式で書き換えると約束してくれました。

この時点で彼らはクリスマス休暇に入りましたので、休み明けを待って複数行の場合などについても明らかにしたいと思います。(This method proved to be the right solution, because it worked the same way with my notebook as well as others equally. IBM has committed to fix the problem this way. We are now just waiting till the year-end vacation period is over.)

 

その間、試みにこの方式を複数行の文字入力画面(=MLE)に応用できないか調べてみましたら、次のようなことがわかりました。すなわちAPLでは複数行のデータはこの場合各行可変長の文字列を要素として構成された列(=文字ベクトルのベクトル)ですが、Windowsでは各行の間にCR/LFコード(2バイト)が挿入された一本の文字列として扱われます。したがってポジションnはAPLで読み取ったデータの書く行間にCR/LFを挿入して1本のベクトルに変換した上で、(In the mean time, I wanted to test to see if the solution is adaptable to the case of multiple-line entry fields. I soon found that multiple line data in APL is a vector of character vectors, while Windows treat it as a single string of characters with CR/LF code separating lines. Therefore I have created such windows format data from APL data as shown next.)

 

 sv½‘AplGetProperty’h1‘UNICODE Data’‘’‘MLE’

 

 D½ÇîâǐTC),¨S½3 4ã½sv

 

その左側に何個の(CR/LF)があるのかを勘定すれば(ゼロ・オリジンの値で)行番号がわかります。(From the position value of n obtained by SendMessageW command, the line number value L is easily obtained as follows.)

 

 L½Æ/ÆǐTC)=nÆ

 

また該当行の何番目の文字かと言うことは左側直近のCR/LFまでの長さ(=文字の数)または下に示すように先行行の長さそれぞれに2(=CR/LFの長さ)を加算したものの総合計、

をnから引き算すれば求められます。(And the cursor position P within the line is obtained as follows, or anyway you like.)

 

 P½n−+/0,LÆ2+îæ¨S

 

しかし問題はここから始まります。私が何故このような問題にこだわるかといえば、Unicodeの採用によって、遅かれ早かれAPLが正式に関数の中で漢字をサポートすることになります。しかしAPLを一般に普及させるためにはキーボードのAPLシフトの問題を迂回して、より直接法的にAPL文字も漢字も入力させる方法が望ましいと思います。したがってAPLの初心者向けにこれまでも再三取り上げたソフトキーボードを使用できるようにしておきたいと思いました。(The real problem starts here though. For this I have to explain why I stick to this problem so much. It is now obvious that Kanji is officially supported within APL functions as texts and comments and we will have very good reason to advocate it to revive the popularity of APL at the time when Japanese APL under DOS had created. As we do this we want the beginners to have as little resistance to use APL characters as possible. My software keyboard, which I have shown in previous news from this site will be most direct means of entering APL and Kanji characters visually and directly, without going though complicating APL and Kanji shifting process.)

 

上記の手法によって、ソフトキーボードで選んだ文字をカーソルの位置する場所に埋め込むことは可能になりました。しかしカーソル位置に選んだ文字を一文字だけ書き出す手段はありません。したがって、入力域全体のデータを読み込み、そのデータの該当位置に選択した文字を埋め込んだ後に、データ全体を入力域に書き戻す必要があります。その結果カーソル位置は元の位置から入力域の先頭に移り、元の位置の1文字右側に再設定しなおしする必要があります。(IBM suggested solution helped me to position a character anywhere you like, but since I dont know how to write a single character in a desired location in the input area, I had to read the whole data from the entry field and place the chosen character at the correct position and write the whole data back to the entry field. This moves the cursor at the beginning of the entry field. Therefore we need to reposition the cursor at the new location.)

 

Windowsの画面設計に関して、Visual Basic.NET や Visual C#.NETはAPLのAP145に相当する機能を持っています。コントロール・ボックスに関して両者を比較すると:(VBA.NET as well as C#.NET seem to have correspondent functions to AP145 in regard to Windows dialog box design work. To compare them:)

 

  APL                           .NET    

 

Dialog                         DialogBox

Check box                      CheckBox 

Combo box                      ComboBox

Custom                         ?

Date                           ?

Entry Field                    TextBox

Frame                          PictureBox?

Grid                           ?

Group box                      GroupBox 

List box                       ListBox

Listview                       ?

Menu and menu items            MainMenu

MLE                            TextBox

Month                          ?

Push button                    Botton

Radio button                   RadioButton

Rectangle                      ?

Scroll bar(Horizontal)         HScrollBar

Scroll bar(Vertical)           VScrollbar

Slider                         ?

Spin button                    ?

Tab                            ?

Text                           TextBox?

Time                           ?

Timer                          Timer 

Treeview                       ?

Message Boxes                  MessageBox

Popup Menus                    ContextMenu

FileDialog                     FileDialog

FontDialog                     FontDialog

 

またこれらの各コントロール・ボックスに対するイベントやプロパティーもおなじ Win32APIに基くものと思われます。(This also applies to the resemblance of Events and Properties.)

 

もともとAPLにはLOAD_API、CALL_APIなどの関数があり、さまざまな場面で使用されていますが、それ相当の専門知識を持っているものの作業巣r範囲として残されているものと考えていました。しかしこのようなことがありましたので、APIの資料(=Win32 API オフィシャルリファレンス改定3版、グラフィック・GUI編 ― アスキー出版編)を取り寄せてみました。その結果これがあまりにも膨大な資料で、われわれの手に負えるところでないことがわかりました。しかし休み明けにIBMとのやり取りを再開するまでに、独自にどのような解決が見出せるか是非探りたいと思いました。結果的にはその試みに成功し、Windows XP, Vista RC1で順調に稼動することを確認できました。(I was aware that APL had functions like LOADAPI, CALLAPI and FREEAPI, and that they are being used in IBMs sample demo programs, but I had overlooked them in the past because someone else more specialized in data processing technologies will be using it some day. But I eventually bought a reference book on Win32 API and found it was too much to get something to use immediately. Therefore I resorted to my conventional methods of finding the solution within my knowledge and used both SendMessageW and SELECTION at the same time and succeeded in producing the wanted result.)

 

ただしこの方法はサービスレベル7(=CSD7)まで正常に機能していたように‘SELECTION’コマンドが正しく機能すれば解決するものですから、それまでのつなぎに過ぎません。(However, this solution is only temporary because corrected AP145 SELECTION command should work as it did before, like at the time of service level 7.)

 

関数エディターに関してはIBMが現在のシステム添付の非常に強力なオブジェクト・エディターに漢字のサポートを組み込む見通しができましたが、ソフトウエア・キーボードに関しては現在APLには次のようなものしかありません。

 

 

したがって先に述べた趣旨に沿って、下に示すような従来のソフトウエアー・キーボード付きの関数エディターを継続してサポートしていきます。