Windows 8 Consumer Preview での VB6 アプリ

前回は Developer Preview 版で検証してみた VB6 製アプリですが、今回は Consumer Preview 版にてやってみました。検証環境は次のような感じで構築しています。

• Windows Server 2008 R2 SP1 上の Hyper-V に構築
• Windows 8 x86 日本語版を利用
• メモリ設定は起動時 1024MB、最大 2048 MB にて設定

VB6 でもクラスは役に立つ

※これは VB Advent Calendat 2011 用の投稿です

元々私は VB2 からの VisualBasic プログラマだったりします。お仕事としても VB を利用していますが、まだまだ VB6 は廃れないなー、というのが率直なところです。

VB6 を利用されている場合、言語上の仕様もありあまりクラスを利用するメリットが見いだせないかと思われます。特定のケースに限り利用するだけで、結構使われていない。または使った事のない方も多いのではないでしょうか。ですが、VB6 でもクラスを利用する事で役立つことは多くあるのです。

VB6 でコンソールアプリを作る

今までずっとできないできないと思っていたところ、@rinta100 さんに教えてもらいました。まずはリンクを。

How to create a VB6 console program

詳しいことはリンク先を見てもらうとわかると思いますが、コンパイル時に明示的にライブラリのリンクを行う（ LINK.exe /EDIT /SUBSYSTEM:CONSOLE ～）ことで、コンソールアプリを作成できるようです。

これは正直驚きました・・・！

Windows 8 Developers Preview での VB6 アプリ

早速ダウンロード開始されていたので、Hyper-V上に環境を構築、VB6アプリの挙動を検証してみました。まだ本格的な検証は行っていませんが、軽く触った感じではかなり良好です。

VIsta 環境以降での SendKey 代替案

VB6 製な AP で Vista 環境以降に限定して起きる問題として、MS-IME の挙動がおかしくなるというのがあるんだよね。勤務先では IME 2007 をやめて ATOK を購入させることで対応させていたけど、根本的な問題は恐らく Sendkey Win32 API を利用しているからという気がする。

自分のPJではSendkeyを利用せずにKeybdEvent API を利用してEnterキーとかの制御をしているんだけど、こっちでは同様の問題は発生していないんだよね。定義はこんなの。

Private Declare Sub KeybdEvent Lib "user32" Alias "keybd_event"
(ByVal bVk As Byte, ByVal bScan As Byte,
ByVal dwFlags As Long, ByVal dwExtraInfo As Long)

利用するときはこんな感じ

Private Const KEYEVENTF_EXTENDEDKEY = &H1
Private Const KEYEVENTF_KEYUP = &H2
Private Const VK_TAB = &H9 '[TAB]
Private Const VK_SHIFT = &H10 '[Shift]

Call KeybdEvent(VK_TAB, 0, 0, 0)
Call KeybdEvent(VK_TAB, 0, KEYEVENTF_KEYUP, 0)

こんな感じで使ってあげればTABを押して離したというのをSendkeyと同じように実現してくれる。で、使っている感想としてはSendkeyであった動作不具合がこっちだと再現できないので、結構Vista Windows 7 とかでも対応としてやっていいような気がする。

Windows 7 + VB6 + DenpyoMan 1.5J でIME切替が思うようにならない場合の対処

そもそもサポート終了というか販売終了してからどれくらいたっているという話はおいておいて。

Windows 7 環境で VB6 + DenpyoMan の組み合わせを利用していると、IME=全角なDenpyoManセルから、別のTextBoxなどにマウスでフォーカス移動し、その後DenpyoMan上のセルへマウスでフォーカスを戻した際、IMEが半角アルファベットになってしまう現象が発生する事があるんだよね。

Vistaからの対応として、EnterEdit時にIMEモードを再設定してくれというナレッジはGrapeCityさんから出ているけどWindows7になった場合これだけでは不十分で。ちょっと時間とって試してみたら、下記のソースで対応できたっぽい。

Dim orgIMEMode As Variant

