2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

最近のトラックバック

無料ブログはココログ

2017年1月22日 (日)

OuDia Ver.1.02.05 を公開しました

  OuDia Ver.1.02.05 を公開しました。
変更点は、以下のバグ修正のみです。

  • 列車種別ビューで、[編集]-[上へ]・[編集]-[下へ]を行うと、アプリケーションエラーになる問題を修正

問題箇所の修正は、ほんの数行でした。
しかし、こういう小修正の場合は、ソフトをWebに公開するまでの手間が高くつきます。
今回のリリースの場合は特に、前回のリリースとは年が変わります。このため、著作権表示の年を-2016 から -2017 に変える必要がありました。この、著作権表示を持つファイルが、結構多いのです。

  • ソース .zip に含まれるReadMe.txt
  • すべてのソースファイル
  • すべてのマニュアルの .html ファイル
  • マニュアルの「この文書の著作権表示 」
  • バージョンリソース(バージョン情報ダイアログボックス)
  • インストーラのプロパティ(インストール後に、コントロールパネルに表示される)
  • インストーラの開始時に表示される、使用許諾契約書

この、ソフトの動作に関係の無い修正点の多さは何とかならないものか・・・と思ってしまいました。

2016年11月24日 (木)

時刻表ビューをPDFファイルへ出力すると、そのPDFでは時刻表の罫線が見えない-2

「PDF出力の場合だけ時刻表の罫線が見えなくなる」という問題の原因を思いつくまでには、時間がかかりました。
原因は、「アプリケーションソフトから長方形を描画したとき、出力先がPDFだと、他の出力先(ディスプレーやプリンター)に比べて、長方形のサイズが大きくなる」ということでした。(ここでの『出力先』は、Windows GDI を指します)。

時刻表ビューをはじめとした「グリッド形式ビュー」は、以下の順序で描画を行っています。

1.グリッドの罫線を描画する
2.各セルに、背景色で長方形を描画する
3.セル内のテキストを描画する

出力先がPDFの場合、2.の処理において描画する長方形が大きく、罫線に乗り上げてしまいます。このため、罫線が覆われて見えなくなってしまうのです。

oudia_1.01.02_pdf

この問題の解決策は、以下のように描画の順番を変えることしか思いつきませんでした。

1.各セルに、背景色で長方形を描画する
2.セル内のテキストを描画する
3.グリッドの罫線を描画する

しかし、これは、結合セルがある場合に、少々面倒な処理が必要になりました。今までは、罫線の後にセルの背景やテキストを描画していたため、結合セルの上を通る罫線は、結合セルの背景色に塗りつぶされて見えなくなっていました。しかし、罫線をセルの後に描画するとなると、結合セルの上に罫線が重なってしまいます。

このため、罫線を描画する処理に、結合セルを避けて線を引くような仕組みを追加しました。

こうして何とか、PDFへの時刻表ビューの出力を改善することができました。

oudia_1.01.03_pdf

2016年11月19日 (土)

Windows10では、時刻表ビューの縦書き表示が正しく表示されない問題

2016日6月26日の記事でお話しましたとおり、Windows10では、OuDiaの時刻表ビューの縦書き表示が正しく表示されません。

  • 縦書きセル中の横書き半角数字が、正しい位置に表示されず、真下の文字と重なる
  • 縦書きのセルの高さが、今までの2倍ほどの大きさになる

Windows10_2

  Widnows10では他にも問題があったので、僕のPCはWindows7に戻してしまいました。このため、この問題を再現させることができなくなりました。

そこで、Windows10の動くPCを借りてきて、リモートデバッグで原因調査をすることにしました。リモートデバッグを使うことにより、Windows10上でOuDiaを動作させて、その動作をWindows7のデバッガーで解析することができます。

その結果明らかになった原因は、

Windows7とWindows10とでは、GetTextMetrics() 関数によって得られる TEXTMETRIC::tmMaxCharWidth  の値が異なる。

