Visual Studioに関するTipsです
これらは、エラーを最初にトラップしたルーチン内でしか有効にならないらしい。
エラールーチン内で別の関数を呼び出して、そこでresumeを実行しても、エラーが発生していないので使えないと表示される。
まったく原因が謎なんですが、あるプログラムでMDI子フォームにツリービューを貼り付けていて、そのVisibleプロパティーをプログラムでFalseにするとなぜか、MDI子フォームのActiveイベントが発生しなくなりました。
ただ、普通に新規にプロジェクト作成した場合は、問題なく動くことを確認したので、そのプログラム特有なのですが、Activeイベントの発生をキャンセルすることなんて、出来るのだろうか?
サブクラス化と呼ばれている方法を使えばなんでもできそうだが、そんなことはやってないようである
> 問題のプログラム
結局、Visbleをいじらずに、TreeViewコントロールのサイズを最小にすることで現象を回避しました。
まあ、自分が知らなかっただけですが、Withはユーザー定義型だけではなく、クラスにも使えます。
たとえば、
Dim Obj as New Class1 Obj.Hoge = "Password" Obj.Fuge True
こんなのが、
Dim Obj as New Class1
With Obj
.Hoge = "Password"
.Fuge True
End With
こういう感じで。列挙型には使えないです。
デバッグ環境ではそのような動きになります。
オプションの全般にエラー処理のオプションがあるので、これを切り替えれば、デバッグ環境でもエラートラップの動作が確認できます。
参照設定を指定し直したら、コンパイルが通らなくなったとか。そういう場合は、順番をチェック。
順番は関係あるみたいです。
当然かもしれないけど。
EXEを作る際には、保存されている内容を元に作られているようで、変更を保存せずにEXEを作っても修正が反映されていない。
同様にVisual Source Safeでも、プロジェクトファイルをチェックアウトしていないと、保存時にエラーが出てしまうがキャンセルしてでも、先に進めて保存しないと、EXEに反映されない。
バグらしい。
insファイルをメモ帳などで書き換え、DLLSelfRegisterをTLBRegisterにする
一度、コンパイルすると出てきたりする
普通あれば、共有機能を使用するが、以下の場合はそこでは使わなくてもいいのかも。
たとえば、以下のようなフォルダ構成で、VBでeditとprintというプロジェクトを作っている。
Project
edit
Save
print
\Pro\Save(editプロジェクトの中のSaveファイルを参照)
二つのVBプロジェクトにはどちらもSaveファイルを参照しているが、printの方はeditフォルダの中のSaveを見に行っている。
という場合、共有させなくても、元々editの中のファイルを見に行っているので、共有しているのと同じようなことになる。
最新バージョンを取得するときはProjectの所から取得して、このフォルダ構成を壊さなければ良い。
二つともメジャーバージョンアップした場合は、Projectから丸ごと、共有、分岐をするという使い方が良いのではないか?
弊害があったらごめん。
最初にどこのプロジェクトに共有ファイルを含めたいかを、VSSの画面で指定して、共有を実行してどのファイルを共有させたいかを選ぶ。
ちょっと、普通の感覚とは逆の感じがするが、これがVSSの操作の基本みたい。
ヘルプを読んでもいまいち使い方がわからなかったが、どうもこのようにして使うらしい。
最初にVSSのデータベースをサーバーなどに作成する。各ユーザーはこのデータベースに接続して使う。
既存のVBプロジェクトがあるとする、これをVSSに管理させる場合は、ツールからプロジェクトをVisual Source Safeに追加を選ぶ。
どこにプロジェクトを作るかの設定画面が出る。これはVSS内での管理イメージだが、親階層でその下のサブプロジェクトも含めてまとめてダウンロードすると、ローカルにこの構造のままフォルダが出来るので、そこは気をつけましょ。
わかりやすいように分類してプロジェクトを作って、登録する。(ちなみに、うちの会社では製品ごとに分けて、さらにマイナーバージョンごとぐらいにプロジェクトを分けている。)
次に作業フォルダを設定する、これはプロジェクトごとユーザーごとに設定する。普通は自分のローカルのハードディスクに設定しておくでしょう。これを設定して、「最新バージョンの取得」を実行すると事で作業フォルダに最新のソースがダウンロードされるイメージ。
ちなみに、ローカルからソースを追加した場合は、初期状態でその場所が作業フォルダに設定される。
現行バージョンで分岐している場合は、ロールバックすることにより現行バージョンが無くなるので、リンクが切れるよという警告だと思う。
ロールバックしようとしているバージョンよりも前で分岐されていれば、たぶんなんの問題もない。
Vssのソース管理というメニューから選べる。
まず、統合先を選んで、このメニューを選び、どのバージョンの変更をマージして取り込むかを選択する。順番を間違えないように。
これは、結構便利。
時間の関係だったり、言語の限界だったりして、似たモジュールをどうしても作らないといけない場合(既に作ってあってそれを使うしかないとかも)がある。そして、両方に共通する機能のアップなどがあって、それぞれに同じような修正を施さないといけない場合、片方に修正を加えた後、「相違点を表示」機能を使って、変更点を確認しながら作るとかなり楽。VB上で表示してしまうと、VB自体の操作ができなくなるので、VSS本体を起動してやるべし。
タブコントールなどはデザイナーでタブを動かしただけで、チェックアウトしていなくても、ローカルのデータは中途半端に書き変わってしまう様子。それで、デバッグ、EXEの作成などすると動きがおかしくなる。
絶対にチェックアウトしていない状態で、デザイナをいじってはいけない。これは他のコントロールも同様のことが起こると考えられる。
また、一度触っておかしな状態になった場合、「最新情報取得」を実行してもローカルのデータは更新されないことが多いので、一見サーバーのデータが壊れたかのように見えるが、実際は違う。この場合、チェックアウトするとサーバーのデータがダウンロードされ、動きが正しくなる。
フォームをマージすると画面が乱れることあり。一度コンパイルすると直ったりするので、ためしてみよ。なおったら、保存してチェックイン
インストールの最後でocxの登録に失敗することがある。これは依存するファイルを一緒にインストールしていないと起こる。
依存ファイルのバージョンが古いという場合も起こるかもしれない。
VBで市販のocxを使っている時なんかは、自動で依存ファイルを登録まではしてくれないようで、その時は自分で登録する必要がある。
Dependency WalkerというツールがVisual Studioにはついてくるので、これで依存ファイルを確認しておいた方がよい。
結局、これもインストールの作成に失敗していることが多し。
Visual Studio Installerも万能ではないので、プロジェクトから依存ファイルを拾ってインストールイメージに追加してくれはするけど、最終的には自分で必要なファイルをチェックした方が良い。
Visual Studioよりもディストリービューションウィザードの方が的確に必要なファイルを拾ってくれるような気がするので、こいつが作ったセットアップのlstファイルを確認して、見ていくのも良いかもしれない。
ディストリービューションウィザードも拾ってくれないファイルがあるので、それは自分で参照設定を確認したり、市販の物であれば、マニュアルなどを確認して追加しないといけない様子。結局、自分で何のDLLを使用するか把握してないとちょっと危ないです。
(#A-takはコムラッドのxlist.ocxを使っていて、それに必要なccc3.dllを入れ忘れてうまく動きませんでした（笑）)
あと、プロパティの名前忘れたけど、DLLを自己登録機能(Self Registry)を使って登録するとか、しないとかの設定もあるので、そこも確認。これはディストリービューションウィザードのlstファイルを見ればわかる。
OSを入れたばかりの環境を作って、テストしながらインストールイメージに含めるファイルを追加していくしかなさそうです。
VSInstallerはマージファイルというmsmという拡張子のファイルを使って、VBのランタイムなどを入れるみたいですが、その中に含まれているファイルを手動で追加すると、「マージファイルの中にも同じファイルがあるぞ」と怒られる。
でも、それで安心して追加しないでいると、インストールされないこともある。
この警告を無視していいか、よくわからないが、インストールされないのはしょうがないので、自分はどうしてもインストールされないファイルだけ、警告を無視して追加している。
「スタートメニュー」の所に「プログラム」とか作ってビルドすると、Windows2000ではうまくいきますが、Windows98では、スタートメニュー直下に全角文字の「プログラム」というフォルダができてしまいます。
正解は、カスタムフォルダを新規に作成して、「ProgramMenuFolder」という名前にして、その中にショートカットを作ればよい。
・・・というか、これはもうちょっとどうにかならなかったのだろうか?
他にもいろいろあるみたいです。以下の「Visual Studio Installer Tips」参照。サンクス!!
「ZERO SPACE」
http://www02.u-page.so-net.ne.jp/ja2/heiro/
ドキュメントによるとこれをTrueにすると従来のDLL管理方法の参照カウンタを使うとのこと。
他のページではSharedDLLsに登録されると書いてある。
おそらく、従来の管理手法ということからすると、インストールした回数をカウントして、アンインストールしたらカウン
トを減らしていき、0になったらどのプログラムもそのDLLを使っていないとみなし削除するという、管理方法のことだと思う。
自分は、とりあえず、ディストリービューションウィザードのlstファイルでsharedになっている物にこれを設定した。
サイズは495×68のサイズで作成すると、ちょうどぴったりのはず。
かなり、強固なシステムになっていて、作成したインストーラーでインストールしたファイルを一つでも削除すると、アプリ起動時に自動的に復元する。これは、DLLやEXEに限らず、どんなファイルでも削除すると復元される。
逆に問題があって、あるファイルを消したくても消せず、インストーラーを作り直さなくてはいけないことになる。