画面のハードコピー No3

キーエミュレーションで、
「ALT + PrintScreen」が動作しない理由は、
Windows7の問題かもしれません。

Win7になってから、
ＨＴＡなどからエクセルアプリケーションなどを呼び出すと、
呼び出されたエクセルにフォーカスが当たりません。

呼び出したＨＴＡなどにフォーカスが残ったままになるんです。

なので、ショートカットキーでＶＢＳを起動した時点で、
元々ハードコピーを取りたかったアプリケーションのアクティブウインドからフォーカスが外れ、
ＶＢＳにフォーカスが移動しますが、ＶＢＳ自体はウインドウを持っていないので、
デスクトップ上にアクティブなウインドウが無くなってしまって、
コピー対象が無くなってしまいます。

場合によっては、タスクバーにフォーカスが当たってて、
タスクバーだけが印刷されてくることもあります。
その印刷結果は、パッと見ただけでは訳のわからないものになってしまってます。

画面のハードコピー No2

画面全体のハードコピーをプリントアウトするのは結構簡単にできました。

そうなると欲がでてきます。

最近のモニターは大画面なので、
フツーにハードコピーを出力したら、見たい部分がすごく小さい場合があります。

そこで、アクティブウインドのみを出力する方法がないか考えました。

クリップボードにコピーするなら、
全画面は「PrintScreen」キーだけ、
アクティブウインドは「ALT + PrintScreen」なので、
エクセルのＶＢＡで、キーのエミュレーションを重ねればいいと思います。

キーをエミュレーションする場合は、
そのキーのコードと、キーを「押す」と「離す」の動作を組み合わせますので、
「ALT」をキーダウン
「PrintScreen」をキーダウン
「PrintScreen」をキーアップ
「ALT」をキーアップ
の順にエミュレートさせれば簡単やん。

で、早速改良してみたら動きません。
なんでじゃ？

画面のハードコピー No1

簡単な資料や、引き継ぎ書などを作る時に、画面のハードコピーが簡単にプリントアウトできたら便利ですよね。

フリーのツールは探せばいくらでもあります。

でも、うちの会社はフリーを使うには申請が必要なので、邪魔くさいです。

そこで、自分で作りました。
まあ、実際には作るよりフリーの利用申請をするほうがよっぽど早くて楽ですけどね。
これも練習です。

技術的な参考はネットにいくらでもあります。

私は、エクセルのＶＢＡを使って、WIN32APIを呼び出して使ってます。
ちょっとした細工で、エクセルをそのまま起動するのではなく、
ＶＢＳからエクセルオブジェクトを非表示で呼び出してます。
そうするとちょっとかっこいい。

さらに、そのＶＢＳのショートカットをデスクトップに置いて、
ショートカットの「ショートカットキー」に「CTRL + ALT + P」とかに設定すれば、
印刷したい画面が表示されている状態で、「CTRL + ALT + P」を押せば、
そのままのイメージで出力されます。

かなり便利です。

ＶＢＡはAPIを呼び出せますが、
ＶＢＳは呼び出せないんです。
これを合わせ技で解消しています。

オラクルをSQLserverに繋ぐ No1

Oracleデータベースは素人には難しいです。

SQLSeverなら、Expressが簡単に導入できるし、SSMS(SQL Server Management Studio)が一緒にインストールされるので、素人でも比較的簡単に運用できます。

でも、業界標準はOracleの勝ちです。
なので、ベンダーで作成されてくるシステムはほとんどOracleベースです。

これをなんとか自分の土俵に持ってきたい。

そこで、SQLServerのリンクサーバー機能を利用してOracleを接続してしまいました。
これだと、ほとんどOracleであることを気にせずにデータの利用ができます。
SQLServerに MicroSoft Oracle ODBC ドライバが用意されていますので、意外と簡単に接続できました。

一旦リンクサーバーの設定が完了すれば、扱いはほとんどSQLServer上の他の純正データベースと同様になります。

Hyper-Vのシャットダウン No1

Windows Server 2008 r2 上に Hyper-V で Windows 7 を立てています。
Server は毎晩シャットダウンします。

翌朝、Serverがエラーを吐きます。
ディスクにエラーがあると。

ホストOS(Server2008)をシャットダウンする前には、必ずゲストOS(Windows 7)をシャットダウンする必要があるのかな？

IIS 7 のアプリケーションIDってなんや？ No5

ちょっと間違ってたかもしれません。

アプリのアプリケーションプールの詳細設定にある、「アプリケーションID」を、

「ApplicationPoolIdentity」から、
「LocalSystem」に変更した。

と書きましたが、
色々試してみたところ、「NetWorkService」でも、
通常使うプリンター以外のプリンターへのアクセスが可能なことがわかりました。
セキュリティー的には「NetworkService」の方が安全なようです。

セキュリティーレベルについては、
MicroSoft TechNet によると以下の通りです。

-------------------------------------------------------------------------------

ApplicationPoolIdentity: 

既定では、アプリケーション プール ID アカウントが選択されています。アプリケーション プール ID アカウントは、アプリケーション プールが開始されるときに動的に作成されます。そのため、このアカウントは使用するアプリケーションに対して最も高いセキュリティを提供します。

Local Service: 
Local Service アカウントは Users グループのメンバーであり、このアカウントには Network Service アカウントと同じユーザー権利が与えられていますが、対象がローカル コンピューターに制限されています。アプリケーション プール内のワーカー プロセスが Web サーバーの外部へアクセスする必要がない場合に、このアカウントを使用します。

Local System: 
Local System アカウントは Web サーバーの Administrators グループに含まれるアカウントであり、このアカウントにはすべてのユーザー権利が与えられています。Local System アカウントを使用すると、Web サーバーに対する重大なセキュリティ上のリスクが生じることがあるため、このアカウントは可能な限り使用しないでください。

NetworkService: 
Network Service アカウントは Users グループのメンバーであり、アプリケーションの実行に必要なユーザー権利が与えられています。このアカウントの資格情報を使用すると Active Directory ベースのネットワーク全体で対話を行うことができます。

-------------------------------------------------------------------------------