2012年10月16日火曜日

Excel 2010:データの入力規則のドロップダウンボタンが消える

図の名前が変わるという話を昨日書いたのですが、そちらはこのことを調べていてたまたま気づいた件でした。

データの入力規則でリストを設定したセルから、ドロップダウンリストの▼ボタンが消えてしまいました。
オプションの「オブジェクトの表示」を「なし」にしているわけではありません。


入力規則を設定した直後から、この▼を「オブジェクトの選択と表示」で追ってみました。
▼は「Drop Down X」の名前で一覧に表示され、他のセルが選択されると非表示のマークに変わります。


名前は一時的につけられるもののようで、ブックを上書き保存しただけでも変わります。上の図では「Drop Down 1」が「Drop Down 2」に変わっています。

おもしろいことに、他のセルに移動して非表示の状態で保存すると「Drop Down」は一覧から消滅してしまいました。 セルに戻ると更新された名前で復活しました。


さて、一覧に表示されていればShapes("Drop Down X").Deleteとやって▼を削除することもできます。
もちろん意図的にそんなことをする理由は思いつきません。ところが実際に見たケースでは他にもオブジェクトが挿入されており、それらをまとめて削除するために以下のようなコードが実行されていました。

Dim shp As Shape
    For Each shp In ActiveSheet.Shapes
        shp.Delete
    Next

「Drop Down」は一覧になければこのFor Eachに引っかかりませんが、あれば引っかかって削除されてしまいます。


問題はその後です。
ブックが.xlsx形式の場合、先の例で見たように上書き保存すればまた「Drop Down」は復活しました。
ところが.xls形式だと上書き保存しても一度閉じてから再度開いても、復活することはありませんでした。それどころか、このシートでは他のセルに入力規則を設定しても▼が表示されなくなってしまいました。同じブック内の他のシートでは問題ありませんでした。

なお、この.xls形式のブックを.xlsx形式で保存し直したところ▼は復活しました。そういう仕様の違いなんでしょうが・・・新旧形式が混在してるとこんなことも起きるんだなぁとびっくりしました。

2012年10月15日月曜日

Excel 2010:2003形式で保存すると図の名前が変わる

知らなかったので。

シート上に図をいくつか挿入したとします。


ここで以下のようなコードを実行してみます。

Dim shp As Shape
    For Each shp In ActiveSheet.Shapes
        Debug.Print shp.Name
    Next

実行結果:


これらの名前は図の挿入時に自動でつけられたものです。

今開いているこのファイルを通常のExcelブック(.xlsx)として保存しても、97-2003形式(.xls)で保存しても上の結果は同じです。ところが97-2003形式の方は、一度閉じて再び開いてから上のコードを実行すると以下のような結果になりました。


.xlsx形式の方は再び開いても元の「Picture ○」のままです。

まぁシート上では名前ボックスにこの「図 ○」という名前が表示されるので、むしろなんで「Picture ○」なんだよという話ですが。もちろん、それぞれの図にあらためて別の名前をつければこのようなことは起こりません。
.xlsx形式と.xls形式はまだまだ混在してるので気をつけたいなと思いました。

2012年10月4日木曜日

Chrome 22:合成用文字による幅の補完(2)

(1)は単なる思いつきだったのですが調べたらけっこう使えそうだったので。

ほんとは三角(U+25E2~U+25E5)がChromeで縮むのをどうにかしたくて調べてました。
ところがただ合成用文字をくっつけるだけだと、Chromeでも合成されてしまって意味がありませんでした。



もっとも、この文字を単独で使うことはあまりないでしょう。違う活用を考えてみました。
下図の上段はU+25E2とU+25E3の間に全角幅の下線記号U+FF3Fを2文字はさみ、IEではコメント全体を全角幅で4文字分にしています。U+FF3FはChromeでも全角幅で表示されます。



Chromeの方は三角の幅が短い分、当然コメント幅が縮みます。

2つのU+FF3Fの間に合成用文字をはさんでみました。下図の例だと合成が起こるIEと起こらないChromeとで、U+0303を使った場合うまく幅が合っているように見えます。



これらの文字はUnicodeのダイアクリティカルマークというブロック(U+0300~U+036F)にあるのですが、こうしてただはさんだだけでIEで合成・Chromeで合成されず、となるのは5文字しかないようでした。


他の文字だとIEでも合成が起こらなかったりしました。
ちなみにこの5つの文字は、コードページ1258(ベトナム語)に定義があるという共通点がありました。他の文字は1250~1258にもCJKコードページにも定義がありませんでした。その意味はわかりませんけどw
せっかく合成用文字はたくさんあるのに、もうちょっとどうにかならないだろうか。

U+FF3FはCJKフォントだと思われますが(ここでIEはSimSun)、他の合成用文字もArialとならIE上で合成が起こります。じゃあゼロ幅のU+200Cに合成させればいいじゃん、と思いつきました。U+200CがArialだろうという話は前に書きました→この日記