ということでした。 "@MS ゴシック" の9ポイントのフォントの場合、TEXTMETRIC::tmMaxCharWidth の値は、

  • Windows7では 13
  • Windows10 では 24

となります。
OuDiaの時刻表ビューは、TEXTMETRIC::tmMaxCharWidth  を使って、縦書きセルの高さや、文字の位置を計算しています。このため、Windows7 と Windows10 とで、時刻表ビューの表示が全く違ってしまうのです。

文字の高さを示す TEXTMETRIC::tmHeight は、Windows7、Windows10 のどちらでも12 です。Windows10の返す 24 という値は、一般的な文字を考えると、おかしな値です。高さ12ピクセル・幅24ピクセルの文字とは、一体どんな文字のことなのでしょう?

というわけで、縦書きセルの描画は、OSの違いの影響を受けない TEXTMETRIC::tmHeight を使って行うことにしました。

Windows10_161119

この変更を行ったOuDiaは、なるべく早くリリースしたいと思います。

2016年8月28日 (日)

OuDiaのホームページは移転しました

本年2月にご案内したとおり、OuDiaのホームページは、移転しました。

http://take-okm.a.la9.jp/oudia/

本年2月にも記しましたとおり、これまで利用していた @nifty の『@homepage』サービスが終了することになったためです。

http://oudiary.cocolog-nifty.com/blog/2016/02/oudia-adfc.html

移転先では当初、CGIがうまく動かなくて苦労しました。OuDiaのホームページでは、ファイルのダウンロード回数を数えるのにPerlによるCGIを使っています。しかし、いまではPerlを使う機会が全く無くなったため、うまく動かないときの問題の切り分け方法が思い出せなくなっていました。CGIは2006年に作り、2014年に一度手直ししただけですので。

2005年ごろには、動的なWebサイトを作る方法としてPerlのCGIは良く使われていましたが、今ではあまり使われなくなったようですね。本屋での入門書が昔よりも減ったことが、これを示していると思います。

もっとも、入門書が減って新規の習得が難しくなっているという傾向は、OuDiaで使用しているMFCにも顕著です。今後、OuDiaのソースコードが読める人間はどんどん減っていくと思われます。そろそろ、より現代的な言語・フレームワークによって作り直された、新たなダイヤグラムソフトの出現が待たれるようになってきています。

2016年8月27日 (土)

Visual Studio 2015 でビルドしたOuDiaは正しく動作しない

Visual Studio 2015 を使用してOuDiaをビルドしてみましたが、これが正しく動作しません。

正常にビルドされたOuDiaでは、ファイルを開いた直後は、作業領域にはウインドウが1つも無い状態になります。
ところが、Visual Studio 2015 でビルドされた OuDia では、ファイルを開いた直後、作業領域に白一色のウインドウが表示されます。また、いくつかのビューを開いたり閉じたりしているうちに、アプリケーションエラーになることもあります。

少し調べてみたところ、以下のメンバ関数が動作していないことが分かりました。

CDocument* OuMfc::HideMdi::CHidemdiRootDoctmpl::
    OpenDocumentFile(
        LPCTSTR lpszPathName
        , BOOL bMakeVisible )

この関数は、CMultiDocTemplate::OpenDocumentFile() をオーバーライドすることによって動作します。しかし、Visual Studio 2015 に添付されているMFCでは、この関数の引数が以下のように変わっているようです。

    ◎VisualStudio 2008
    CDocument* CMultiDocTemplate::OpenDocumentFile(
        LPCTSTR lpszPathName,BOOL bMakeVisible)

    ◎VisualStudio 2015
    CDocument* CMultiDocTemplate::OpenDocumentFile(
        LPCTSTR lpszPathName, BOOL bAddToMRU, BOOL bMakeVisible)

CMultiDocTemplate::OpenDocumentFile() は、MSDNで文書化されていないメンバー関数です。非公開の関数は、ライブラリのバージョンアップ時に、仕様が突然変更されるケースがあります。そういうものを使用していると、こういうことも起こってしまいます。

