Windows7 x64 環境に於けるVB.NET WebBrowser PDFインライン表示

.NET FRAMEWORK 3.5で開発したアプリがWindows7 x64環境で正しく動作しなかった。

実装した機能
WebBrowserコントロールにpdfファイルをインライン表示する機能

現象
x64環境だと、インライン表示されず、別窓に開いてしまう。つまり、pdfファイルをダブルクリックした時と同じ画面。

解決方法
VSのコンパイラの詳細設定で、ターゲットCPUをAnyCPUからx86に変更(因みに、x64では駄目だった。adobe readerは32ビットだからね。)。

これだけで解決してしまった。

でも、この解決方法を見つけるまでは、実にまる1日かかった。
ネットで検索しても解決方法は見つからず、仕方がないのでadobe のSDKを使ってOLEでPDFを表示することにしたのだけど、WebBrowserよりも動作が遅い。何故か分からないけどpdfのページ数が多いと極端に遅い。しかし、仕方がないのでこれで我慢しようかと思っていた時、ふと気付いた。SDKのサンプルをx64環境で動作させる時、AnyCPUだと動作しなかったのでx86に変更してコンパイルして動作させた。ひょっとして、WebBrowserも同じかと思って試してみたところ、案の定、動作した。

あ～、今日はこれで仕事は終わりにしよう。気分上々。

SQL文て意外と奥が深いんだな

業務用アプリでデータチェック処理が2分かかっていた。俺の感覚では数秒で終わらないといけない処理なので、早くなる様にアルゴリズムを変更したら逆に5分かかるようになってしまった。

そこで、今度はSQL文のWHEREを重点的に見直した。
今まで文字列を=で正確に比較していた部分を、LIKE %で曖昧検索にしたらそれで処理速度が向上。更に、いくつかの条件式を一つの条件式に纏めてみたら(単純に纏めたのではないよ。ほぼ同じ条件になる様に全く別な条件式に変えた。)これで劇的に向上。その他細かいチューニングをして、最終的には2秒で終わるようになった。

う～ん、まだまだ勉強が必要だな。

ADO.NETでExcelブックのデータ取り込み

開発中の業務用アプリで、Excelブックからデータを取り込みたいのだが、JET OLE DB プロバイダーを使って読み込むと、取りこぼしが発生することが判明。

マイクロソフトの技術資料によると、「従来のデータベースとは異なり、Excel テーブルの列に直接データ型を指定する方法はありません。OLE DB プロバイダが列内の 8 行をスキャンして、そのフィールドのデータ型を推測します。」とある。

例えば、ある列でデータの先頭から8行目までは空白セルが続き、その後に数値が入っているセルが出現すると(例えば9行目)、その数値が無視されてしまう。つまり、空白セルと同じ扱いになってしまう。

試行錯誤した結果、書式に数値を指定しておけば、推測の結果が数値となり、そのデータは正しく取り込まれることが分かった。

推測に使用する行数は拡張プロパティのMAXSCANROWSを指定する事により、最大で16行まで指定できるが、1～16行目迄は空白で、17行目に1が入っていると17行目は空白になってしまう。

一番の解決策は、Excelテーブルの列に直接データ型を指定出来る事なのに、マイクロソフトは何故そう出来るようにしてくれないのだろう。

結局、VBA(Visual Basic for Applications)でマクロを作って、それをVB.NET側から起動する事にしたのだが、そのVBAマクロがアドインだと、VB.NET側から起動する事が出来ない。回避策はマイクロソフトが公開しているが、それについての動作は保証していない。これで業務ソフトを作らなければならないなんて。。。

まったく、何でこんな不便な仕組みを作っているんだろう、マイクロソフトは。