'ＩＭＥモードを再設定
orgIMEMode = objDenpyo.TRow(.ActiveCellKey).Details(dpTextIMEMode)
objDenpyo.TRow(.ActiveCellKey).Details(dpTextIMEMode) = dpIMEOff
objDenpyo.TRow(.ActiveCellKey).Details(dpTextIMEMode) = orgIMEMode

誰の役にも立たない気がするけどｗ

Windows 7 における VB6 の Strconv 関数の挙動

以前にTwitter上でつぶやいたにも関わらず、きれいさっぱり忘れてしまいなおかつその問題が別の案件で出てしまってさぁどうしよう、と悩んでしまったのでメモとして。

Shift-JIS を扱うプログラムではバイト単位に文字列を操作したいという要求が多いので、例えば「先頭5バイト」などといった場合、次のような書き方が多いと思う。

StrConv( LeftB ( StrConv ( [originalStrings], vbUniCode), 5), vbFromUnicode)

Vista まではこれで問題がないのだけど、Windows7ではStrconv関数内部で呼び出されているAPIの挙動が変化したので、これで抽出した場合でも2バイト文字の先頭１バイトは残ってしまう。VistaまではStrconv関数の処理結果として２バイト文字の先頭だけが残るようなケースでは、その部分を除去してくれていたのだけどWindows7ではそうならずにそのまま返却されてくるんだよねぇ。

対応策としては「1文字ずつ」処理するようなロジックに切り替えることぐらいしか思いついていません。大した手間でもないのでそれで十分だと思います・・・

DenpyoManとDataGridView

社内で講習会なぞをやっているので、VB6・VB.Net共に調べたり話したりすることがそれなりにあるんだけど、グリッド系コントロールはどれもこれも基本思想としては一緒な気がしているんだよね。

異なるのはUIデザイン部分が殆どで、大枠としての制御（値の使い方等）はそんなに違いがないように思えるなぁ。DataRepeaterだって、細かい部分は異なっても大枠の制御は似たようなもんだし。

この部分で違う設計が思いつけば意外とイケるコンポーネントにできるかも。

どうもグリッドという物自体に行き詰まりを感じる・・・

Windows7 RC版でVB6製アプリケーションの動作

ViryualPC上で今回も環境を用意してみたので一通り動作確認。
相変わらずTabCtl32.ocxとMsflxgrd.ocxがレジストリ登録周りで失敗しているくせに、何事もないかのように進んでしまい少々ハマっただけでとりあえずは問題なさそう。

一応自分で手掛けているシステムだけ確認したけれど、その際に利用していたサードパーティ製ツールはこれ。

• DenpyoMan 1.5
• ActiveReport 1.5

一応この二つは問題なく動いている様子。これで一安心かな・・・。

GrapeCity製品で問題あるのは、自分が関わっている中ではInputMan6.5だけかな。
自分のプロジェクトでは利用していないけど、どうやらこれのIME制御関係とメニュー関係のocxで問題が出る様子。
でもInputManとDenpyoManってIME制御同じことやっていると思っていたんだけどなぁ。

今のところ自分のプロジェクトのDenpyoMan利用箇所では問題ないんだよね。

・・・これでXP Modeでなくても大丈夫とわかって一安心だｗ
使ってはみたいんだけどねぇ。

Windows7のWindows XP Mode

あー、なんというかやっぱりこういう形になってきたか、というのが正直なところ。

結局一部のWindowsXPから乗り換えられないユーザー、ベンダーの為に仮想化されたXPを標準提供しようということなんだよね。

ぱっと見た目はAPP-Vというか、VirtualPCのように「いかにも仮想化です」という雰囲気がないのでいい感じはするｗ

実際にベータがリリースされたら確認はするけど、APPからストレージ（ローカル環境）にアクセスする際に、何か気をつけないといけない点があるような気がするなぁ。XPからVistaに変化した際に一躍有名になったローミングとか、一部フォルダのリダイレクトとかをもう一度チェックしないといけないのかな？

Windows7にVB6アプリ