下図の3段目・4段目は合成用文字にU+0304を使っています。
そのままU+FF3FではさんでもIEで合成は起こりませんが、U+200Cと組み合わせると合成されました。U+0304のフォント自体変わったように見えます。



結果、U+200CとU+0304を使ったパターンでもChromeと幅が合いました。これなら5文字以外も使えそうです。

さて、これを実際のコメントに使う例を考えます。
下図は三角とU+2587を組み合わせたコメントです。三角を使った行はChromeでは縮んでズレてます。


三角を使った行を上のU+0304を使った形に変えます。もう1つ別のコメントでU+2587の部分を作り、上からかぶせてみます。



IEもChromeも全角幅4文字分のコメントのまま、Chromeの三角部分のズレが修正されました。
三角自体が縮むのはどうしようもないとしても、Chromeで崩れないようにするという意味では実用的と言えるんじゃないでしょうか。
なお、以上の表示はArial Unicode MSの有無には関係ないようでした。またWindows 8でも同じでした。

問題はまたWindows XPです。
IEの方は若干7・8と挙動が異なるものの、上のU+0304のケースについては問題ありませんでした。一方Chromeでは全然ダメでした。


XP+Chrome・・・シェアを考えると諦めるしかないのかなと思いました。

2012年10月1日月曜日

Chrome 22:全角幅の空白文字(2)

Chromeでも全角幅になる空白文字として、(1)でU+3164という文字について書きました。
この文字のネックは、これ自体がGulim化文字だということです。


上の図においてU+2587はGulimに無いため、IEでは幅の短い字形(フォントリンクでMS UI Gothic)に変わっています。U+2588ならGulimの全角の字形になりますが、その場合ChromeではArialの幅の短い字形になってしまうことは言うまでもありません。
また、この文字は8だとSimSun化・MingLiU化で全角幅になりませんでした。

(1)ではU+115A~U+1160というのも調べました。これらはフォント変化文字ではないものの、8やXPで7と同様の表示になるのはGulim化の場合だけでした。
ところが同じ「ハングル字母」というブロックにあるU+11A3~U+11A7という文字が、やはり全角幅の空白でありながらU+115A~U+1160とは少し挙動が違うことに気づきました。


以下、このU+11A3を(1)の時と同じパターンで試したところです。Windows 7ではU+115Aと同じです。



U+115AはWindows 8だとIEでGulim化以外Malgun Gothicになってしまいました。
一方このU+11A3は、そうなるのがゴシックの場合だけでした。



なぜゴシックだけ違うのかは全くわかりませんでした(本来はフォントリンクでGulimのはず)。
とは言え空白を全角幅にしたいのはSimSun・Gulim・MingLiUの場合でしょうから、一応実用的と言えるんじゃないでしょうか。

ただしXPではダメでした。Gulim化の場合にしか使えません。



まぁXPをいつまで考慮すべきなのかという問題ですけど。

追記:
(1)で少し触れましたが、これらの文字はMacでは透明にならないそうです。

 一部のユーザには文字化けしてしまう空白文字 - ニコニコ動画まとめwiki

あらためてご指摘をいただいたので参考まで。

2012年9月26日水曜日

Chrome 22:U+2009による幅の補完

Chromeが22にバージョンアップしました。Flash Playerのことで言えば、組込みのプラグインは古い方のNPAPI(gcswf32.dll)が消え、PPAPI(pepflashplayer.dll)だけになりました。これで完全に移行したということなんでしょうか。自分で試してる環境ではニコニコは一応pepflashplayerでふつうに視聴できています。

それより今日気になったのは、突然の「ニコニコ新バージョン」というニュースでした。
ZeroWatchは本来いいもののはずだと思っています。プレーヤーを再読み込みせずに動画を移動できるのは、画期的な仕様です。しかし重すぎるのとUIの使い勝手が悪すぎたのとで、これだけ不評を買ったんじゃないでしょうか。だからバージョン2的なものが開発されてるんじゃないかと期待してたのですが・・・まさか全然別のものが出てきたりしないですよね?

さて、前回書いた話の続きです。
以前U+2001がフォントによって幅が変わるという話を書きました→この日記
ここでArialとかゴシックとか言っているのはあくまで推測なのですが、とりあえずそういうことにしておきます。U+200Xはゴシックの方がArialより少し幅が広いようです。ところがU+2009だけ、なぜかArialの方が広いことに気づきました。


上の図の空白部分はU+2009を10個並べてあります。
IEでは空白部分に直接接する文字をU+30FB(「ゴシック化」文字)と半角の「a」とで入れ替え、U+2009のフォント状態をそれぞれゴシック(上段)・Arial(下段)に変化させています。ChromeのU+2009はArialだと思われます。
(ゴシック化にカギカッコをつける理由はいつか別の機会に書きたいと思います)
ゴシックとArialの幅の差を、Chromeで縮む幅の補完に使えないだろうか?

シャープ記号のU+266FはIEでゴシック、ChromeではArialで表示されます。文字幅にかなり差があります。