2016年8月21日 (日)

Visual Studio Community 2015 をインストール

現在、Visual Studio Community 2015 をダウンロード・インストール中です。Visual Studio Community は無償の開発ツールであり、従来あった無料の Visual Studio Express Edition の後継ソフトにあたります。

現在公開されているOuDia は、Visual Studio 2008 Professional Edition でビルドされていますが、これは有償のツールです。購入価格はすでに忘れてしまっていましたが、ネットで調べてみたところ、29800円でした。有料とはいっても、個人でも手が届く値段です。

Visual Studio 2008 にも、無料のExpress Edition はありましたが、これには MFC が添付されていません。このため、MFCを使用しているOuDiaは、無料のExpress Edition ではビルドできませんでした。

ところが、Visual Studio Community 2015 は、無償版なのに、MFCが添付されているとのこと。このため、無償の開発環境でOuDiaのビルドができるわけです。ならば、乗り換えを検討する価値は大です。

と、そんなことを考えているうちに、ダウンロード・インストールは完了しました。ダウンロード・インストールには、ADSLで2時間40分ほどかかりました。
  その後更にWindowsの再起動があり、初回起動時にはマイクロアカウントのサインインも必要です。結局、Visual Studio Community 2015 を起動するまでには3時間ほどかかりました。

早速起動し、簡単なMFCアプリケーションを作成してみましたが、ここで問題に気づきました。

Visual Studio Community 2015には、インストーラパッケージ(oudia.1.02.03.msi) を作成するための『セットアップ プロジェクト』の機能がありません。MSDNを検索してみたところ、「InstallShield Limited Edition は、Visual Studio ではサポートされなくなった Windows Installer テクノロジを置き換えます。」とあります。「InstallShield Limited Edition」というのは、Visual Studio の拡張機能、いわゆるアドオンです。

https://msdn.microsoft.com/ja-jp/library/dn531020.aspx

それならばと 「InstallShield Limited Edition」 を検索してみたところ、ここには「Visual Studio Community Edition is not supported.」とあります。

http://learn.flexerasoftware.com/content/IS-EVAL-InstallShield-Limited-Edition-Visual-Studio   

これ以外には、「Microsoft Visual Studio 2015 Installer Projects」というアドオンもあるようです。

https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300-40a7-8797-c509fb8933b9?SRC=VSIDE

とりあえずはこれを試してみようと思います。しかしおそらく、ビルドしただけでインストーラパッケージが完成するというわけにはいかず、いろいろ再設定が必要ではないかと思います。

2016年6月18日 (土)

エンベデッドシステムスペシャリスト試験に合格

今年の4月に、エンベデッドシステムスペシャリスト試験  を受験しました。昨日 6/17 にその合格発表がありまして、合格していました。試験は午前Ⅰ・午前Ⅱ・午後Ⅰ・午後Ⅱの4つの時間帯から成り、その全てで60点以上をとれば合格なのですが、午後Ⅰは65点と、合格点ぎりぎりでした。

エンベデッドシステムスペシャリストは昨年も受けておりますが、昨年は午前Ⅰで不合格でした。午前Ⅰは、エンベデッドシステム固有のものではなく、情報処理技術全般を出題範囲としたマークシート式問題、いわゆる一般教養問題です。これで不合格というのは情けないものでした。
これに懲りて今回は、試験前に一般教養のテキストを繰り返し眺めるようにしたところ、一気に合格することができました。

午後Ⅰ・午後Ⅱは、仮の組み込み機器を題材にした、タスク設計に関する問題がほとんどです。午後Ⅰ・午後Ⅱともに記述式ですが、午後Ⅰは90分で2問に解答、午後Ⅱは120分で1問に解答となっています。

午後Ⅰ試験は時間にゆとりがなく、素早く答えを出さないと、時間が足りなくなります。通常こういう試験では、自己採点用に、自分の答えをメモに控えておきたいものです。しかし、午後Ⅰ試験にはそんな余裕はとてもなく、直接答案用紙にどんどん答えを書いていかないと間に合いません。