まぁ職業柄仕方がない（ｗ）のでWindows7ベータ環境にVB6製システムをインストールしてみて動作確認なぞしてみた。今回のシステムはGrapeCity社のDenpyoMan1.5とActiveReport1.5を利用しているのでここらへんの確認もこめてやってみたんだよね。
結果としてはまぁVistaと同様。というよりも、このシステムを作っている時、ある程度考えて作っていたおかげかVistaでの文字入力のトラブルとかファンクションキー利かないよ！ｳﾜｧｧﾝ！なんてトラブルも全部回避していたので、一応安心ｗ

いやね、社内の他の人達が作ったシステムだと上のトラブルが出ているみたいだからｗ
ま、作り方の差が出ているわけですが。

ただし、インストールにちょっと問題があったんだよね。このシステムのインストールはVisualStudio Installerで作成していたんであまり心配していなかったんだけど、MsFlexGrid.ocxとTabPage.ocx（名前が怪しいけど、グリッドとタブコントロールの事です）のインストールだけが正常に行われていなく、レジストリ未登録みたいな状態のまま「インストールは正常に終了」となっていたんだよね。うーん、これはWindows7環境がベータだからなのか、それともocxコントロール側の話なのか。

もうちょっと時間をとって手作業で設定してみたり色々確認はする予定。
とりあえずVB6アプリでも「ちゃんと作っていれば」特にトラブルなく動作してくれそうです。

長音と全角ハイフン

VB6での作業中。
伝票明細のケース数を印字しようと思ったので、コントロール名に「ケース数」と入れてみると。

「プロパティの値が不正です」

・・・忘れてたんだよなぁ。コントロール名としては使えない文字があることを。全角だろうと半角だろうと、〒とか＆とかー（ハイフンも含む）は使えないんだったよなぁ・・・。

＆はショートカットの設定に使うから、というのは覚えているんだけど、なんで長音とかハイフンってダメだったんだっけかな？

ライブラリ屋さんとして

元ネタ：ディベロッパー製品開発統括部 Blog : 開発者共通の悩み？Yomi-Autocompletion の動作に関して

いやぁ、よくわかるわこの悩みが・・・。
案件に依存したものしか作っていない場合には、絶対にたどり着かないこの悩み（ｗ

汎用性と専門性とのバランスというのは、常に悩みどころなんだよね。
極端な話、案件依存したヤツは社内で統一的に使うライブラリにはなるわけがないし（ｗ

いや、声を大にして言えないけど。

ファイルをVarBinary(MAX)列にINSERT、UPDATEする

これもフルテキストに関連するし、今回使う予定なのでメモ。

ファイルイメージをそのままDBに落とすためには、項目の型がVARBINARY(MAX)かIMAGEになっている必要がある。VARBINARYやIMAGE列には単純にINSERT（UPDATE）は行えず、OPENROWSET関数を利用しなければならない。OPENROWSET関数は「ローカルファイルをインポート」するような動き（実際にはローカルファイルをOleDbとして扱う、だけど）のでOPENROWSET関数を含んだSQL文を実行する際にはデータベースサーバ上に対象となるファイルが存在していなければならない。インポートの際にはOPENROWSET関数をBULKオプション、SINGLE_BLOBオプション付で実行する。

ちゅうことで、データベースサーバ上の一時領域をどこかで保持しないといけないね。んでデータクラスでSQLを実行する直前までにファイルをアップロードしておく、と。

んー、単純にデータクラス内部にアップロードのロジックを用意するってのもやだねぇ。やっぱり、アップロードの部分は別クラスに切り出しておかないと、後々どうにも具合が悪そう。

VistaでのVB6ランタイム

どうやらちゃんとWindowsInstallerを利用してインストールしても、レジストリに登録失敗するケースがあるみたい。

今回のケースではTabCtl32.ocxとMSFlxGrd.ocxがおかしくなっていた。再度Regsvr32.exeで登録しなおすことで問題は解決できたんだけど・・・。ネット上を見ていると、このほかにもWinSock周りで同様の現象がでるみたい。

UACをOFFにした状態でインストール、その後UACをONにしたりしても同じような状況になるって話もでてるね。
なんか特定のコンポーネントに由来した問題のような気もするな・・・。

