HOME     メール  

Links:

最近の投稿

カテゴリー

広告

サイト内検索

外部リンク

アーカイブ

広告

お知らせ

ATLを使わないWTLもどき ver1.1リリース

正式名称Natsuhaze Windows Class Library

ActiveXコントロールに対応しました。ダイアログ上で比較的簡単に使えるかと思います。
これはEternal WindowsというサイトのFlashコントロールを使ったサンプルコードを改変して実現したものです。(サイト管理者に許諾は取ってあります)。この場を借りてEternal Windowsの管理者に御礼申し上げます。

ダウンロードは左側のリンクからお願いします。

サンプルプロジェクトには、Webブラウザコントロールを使ったサンプルコードが同梱されています。

その他の変更点
2012 8/31 ver1.10 8/31 nwclcom.hの追加。ActiveXコントロール使用可能

1.02 8/9
DDX_UpdateData,DDX_var<>::UpdateData()を追加。ダイアログのメッセージハンドラ内のデータ交換関数の値の更新は、値の代入のときのみ行われるため、MFCと同じようなものが必要と思い追加MFCのUpdateData(TRUE)と同じ意味である

1.01 7/23
virtual int CDialog::OnOk(),OnCancel()を追加。それにともない#define COMMAND_OnOk(handler),COMMAND_OnCancel(handler)は廃止。やはりデフォルト処理は仮想関数があると便利
CPropertyPage::OnApply()を追加 返り値が特殊なので1が成功を表す仕様にした
class CComboBoxExの追加
CPropertySheet::DoModal()の返り値を::PropertySheet()の返り値をそのまま返すのではなくCDialog::DoModal()の返り値に合わせた
プロパティページ専用ハンドラ生成マクロ( PPH_WIZNEXTなど )を設けた

WTLでもActiveXコントロールの利用はできるのですが、ソースコードを見ると、汎用化されなくてActiveXなら何でも簡単に使えるようには見えませんでした。何度も別のCLSIDでインスタンス作成を試みているコードがあったからです。

しかし、今回新たに作ったものは汎用性のあるもので、ユーザがCLSIDやインターフェイスIDを知っていれば簡単に実装できます。サンプルプロジェクトでWebブラウザコントロールを使った例がありますので参照してください。

まあ、今となってはActiveXコントロールはあまり使わないのでしょうが、WebブラウザやFlash,PDF表示用コントロールがあるので完全に廃れるわけではないでしょう。
 それにActiveXコントロールは基本的にVisualBasicなどのお手軽開発言語用のコントロールなのでC++で上記の有名なアプリケーション以外は使われないでしょう。COMをベースとしているので非常に難解ですし、EternalWindowsがなければ実現できませんでしたね。

COMはほとんど呪文の固まりのような仕様で、MSDNのリファレンスやSDKのサンプルだけではちんぷんかんぷんです。MicrosoftはWindows開発のために、これを今でも拡充しています。仕様は難解でも拡張性が高い、具体的にはWin32APIのように、引数の追加をした関数を新規に作るという、無理な増改築のようなやり方をせずに済んでしまうのが良いのでしょう。
 つまり基本仕様を変えずにいくらでも拡張できているわけです。これはMicrosoftにとって二重の利点になります。実装部分を隠した、わかりづらい仕様なので自分たちの以外のメーカーには、より気の利いたアプリケーションが作成できなくなる、仕様を実質的に隠蔽できたうえで、拡張ができるわけです。

COMの仕様はIntelのUSBやPCI Exressを想起させます。つまり、引数(バス)は最小限にして拡張性を持たせた規格と言うことです。インターフェイスポインタの取得など、ワカサギ釣りのようです。

MicrosoftはMSDNなどで公開しているAPIのリファレンスは全て実際に動くサンプルコードを添付すべきでしょう。WinMain()や#include分も記述された完璧に動くコードです。自然言語と同じく、言葉の説明を詳細に説明するより実際に使う文が重要なのです。
しかしこれは自分たちの優位性を保つためにそうすることはないでしょう。

Apple同様Microsoftも自分たちの認める世界でしか動かないアプリケーションのみ認める傾向にありますから、自分たちの望まないカスタマイズを施したアプリケーションは気に入らないのです。これは、別にユーティリティーソフトの開発だけではない問題で、業務用アプリケーションの開発でも支障が出るものです。
 具体的には自分たちの指定したユーザインターフェイスに叶ったアプリケーションしか開発できないよう仕向けているため、Microsoftの意向で以前とは全く違うユーザインターフェイスを強要されることで、コンピュータの操作に疎い業務用ソフトしか使わないユーザが不便を被るのです。これはもうすぐ発売されるWindows8やその中で使われるユーザインターフェイスで誰もがわかることです。

だからこそこのライブラリの必要性が出てくるのです。NwclはこのようなMicrosoftの移り気なところをできるだけ回避できるライブラリです。まず、Win32やcomという.NETより遙かにWindowsの中枢を担うAPIを直接使うことで、長期間にわたってソースコードを変更する必要が無くなります。もし、VisualStudioのMFCなどのライブラリや機能を使っていたら、毎回最新版を買わざるをいけない状況に陥り、かつユーザインターフェイスも変えなくてはならないようになってしまいます。開発者はMicrosoftに翻弄されているのです。