U+266FもU+30FBと同様「ゴシック化」文字なので、これに接したU+2009もIEではゴシックだと考えられます。
これでU+2009をはさんでみたところ、U+2009を20個にしたところで全体のコメント幅に差がなくなりました。



20個も空白文字を並べるのが実用的かっていう疑問はありますがwちなみにWindows 8でも同じでした。
Windows XPでは使えません。XPのArialにU+200Xは無いからです。Lucida Sans Unicodeにはあったので、それが表示されているのかなと思いました。



少なくともArialとは幅が違うようです。

XPはいずれ考慮の必要がなくなるでしょうが、悩ましいのがArial Unicode MSです。
星マークのU+2606はやはりIEとChromeで幅が異なります。こちらではU+2009が7個でコメント幅がそろいました(U+2606に接したU+2009は、IEではやはりゴシックのはずです。説明は長くなるので省きますが)。



ただし上の図でChromeが表示しているU+2606はArial Unicode MSです。Arial Unicode MSが無い場合U+2606はゴシックと同じ字形で表示され、コメント幅がIEより広くなってしまいます。


仮にこの手が使えるとしても、何の文字の調整に使うのかが問題です。
実はArialやその代替に使われる(と自分が勝手に推測している)Lucida Sans Unicodeは、それほど特殊文字を持っていません。Arial Unicode MSで表示されるものがかなり多いです。Arial Unicode MSがどの程度インストールされているものなのか、わかるといいんですが。

2012年9月23日日曜日

Chrome 21:合成用文字による幅の補完(1)

こういう方法もあるかもという話です。
Windows 7で見ただけで、よく検証したわけではありません(XPではたぶん無理?)。

下図は大文字のAの後ろに合成用文字U+0304というのをつけて入力したところです。IEとChromeいずれもU+0304はAに合成されています。形としてはChromeの方が正しいんでしょうか。


これが文字の組み合わせによっては、IEでは合成されるのにChromeでは合成されないケースもあることに気づきました。

下図はその例です。全角の大文字CをU+2587で挟んでいます。CはIEではSimSun化され、Chromeでは何も起こらずゴシックで表示されます。SimSunの全角幅のCに対して、ゴシックのCは少し幅が縮みます。
下段のコメントでは、このCにU+0301という合成用文字をつけています。


IEではCとU+0301は合成され、上下のコメント幅に差はありません。ところがChromeでは合成が起こらず、その分下段のコメント幅が長くなっています。これを利用できないだろうか。
※ちなみにIEではゴシックだった場合も合成は起こります。

下図も上と同様、U+0301をつけた場合とつけない場合とを比較しているところです。


見た目がちょっとアレですけど、あくまでコメント幅の実験なので(^ω^;)下図は2つの図を重ねてみたところ。


U+0301をつけた方はIEとChromeでほぼ同じくらいの幅になりました。

ほんとは特殊文字でこれをやりたかったのですが、豆腐になるものが多くて使えそうな組み合わせを見つけられませんでした。 ただ合成用文字はたくさんあるので、うまいこといく場合もあるのかもしれません。

2012年9月18日火曜日

Excel 2010:未登録のアドインもカウント

VBAのコードを書いたブックをアドイン形式(.xlam)にする場合があります。
メリットとしてはシートをユーザーが表示できないという点です。.xlsm形式で全てのシートをxlSheetVeryHiddenにするということはできません。また、ウィンドウを非表示にしてもユーザーが再表示できてしまいます。
ただし.xlam形式だとちょっと不便な時もあります。

今、.xlam形式と.xlsm形式のファイルを1つずつ開いているとします。


ここで以下のようなコードを実行するとxlsmの方だけが捕捉されます。

Dim wb As Workbook
    For Each wb In Application.Workbooks
        Debug.Print wb.Name
    Next


Workbooks.Countは1です。.xlamもWorkbooksで直接名前を指定すると捕まえられるので、いまいち腑に落ちないんですが。


WorkbooksがダメならAddinsかと思うと、こちらは登録されているアドインだけが対象です。ただ開いただけの.xlamは無視されてしまいます。Addins.Countは5です。

Dim A As AddIn
    For Each A In Application.AddIns
        Debug.Print A.Name
    Next



最近になって気づいたのですが、いつの間にかAddins2というコレクションがありました。どうも2010で追加されていたようです。

<参考>New Objects, Collections, and Enumerations_Excel.Dev - MSDN

これだと未登録の.xlamでも開いていれば対象にするらしい。

Dim A As AddIn
    For Each A In Application.AddIns2
        Debug.Print A.Name
    Next


Addins2.Countは6でした。

2003では拡張子の区別がなく、.xlsのままIsAddinをTrueにするなんてこともやりました(いい使い方ではないと思います)。その時に、このFor EachやCountで困ったことがありました。2003でこれがあったら助かったんですけど。
それにしてもこういうのが新たに追加されたということは、.xlamを普通のブックのようにただ開かせるという使い方もけっこうあるんですかね。