VB6のコレクションと.Netのコレクション

久々にVB6の修正をやっていて気づいた。
VB6のコレクションにはClearメソッドがない・・・。

うわー、単純だけど地味に効いてくるなぁ・・・。よくCollectionの拡張しないでやっていたね、自分。

VB6サポート

昨日Windows2008Serverのセミナーに参加してきたんだけど、どうやらまだVB6ランタイムはサポートされる様子・・・。

技術者としては「とっととサポートうち切って.Netに完全移行」させてしまっていいと思うんだよねぇ。どうせVB6がサポートされないと困る！なんて言っている人たちって、サポートうち切られたからって他ＯＳに移る可能性は低いと思うんだよなぁ。

WindowsでVBしか使えない人だから文句を言っているような気がしてならないのよ。

VB6の頃に比べて思うこと

継承できるってなんてスバラシイ！、というのが一番思うトコだろうか。ＶＢ６でなんちゃってＯＯＰ形式なプログラムを作っていた身としては、普通に継承できるっていうことだけでもかなり感動なんだよねぇ。

でも、ＯＯＰなやり方を見たこともやったことない人にしてみると、これがそうでもない。まぁ、自分も体感するまでに数年かかっているから気持ちは分かる。

でも「そんなレベルで社内標準とかを語る」のはやめてくれ。マジで。おいらが何も言っていないのは、それでいいと思っている訳じゃなくて、「あなたに理解してもらうのが面倒だから」なんだよ・・・。

面倒くさいなぁ・・・

週末に今の会社の上期会議があったわけで、その場で各個人の上期目標などを色々発表していたんだが。

社内の雰囲気としてはおおむね.Netに進むという考えが浸透していたのが分かったのは良かった。これまで２年くらいかけて、今までと異なる設計思想やらフレームワークやらなんやらを言い続けてきた甲斐があったってもんだ。
ただ厄介な人物はあいかわらず厄介で。

「今までＶＢ６で利用してきたフレームワーク（実際はただのスケルトンなんだけど）を.Netに移植したりして、.Netに移行するかどうかを判断しようと思う」などと言う始末。

思わず言いたくなった。
「あなたにはそこまでできません。」
「ジャマだから.Netの開発に関わってこないでくれ」と。

資格試験を色々とうけて資格を取得しているのはえらいと思う。ただ、資格の悪いところが思い切り現れているんだよなぁ。「知識があることを示してはいるが、能力をあることを示してはいない」という点が。正直、この人は資格をたくさんもってはいるが、所詮それだけだなぁ、というのが自分からみた感想だな。全然レベルが低い。社内しか世界を知らないから、ものすごく見識が狭い（あまり人のことを言えた義理でもないのは承知でな）。
そして悪いことに今の社内に、自分と同レベルかそれ以上の見識をもった人間は開発にいないので、自分以外誰もその人に意見を言わないことだ。

データベースの正規化もできない。ＡＤも組めない。ＸＭＬも使えない。ＯＯも（少しだけでも）理解していない。年数だけ重ねたいい例だよ。

この先どこかでまたこの人とやり合う場面が生まれることになるとは思う。それを考えると正直面倒くさいな・・・。「好きにやってくれ、ただし俺には構うな」と言ってしまいたいよ、ホントに。

仕事でVB6

ちょっとこの頃は仕事の都合でＶＢ６をまた触っている。まぁ、他社パッケージ関連のカスタマイズだからなんだけどねぇ。

でもVB2005触った後にVB6を触ると、何とも言えない不便さを感じるねぇ。VB6だけやっていたころはまったく気づかなかったけど、VB2005をある程度使っているとその差がものすごく体感できてしまうのよ。結構開発環境は進化していることに改めて感心したねぇ。IntelliSenceとスニペットがなんといっても強力。FF12で言えばミストナックくらい強力だ（ｗ

しかし一番の困りどころは、頭の中で考える構成がすべてクラスを利用したロジックに染まってしまったのでVB6では非常に辛いとこだね・・・。