午後Ⅱ試験は。時間にはゆとりがあります。しかし、テーマとなる機器の仕様に関する説明が細かい文字で7,8ページもあり、まずそれを理解するのが大変です。設問も熟考を要するもの、熟考しても答えが浮かばないものもあります。

午後Ⅰ・午後Ⅱとも記述式ですが、午後Ⅰはマージャン型思考、午後Ⅱは将棋型思考を問う問題なのかと思います。

幸い、試験内容が日頃の仕事に近い内容だったため、特別な受験勉強はしなくても、合格することができました。学習は、仕事帰りの電車の中でテキストを見る程度でした。

組み込みソフト開発の現場で、普通に設計思想を持ってシステム開発を継続している人にとっては、それほど苦労せずに合格できる資格試験なのだと思いました。

2016年6月16日 (木)

自作ライブラリの管理方法の見直し

 

現在、自作ライブラリの管理方法を再考しています。

OuDiaのソースツリーは、ルートディレクトリ付近で、『DiagramEdit』と『libs』に分かれています。
『DiagramEdit』は、OuDiaに固有のプログラムを収録したディレクトリです。一方の『libs』は、OuDiaでなくても使えそうなプログラムを収録しています。

例えば、時刻表ビューなら、「グリッド形式ビュー」という仕組みを実現しているのは『libs』の中の『DcDrawLib::DcdGrid::WndDcdGrid3』というクラスです。そして、その「グリッド形式ビュー」という仕組みを使って、OuDia固有の『時刻表ビュー』を実現しているのが、『ViewJikokuhyou::WndJikokuhyou::CWndJikokuhyou』クラスです。

現在、これらのプログラムソースファイルを、まとめてSubVersionでバージョン管理しています。

しかしながら、これら『libs』のコードの保存形態について改めて考えると、以下のような問題点が出てきました。

1.今となっては陳腐化したライブラリを保存し続けるべきか?
2.ライブラリをビルドするためのプロジェクトファイルを管理するべきか?
3.ライブラリにプリコンパイルヘッダは必要か?

現在は、これについて色々と考えているところです。この結果、OuDiaのソースツリーは、今後変化することが見込まれます。

2016年1月24日 (日)

UML作図ツール.astah* community を試用

OuDia開発は、14/08/03 のリリースからずいぶん間が空いてしまいました。会社勤めの身では、OuDiaを開発できるのは土・日曜に限られます。2日間では、ちょっとした修正を考えることはできても、大きな構想を考えることは難しいです。

大きな構想を考えられるのは、盆・正月などの長休みに限られます。今年の正月休みは、ひさしぶりにOuDiaの設計図面を見直しました。

