なぜこれが起こっているのかはわかっており、Windows 7/8 に対応するようにプログラムを変更する必要があることもわかっています。
よし、それなら私は死んだ馬を殴らないようにしようと思います (ただし、これは私が定期的に良いむち打ちをしたいと思っているものです。なぜなら、非常に多くの人が誤解しているからです)。あなたのプログラムが以前のバージョンの Windows でも正しく動作したという事実は、潜在的なバグの幸運な結果であったことだけを指摘しておきます。「Program Files」フォルダーは、書き込み可能にすることを意図したものではありませんでした。新しいバージョンの Windows のばかげた「問題」を回避しているだけではありません。これは、最初から実行する必要があったことです。
「users」の下の appdata フォルダーが、データベース/Word ファイル/バックアップの保存に推奨される場所であることはわかっています。ただし、私のシステムでは非表示になっており、ユーザーが簡単にアクセスできるようにしたい (非表示ではない) ので、MyDocuments フォルダーを考えていましたか?
これが複雑であることはわかっているので、できるだけ簡単にできるか試してみましょう...
" App Data"フォルダーは、アプリケーションによる内部使用を目的としたデータ用であり、ユーザーが直接見たり操作したりすることを意図したものではありません。
「マイ ドキュメント」フォルダは、ユーザーが表示して直接操作できるすべてのものを格納します。つまり、アプリケーションデータではなくユーザーデータです。
さらに、これら 2 つのフォルダ タイプのそれぞれに、ユーザーごとのバリアントとグローバルなバリアントもあります。「アプリ データ」の場合、ユーザーごとのバリアントは、ローカル (ローカル マシンのみにとどまる) とローミング (ユーザー アカウントをたどって、ユーザーがログオンするネットワーク上の任意のマシンに移動) にさらに細分されます。
そのため、ファイルに「ユーザーが簡単にアクセスできる」ようにする場合は、必ず「マイ ドキュメント」フォルダーを使用する必要があります。それが目的であり、ユーザー ドキュメントです。
これらの複雑なルールがすべて存在する理由は、Microsoft や Adobe などの人気のあるベンダーによる不正な動作をしたアプリケーションが、ユーザーの「マイ ドキュメント」フォルダーにジャンクをダンプする傾向があった (持っている?) ためです。直接。その後、ユーザーは自分のドキュメント フォルダーを開くと、そこに置いたことのない大量のファイルが表示されます。「これは何ですか?これらは私のものではありません。私の文書はどこにありますか?」先週、母の PC を更新したときに、母から尋ねられました。
MyDocuments を見つける方法が明確ではありません。誰でも助けることができますか?
VB 6から?簡単な方法は、あなたが見た質問でボブとマークが提案したものです。これには、Shell オブジェクトを作成し、関心のあるフォルダーの場所を照会することが含まれます。
欠落している部分は、「マイ ドキュメント」フォルダーに対応する定数です。定数の完全なリストはこちらにあります。必要なものには名前が付けられていますssfPERSONAL
(この API が作成された昔、Windows はそれほどフレンドリーではなく、「マイ ドキュメント」という名前はまだ発明されていなかったため)、値は です&H05
。したがって、コードは次のようになります。
Const ssfPERSONAL = &H05
Dim strMyDocsPath As String
strMyDocsPath = CreateObject("Shell.Application").NameSpace(ssfPERSONAL).Self.Path
MyDocuments\CompanyName や、上記のリンクに記載されている Appdata フォルダーなどを使用したい場合、パッケージ/配置ウィザードに、上記の mdb ファイルとフォルダーをこの特定のフォルダーにインストールするように指示するにはどうすればよいですか? 使用できる PDW の Appdata または MyDocuments フォルダーのマクロはありますか?
ボブが彼の回答でまだカバーしていないことをこれに追加できることはあまりありませんが、このVBアプリケーションを最新化するときに、より優れたインストーラーを支持して時代遅れのPDWを捨てることも検討することをお勧めします.
個人的に、私はInno Setupの大ファンです。これは Windows アプリケーション用の無料のインストーラー ユーティリティであり、スティックを振ることができるよりも多くの機能を提供します。VB 6 アプリケーションで非常にうまく機能します。私自身、そのために何度も利用しています。少なくとも基本的には、かなり使いやすいと思います。あらゆる種類の高度なカスタマイズがサポートされており、ドキュメントを読んでよく学習しないと難しいものもありますが、すべて非常に実行可能です。私は、Inno Setup プロジェクトをカスタマイズする Delphi コードを書くことさえできませんでした。
Inno Setup では、事前定義された定数の 1 つを使用して、システム フォルダーへのパスにアクセスします。たとえば、{userdocs}
と{commondocs}
. これらは、PDW のマクロとほぼ同じように機能します (まったく同じではないにしても、長い間使用されてきました)。
もちろん、これでも Bob が正しく指摘した問題は解決しません。ユーザーの "My Documents" フォルダの概念は、インストーラにとってあまり意味がありません。すべてのユーザー間で共有されているため、確かにグローバル(パブリック)の "マイ ドキュメント" フォルダーにアクセスできますが、これはおそらく必要なフォルダーではありません。インストーラーは、十分な権限を持つすべてのユーザーが実行できる必要があります。実際、これは多くの場合、アプリケーションの実行に使用される通常のユーザー アカウントとは異なる管理者アカウントになります。セットアップ中に特定のユーザー アカウントを想定することはできず、設計でこれを考慮する必要があります。
「テンプレート」アプローチがあなたにとって良いものになるように思えます。新しいユーザー アカウントのセットアップに使用されるファイルの完全なセットは、"Program Files" フォルダーに保存できます。これは、誤った変更から十分に保護されているため、実際には良い場所です。これにより、必要な権限を持っていることが保証されます。アプリケーションが新しいユーザー アカウントで初めて起動されたときに、この事実を検出し、アプリケーションで使用する新しいユーザー アカウントをセットアップすることを提案できます。この時点で、正しいユーザー アカウントで実行していることがわかるので、上記のコードを使用して、そのユーザーの "マイ ドキュメント" フォルダーの場所を照会できます。"Program Files" 内のアプリケーションのフォルダーのサブディレクトリに目的のフォルダー構造がすべて設定されている場合、新しいユーザー アカウントの設定は、そのフォルダーをコピーするのと同じくらい簡単です。ユーザーから情報を収集したり、カスタマイズ オプションを提供したりする必要がある場合は、「初回実行ウィザード」を少し書くことができます。