Double-talk Publisher

鉛筆で印刷するプリンター

へぇ。これはなかなか良いアイデアだ。印刷物が消しゴムで消せるってのは新たな体験だろうな。

大抵のプログラミング言語には、エラーを検出し、例外処理を行う仕組みが用意されています。JavaScriptであれば「try〜catch文」がそれにあたります。基本的には以下のように使います。

try{
	//こなしたい処理
}catch( e ){
	//例外処理（エラー）
}

このように、通常はエラーが出ないことを期待しつつ、万が一のため、catchに例外処理（エラー）を用意しておくといった使い方をしますが、以下で説明するような「打たせて取る」といった使い方も有用です。例えば、あるスウォッチ名がそのドキュメントに存在するかを調べるときがそうです。

まずその前に、同じことをtry〜catch文を使わない「きまじめなコード」で考えてみましょう。

//きまじめな見本
function existsColor(cName){
	var i;
	var cntColors= app.activeDocument.swatches.length;
	for (i=0;i<cntColors;i++){
		if(app.activeDocument.swatches.item(i).name===cName){return true;} //あったのでtrueを返す（関数を抜ける）
	}
	return false; //なかった
}

var res=existsColor('C=100 M=0 Y=0 K=0');
alert(res);

上のコードは指定されたスウォッチ名をドキュメントにある全てのスウォッチ名と比較して結果を返しています。処理の特性上、恐らくこのような関数化も必要になってくるでしょう（もしくは無名関数＋if文など）。

このような処理が必要な場合もありますが、単にスウォッチの有無を調べエラーを弾くだけなら、try〜catch文で以下のように処理することも可能です。

//打たせて取る見本
//ここにさしかかった段階でcNameには（'C=100 M=0 Y=0 K=0'）などの値が入っているものとする
try {
	//エラーが出るか出ないかが知りたいだけで、何か処理するわけではない
	//コード自体は「cNameという名のスウォッチの名前を知る」というナンセンスなコード
	var dummyStr= app.activeDocument.swatches.item(cName).name;
} catch (err){
	alert('NotFound');
}

このナンセンスコードがそのまま通れば、そのスウォッチ名が存在することになり、エラーが出たら存在しないということになります。

とにかく打たせてエラーが出たら取る。try〜catch文はそういう使い方もアリなのです。

「ESTKのキー入力がうまくいかない」
「Adobe系のアプリで入力が追いつかない」
そのような話を小耳にはさみつつ、自らの問題がオーバーラップ。

「ATOKの入力モード変換が追いつかない」んです。

例えば「欧文モード」にいて「かなモード」に変更して「満足」と打とうとします。その時タイミングが悪いと「manぞく」＞「つい勢いで確定」＞「man族」などと打たれてしまいます。

そう、IMとOSの同期がとれていないんですよ。バッファエラーで間がおかしなことになるならいざしらず、のっけの入力が飛ばされたりするなんて今まで出会ったことはありませんが、10.6にしてから頻繁にこれが起こります。

ふと、直感的に「非同期の割り込み処理がどうにかなってるんじゃないか」と思ったんですが、そこで気になるのが「Grand Central Dispatch」。

これはなんでもかんでもお構いなしにタスクを切り裂いて、とにかく早く多数のスレッドを処理してしまおうという技術なわけですが、これにIMが同期していないのではないかという気がします。IMだけでなく、CLさんのIllusutratorの例もそうかもしれません。

入力が追いつかないのではなく、入力フィルタールーチンがしのごのしている間に、キー入力が非同期で先に処理されているのではないでしょうか。本来、こういうものは同期処理されるように設計されるはずですが、何分、OSの登場のほうが遅かったので今はこうなっちゃってる、と。

もしかして、Grand Central Dispatchが入力関係のトラブルの原因か？