ここで、設計図面の作図ツールが古くなっていたことを改めて思い返しました。僕は、2004年ごろから、ソフトウエアのUMLの設計図面を、Dynamic Draw(http://www.dynamicdraw.com/jp/) というドローツールで作成してきました。
2004年当時においても、UML作図ツールとしては、有償の Microsoft Visio のほか、海外製のフリーのUMLツールもありました。そのなかで Dynamic Draw を採用した理由は、

  • テンプレートによるUML図面をサポート
  • 無料
  • 日本製で、日本語によるヘルプが充実している

といったことでした。
しかしその後、 Dynamic Draw は何度かバージョンアップされました。その結果、操作感が変わってきました。このため、もっと便利なUML作図ツールがないものかと思うようになっていました。

そこで、正月休みに改めて、UML作図ツールを探して、いろいろ試してみました。

この中で、astah が日本製・軽快で使いやすいと感じました。そこで、既存の設計図面を、astah community で書き直してみました。かなり楽に書き直すことができたので、Dynamic Drawからとりあえず、astah community に乗り換えたいと思っています。

  特にうれしかったのは、用紙サイズの制約なしに、自由にUML図面の要素を配置できること。Dynamic Draw や Visioのような「汎用のドローツールで、UML図面の作図もサポートする」というものでは、UMLの図要素や、要素間の関連線を、用紙内にうまく配置することに常に気を遣わされました。

また、UMLの中でもシーケンス図は、複雑な形状の図形を微妙に配置する必要があります。汎用のドローツールでは、図形が複雑になれば作成の手間がかかるのは当たり前のことです。 Dynamic Drawはテンプレートを使ってこの作図を楽にしようとしてはいましたが、それでも操作は複雑でした。しかし、 astah のシーケンス図作成機能は、UMLのシーケンス図を作成するという目的に特化した分、作図が非常に楽でした。

astah community は、astah のシリーズの中での無料版で、機能が制限されています。また、商用目的での利用ができないことになっています。上位の有償版として astah UML があり、これはいくつかの機能制限が解除されます。astah UML のライセンスは年間5000円と、ウイルス対策ソフト程度の値段です。

無料版の astah community でも一応、UML設計図面を一通り作成できます。しかし、ファイル間でUML要素(クラスアイコンなど)や図面をコピー・ペーストする機能は、有償の astah UML でないと出来ません。これは残念でした。

とはいえ、年間5000円なら、個人でも払えない金額ではありません。もう少し無料版を使ってみて、必要を感じたら、有償版の導入も考えたいと思います。

2014年8月 3日 (日)

OuDia Ver.1.02.02 を公開しました

  2014年8月3日の午前5時頃、OuDia Ver.1.02.02 を公開しました。 ほぼ2年ぶりのバージョンアップとなります。

変更点は、以下のとおりです。

  1. 駅ビュー・列車種別ビュー・時刻表ビューにおいて、セルのランダム選択ができるようになりました

  2. 『駅のプロパティ』・『列車種別のプロパティ』・『列車のプロパティ』・『駅時刻のプロパティ』ダイアログが、セルの複数選択時に使用できるようになりました。

  3. 駅ビューのメニューコマンド[駅時刻]-[直通化]の仕様を変更しました

  4. 駅ビュー・列車種別ビュー・時刻表ビュー・ダイヤグラムビューにて、&の入った文字列が正しく表示されない問題を修正

1.と2.は、2011年1月から構想し続けていた「複数選択・プロパティ設定」がようやく完成したものです。この機能の検討過程については、このブログでも何度かお伝えしてきました。

結局、構想開始から公開までは3年半もかかってしまいました。「複数選択・プロパティ設定」をサポートするダイアログボックスの動作は、考えていた以上に複雑で面倒でした。

4.は、 & の入った駅名や列車名が正しく表示されずに、アンダーライン表示になる問題を修正したものです。今までのOuDiaでは、駅名に "123&4" と入力すると、駅ビュー・時刻表ビュー・ダイヤグラムビューでは、この駅名が "1234" と表示されていました。英語圏では、名前に & を含む駅名が結構あります。この不具合は、そういう国のダイヤを入力する際に顕在化していました。
修正後のOuDiaでは、駅名に "123&4" と入力すると、時刻表ビュー等でも正しく "123&4" と表示されるようになりました。

Win32APIでWindowsアプリケーションを作成する力のある人なら、すでにピンときていると思います。この、「&の次の文字にアンダーラインを表示する」という動作は、DrawText() 関数 の仕様に起因しています。DrawText()関数では、この「&の次の文字にアンダーラインを表示する」という動作がデフォルトになっていて、この動作を止めさせるためには明示的に DT_NOPREFIX オプションを指定する必要があります。これまでは、この指定を明示的にしていませんでしたが、今回の修正からは、OuDiaとしては DT_NOPREFIX オプションを常時指定することにしました。

とはいえ、もしかしたら、プログラミングの知識があって勘の鋭いユーザーの中には、このアンダーライン表示を積極的に利用していた人もいるかもしれません。今回の修正によって、そのような使い方はできなくなりますので、そのような使い方をされていたスーパーユーザーの方々(1%もいないと思います)へは、御免なさいと申し上げるしかありません。