カテゴリー別

お絵描き、デザイン

写真、動画関連ソフト

アメーバピグ専用ソフト

ホームページ関連

画像処理

スキャナー用

SEO 関連

お楽しみ

その他

過去ログ

2018年01月19日(金)

7z.dll を使ってみる段階は完了しました

7z.dll を使って書庫を解凍してみるテストが完了しました。

安定して使えそうな感じでなので、
使いやすくラップする作業に入りました。

真面目にやると大変ですが、
使う API しかラップしないので
そんなに、かからないでしょう。

ちなみに、ラップとは
サランラップをかけること
と似たようなもんで、かけると
食材をつかんでも汚れなくなるので安心です。

やっぱ、違うか。

ま、雰囲気は似ていて、直接さわるよりも
使いやすくなるようにします。それがラップ。

当然、うまくやらないと、
使いにくくなるだけなので意味ないです。

7z.dll の場合、COM なので、
ATL の CComPtr を使うと
かるくラップできます。

私の場合、エラー処理のコードを隠したいので、
HRESULT 値がおかしいときは例外を
投げるようなコードでさらにラップします。

ちなみに、PROPVARIANT のラッパーも
ATL/WTL にないみたいなので自前でラップしてます。

・・・

話は変わりますが、7z.dll を ATL で扱うには

struct __declspec(uuid([GUID])) IArchiveOpenCallback;

みたいな宣言が必要です。上の疑似コードは、
IArchiveOpenCallback の GUID として
[GUID] を紐付けます。

error C2787: 'IArchiveOpenCallback':
このオブジェクトに関連付けられた GUID はありません。

みたいなエラーになったら宣言してあげましょう。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2018年01月18日(木)

7z.dll を用いた zip の解凍に成功しました

前回に引き続き、7-Zip API のテスト中。

今日は、7z.dll を使って zip ファイルを
解凍してみるテストが完了しました。

IStream もどきの COM インタフェースを
備えたオジェクトポインターを渡す必要がありますが、
IStream をラップすれば、難しくはありません。

COM に精通してればの話ですが・・・。

ただし、7z の IInStream の Read 実装で、
IStream の Read の返り値をそのまま返すのは
よろしくないようです。

というのも、IStream ではファイルの末尾に逹っした場合
返り値として、S_OK の代わりに S_FALSE が返りますが、
7z の IInStream では、その場合も S_OK を期待しているからです。

・・・

書庫ファイルのフォーマットを推定するやり方も
だいたい、目処がたったので、もうそろそろ
使ってみる段階は終わりかな。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2018年01月16日(火)

7-Zip (7z.dll など) を、VisualStudio 2015 でビルドしてみました

今日は、タイトルの通り、7-Zip
VisualStudio 2015 でビルドしてみました。

結論からいうと、 ココ にある通りの方法で OK でした。

簡単に書くと、VisualStudio をインストールするとできる
コンパイル用のコマンドライン環境で、CPP¥7zip に移動し、
namke すれば OK なのですが、そのままだとエラーがでるので、

CPP¥Build.mak の、-OPT:NOWIN98 を削除します。

リンク先のように、
NEW_COMPILER=1
すると、
-GS- オプションと、
-Zc:forScope オプション
がはずれるので、指定した方がよいでしょう。

-GS- は、バッファーオーバーランの検出がオフにするオプションです。
7-Zip にバグがなければ無関係ですが、指定しなくてよいでしょう。

-Zc:forScope は、for の初期化子で定義された変数が
for ブロックの外に出ないようにするオプションだと思います。
VC の昔のバージョンだと既定でブロックの外から
参照できていたのでそれ用でしょう。別にエラーにならないので
あっても困りませんが、指定しなくてよいでしょう。

もう一つのコマンドライン引数の、MY_STATIC_LINK=1 ですが、
指定するとコンパイルオプションの -MD が -MT になるようです。

利用する側のプログラムをコンパイルするときに、
構成プロパティ > C/C++ > コード生成 の
ランタイムライブラリーで、「マルチスレッド DLL」のかわりに、
「マルチスレッド」を選択している人は、指定しましょう。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2018年01月04日(木)

「このファイルを開く方法を選んでください。」で表示されるプログラム名

写真閲覧ソフトのミルノ PC フォトフレーム を修正中。

写真をミルノに!

で覚えてね。キラーン。

まぁ、だいたいテストも終わったので、
x64 版のインストーラーを作成中です。

ミルノ PC フォトフレームをインストールすると、
画像ファイルの既定のプログラムとして設定できます。

その副作用として、ミルノをインストールした後、
エクスプローラーから Jpeg などの画像ファイルを開いた場合、
「このファイルを開く方法を選んでください。」
画面が表示される場合があります。

「このファイルを開く方法を選んでください。」

で、x64 版 (64 ビットバージョン) と
x86 版 (32 ビットバージョン) を
両方ともインストールした場合、
表示される名前が、どちらも、
ミルノ PC フォトフレームだと
好みの方を選択するのが困難です。

そこで、64 版の名前を
「ミルノ PC フォトフレーム x64」
と表示されるようにしました。

結論から言うと、
「このファイルを開く方法を選んでください。」
画面で表示されるプログラム名は、実行ファイルの
「ファイルの説明」か「製品名」なので、
それらを変えれば OK です。

リソースファイル (.rc) でいうと、
"FileDescription" か "ProductName" です。

まぁ、どちらか使われてるんだと思いますが、
自分は、両方とも同じ値にしちゃってるんでわかりません。

ところが、最初、プログラムの上記値を変えても、
表示される名前が変わりませんでした。

たぶん、OS にキャッシュがあるんだろうと思って
調べたみたところ、レジストリの下記場所に
プログラム名のキャッシュを発見しました。

コンピューター¥HKEY_CLASSES_ROOT¥Local Settings¥Software¥Microsoft¥Windows¥Shell¥MuiCache
コンピューター¥HKEY_CURRENT_USER¥Software¥Classes¥Local Settings¥Software¥Microsoft¥Windows¥Shell¥MuiCache
コンピューター¥HKEY_USERS¥[おそらくログインユーザーのID]¥Software¥Classes¥Local Settings¥Software¥Microsoft¥Windows¥Shell¥MuiCache
コンピューター¥HKEY_USERS¥[おそらくログインユーザーのID]_Classes¥Local Settings¥Software¥Microsoft¥Windows¥Shell¥MuiCache

上の 4 つの場所に発見しましたが、
1 つを消すと全て消えたので実体は同じものでしょう。

名前が「実行ファイルのパス + .FriendlyAppName」で、
値が「表示名」になってるようです。

で、今回の場合は、値の名前が、
C:¥Program Files¥SSSoftware¥Miruno2_64¥Miruno.exe.FriendlyAppName
のを削除すると、めでたく新しい名前が表示されました。

・・・

x64 (64 ビット) バージョンの公開はまだ先ですが、

日本語の最新版はこちらのページから、ダウンロードできます
You can download the latest version of Miruno PC Photoframe here.

ご意見・ご要望はこちらからどうぞ
You can contact me by this mail form.

・・・

今年もよろしく。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2017年12月29日(金)

ミルノ PC フォトフレーム x64 (64 ビットバージョン) のインストーラー作成など

写真閲覧ソフトのミルノ PC フォトフレーム を修正中。

写真をミルノに!

で覚えてね。キラーン。

まぁ、だいたいテストも終わったので、
x64 版のインストーラーを作成中です。

インストーラーは Windows Installer XML (WiX)
と呼ばれるもので作成してのですが、
ちょっとはまったのでメモしときます。

はまったのは、以下の点。

多言語に対応する場合、light でリンクするときに
各国語用の文字列を定義した、wxl ファイルを入力します。

当然、ソフトウェアの名前は、
言語ごとに違うので、wxl で定義します。

で、64 ビットバージョンと
32 ビットバージョンで名前を変えるには、
wxl で変えるのが自然なので、
条件分岐しようとしたところできませんでした。

wxs ファイルでは <?if $(sys.BUILDARCH) = x64 ?>
みたいな感じで分岐できるのですが、wxl では無理です。

何か方法が無いかと思って
探してしまったのが運の尽き。

おそらく、簡単な方法はなさそうです。

wxl ファイルは各国語用の
文字列を用意するためのものなので、
プログラマーでなくとも書いたり読んだりできるように
条件分岐などの複雑な命令は使えない設計なんだと思います。

非常に正しいです。

では、どうすればよいかというと、
wxl では単純に 32 版用の名前と
64 版用の名前を両方定義しておいて、
参照する側で分岐します。

<?if $(sys.BUILDARCH) = x64 ?>
<?define ProductName = "!(loc.ProductName64)" ?>
<?else ?>
<?define ProductName = "!(loc.ProductName32)" ?>
<?endif ?>

wxs 側のコードは、こんな感じっすね。

・・・

x64 (64 ビット) バージョンの公開はまだ先ですが、

日本語の最新版はこちらのページから、ダウンロードできます
You can download the latest version of Miruno PC Photoframe here.

ご意見・ご要望はこちらからどうぞ
You can contact me by this mail form.

・・・

ちなみに、light に -d オプションを使うと、
変数を定義できますが、それを使うよりも
上であげた方法の方がシンプルでいいと思いますよ。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2017年12月22日(金)

Windows API、SECURITY_ATTRIBUTES、bInheritHandle 引数の訳

写真閲覧ソフトのミルノ PC フォトフレーム を修正中。

写真をミルノに!

で覚えてね。キラーン。

SECURITY_ATTRIBUTES の bInheritHandle を訳します。

返されるハンドルを、新しいプロセス作成時に継承するかどうかを
指定する真偽値です。もしこのメンバーが TRUE なら、
新しいプロセスはハンドルを継承します。

ですね。

書いてあるとおりですが、子プロセスを作成した後に
親プロセスで作成したハンドルは継承できませんでした。

まぁ、常識的にはそうだわな。

なので、子プロセスへの通信が 1 回のみの場合は
継承を TRUE にしてハンドルを作成した後、
プロセスを作成すれば、ハンドルがそのまま使えます。

ところが、2 回目以降の通信では、
exe が起動済みなので、そのまま渡せません。

結局のところ、普通にプロセス間通信するには、
DuplicateHandle する必要がありますね。

DuplicateHandle で複製したハンドルを閉じるには ?

ちなみに、DuplicateHandle で作成した
ハンドルは、ターゲットプロセスでのみ
有効なハンドルなので、CloseHandle も失敗しました。

私のプログラムでは、(とういかだいたいそうなるとは思いますが)
種々のハンドルを共有メモリーに置いて通信します。

が、転送先のプロセスで共有メモリーの読み込みに失敗すると
ハンドルも当然、読めません。

ハンドルが読めなければ、もちろん
閉じることもできないので、やはり
送信元プロセスで閉じる必要がでてきます。

DuplicateHandle を読むと、dwOptions に
DUPLICATE_CLOSE_SOURCE を指定することで
ハンドルを閉じることができると書いてあります。

その際のパラメーターは、
hSourceProcessHandle にはターゲットプロセスのハンドルを、
hSourceHandle には複製された、閉じたいハンドルを
lpTargetHandle には NULL を
dwOptions には DUPLICATE_CLOSE_SOURCE を
指定せよと書いてあります。

じゃ、hTargetProcessHandle には
何を指定すればいいねん
と、つっこみたくなりますが、
きっと、何でもよいのでしょう。

・・・

x64 バージョンの公開はまだ先ですが、

日本語の最新版はこちらのページから、ダウンロードできます
You can download the latest version of Miruno PC Photoframe here.

ご意見・ご要望はこちらからどうぞ
You can contact me by this mail form.

・・・

bInheritHandle そんなに便利じゃないな。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2017年12月21日(木)

共有メモリーを利用したプロセス間通信のテスト完了

写真閲覧ソフトのミルノ PC フォトフレーム を修正中。

写真をミルノに!

で覚えてね。キラーン。

なにげに苦労しましたが、
64 ビットのミルノ PC フォトフレームから、
32 ビット Susie Plug-in を利用するための
実験が終了しました。

おおまかには、32 ビットの子プロセス (exe) を作成し、
Susie Plug-in をかわりに実行してもらいます。

32 ビットの子プロセスは実行する側なので、
サーバーと呼ぶことにします。

利用するリソースを最小限に留めるため、
Miruno 1 に対し、サーバーを 1 起動することにします。

複数の Miruno に対し、サーバーを 1 だけしか
立ち上げない方法も取れますが、実装が複雑になるわりに
メリットが少なそうなので、不採用です。

画像の読み込みスレッドごとに、
サーバーを立ちあげると、実装は少し簡単になりますが、
リソースの無駄が激しいのでやはり採用しません。

画像の読み込みは複数のスレッドで行いますが、
スレッドごとにサーバー (exe) を立ち上げないので、
サーバーも、リクエストを独立したスレッドで実行します。

これらを実現するために、
実験が必要になってきそうな機能は
私的には、下記の 3 つです。

1. 親プロセスで作成した共有メモリーを
子プロセスで読み込み/書き込みするテスト。

2. 逆に子プロセスで作成した共有メモリーを
親プロセスで読み込むテスト。
(別に書き込みもできると思いますが、今回は必要なし)

3. 親から子にリクエストを送ると、
子のプロセスのスレッドで実行するので、
それを待つテストです。

親プロセスで作成した共有メモリー

を子プロセスでアクセスするには、CreateFileMapping に渡す
SECURITY_ATTRIBUTES の bInheritHandle を TRUE にします。
また子プロセスを作成するときの CreateProcess に渡す
SECURITY_ATTRIBUTES の bInheritHandle も TRUE にします。

結果、CreateFileMapping で作成したハンドルを
そのまま、子プロセスで利用できました。

子プロセスで作成した共有メモリー

を親プロセスでアクセスするには、
DuplicateHandle を使います。

親から子に、親のプロセス ID を通知しておき、
子で CreateFileMapping したハンドルを
親プロセス用に複製してから返します。

おそらく、この方法は親から子にハンドルを渡すときにも使えますが、
InheritHandle した方が簡単そうです。

ま、InheritHandle に何か問題が発覚した場合は、
DuplicateHandle を使うことになるでしょう。

CreateFileMapping で作成するハンドルに名前を付けて、
他方のプロセスでは、OpenFileMapping する方法もありますが、
1 対 1 の通信では、実装が複雑になるため、おすすめできません。
衝突するかもしれない名前が無駄に増えるのもよくないですね。

親から子へのリクエストと完了待ち

リクエストは子プロセスに見えないウィンドウを作成しておいて、
子プロセスのウィンドウに SendMessage すれば OK ですね。

子のウィンドウは、 EnumThreadWindows すれば見つかります。

とはいえ、プロセス起動直後だと、ウィンドウが
まだ作成されていないかもしれないので
少し待つ必要はあるかもしれません。

サーバー側では、処理用のスレッドを作成し、
メッセージループを抜けると SendMessasge は
仕事が終わる前に制御を返してしまいます。

最初は、SendMessage で呼び出し側のスレッドを
ブロックしたまま、仕事用のスレッドを起動し、
仕事が終了したら SendMessage のブロックを
解除できないかと考えたのですが無理っぽいです。

余談ですが、 ReplayMessage を使うと、
早期にブロックを解除することはできるみたいです。

話を戻して、SendMessage をブロックする方法は無さそうなので、
クライアント側から、サーバー側に同期オブジェクトを渡して、
クライアント側では、SendMessage 後に
同期オブジェクトが発火するまで待つことにします。

サーバー側では、仕事が終わった後で、
同期オブジェクトを発火させます。

同期は CreateEvent とかを使えばできます。

やはり、InheritHandle を TRUE にすると
親プロセスから子へ DuplicateHandle が不要になります。

・・・

x64 バージョンの公開はまだ先ですが、

日本語の最新版はこちらのページから、ダウンロードできます
You can download the latest version of Miruno PC Photoframe here.

ご意見・ご要望はこちらからどうぞ
You can contact me by this mail form.

・・・

文章にしても、やっぱ、長ーいな。

これで、技術的に難しそうなところは
クリアになったので、あとはコツコツですわ。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2017年12月12日(火)

libzip 最新版のコンパイルに手間取るの巻

写真閲覧ソフトのミルノ PC フォトフレーム を修正中。

写真をミルノに!

で覚えてね。キラーン。

とりあえず、使用しているライブラリーを
最新のものにするため、ソースコードを
ダウンロード、コンパイルしました。

なんとか、完了しましたが、
libzip のコンパイルには、手間取りました。

コンパイル手順を書いときますね。

cmake のインストール

コンパイルには cmake が必要なので、
あらかじめインストールしておきます。

zlib のコンパイル

libzip は、zlib を使用するので、
まずは zlib をコンパイルします。

X:¥Original¥cpp¥zlib¥ フォルダーの下の、
zlib-1.2.11 に最新の src を展開します。

コマンドラインで、zlib-1.2.11 に移動し、

mkdir build
cd build
cmake .. -G"Visual Studio 14 2015" -DCMAKE_INSTALL_PREFIX="X:¥Original¥cpp¥zlib¥installed"

を順に実行します。

作成した build フォルダーの下に zlib.sln
ができるので、Visual Studio で開きます。

私の場合は、zlib、zlibstatic プロジェクトのプロパティで、
構成プロパティ > C/C++ > ラインタイムライブラリを
DLL なしのやつに変更します。

すわわち、
デバッグ版: マルチスレッド デバッグ DLL > マルチスレッド デバッグ
リリース版: マルチスレッド DLL > マルチスレッド
です。

あとは、デバッグ版、リリース版、
それぞれで「ソルーションのリビルド」した後、
INSTALL プロジェクトをのみをリビルドすると、
X:¥Original¥cpp¥zlib¥installed に lib とかがコピーされます。

なんとなく、わかると思いますが、
zlib.lib が DLL を使うバージョン
zlibstatic.lib が DLL を使わないバージョン
zlibd.lib、zlibstaticd.lib はそれぞれのデバッグ版です。

libzip のコンパイル

だいたい、zlib と同じです。

X:¥Original¥cpp¥libzip¥ フォルダーの下の、
libzip-1.3.2 に最新の src を展開します。

コマンドラインで、libzip-1.3.2 に移動し、

mkdir build
cd build
cmake .. -G"Visual Studio 14 2015" -DCMAKE_PREFIX_PATH="X:¥Original¥cpp¥zlib¥installed" -DCMAKE_INSTALL_PREFIX="X:¥Original¥cpp¥libzip¥installed"

を順に実行します。

作成した build フォルダーの下に libzip.sln
ができるので、Visual Studio で開きます。

私の場合は、libzip、libzipstatic プロジェクトのプロパティで、
構成プロパティ > C/C++ > ラインタイムライブラリを
DLL なしのやつに変更します。

すわわち、
デバッグ版: マルチスレッド デバッグ DLL > マルチスレッド デバッグ
リリース版: マルチスレッド DLL > マルチスレッド
です。

あとは、デバッグ版、リリース版、
それぞれで「ソルーションのリビルド」した後、
INSTALL プロジェクトをのみをリビルドすると、
X:¥Original¥cpp¥libzip¥installed に lib とかがコピーされます。

ただし、libzip とは違い、デバッグ版、リリース版で
ファイル名が同じ zip.lib なので、リンクしたい
方のプロジェクトの INSTALL のみリビルドしましょう。

てな、感じで OK だと思うのですが
コンパイルエラーが発生してうまく行きません。

コンパイルエラーは、zip_libzip_version.c で発生。
LIBZIP_VERSION が定義されてないエラーです。

ソースを検索してみると、VERSION がそれっぽいので
LIBZIP_VERSION を VERSION にするとコンパイルできました。

cmake のバージョンの差異か、
オプションの違いかなんかでしょうね。

ちなみに、作成された zip.lib は
DLL 無しバージョンみたいですが、
今度は、リンクに失敗しました。

_imp_zip_close がありません。みたいなエラーです。

ZIP_EXTERN マクロが怪しいので zip.h の定義を見ると、
ZIP_STATIC を定義すれば OK そうです。

私は、zip.h をインクルードする前に、必ず
#define ZIP_STATIC するようにしましたが、
リンクするプロジェクトのプロパティの
構成プロパティ > C/C++ > プリプロセッサ にある
プリプロセッサの定義に、ZIP_STATIC を追加してもよいでしょう。

日本語の最新版はこちらのページから、ダウンロードできます
You can download the latest version of Miruno PC Photoframe here.

ご意見・ご要望はこちらからどうぞ
You can contact me by this mail form.

・・・

ちなみに、libpng もだいたい libzip と
同様の方法でコンパイルできましたよ。

ミルノ PC フォトフレーム
ミルノ PC フォトフレームのダウンロード
ミルノ PC フォトフレームの更新履歴
ご意見・ご要望連絡窓口


2017年12月04日(月)

「ドキュメント」の ITEMIDLIST を SHGetSpecialFolderLocation で取得すると、IShellFolder で列挙して取得できるものと違うみたい

今日も、 ローカルブラウザ の修正中。

ローカルブラウザは、自分のパソコンに保存されている
HTML ファイルなどを、効率よく表示するためのソフトです。

インターネットエクスプローラーみたいなものですが、
ウィンドウズエクスプローラーと同様のフォルダーツリーが
あるので、ローカルに保存されているファイルを簡単に開けます。

↑ 開発中の画面。

今日も、テストと不具合の修正です。

「ドキュメント」の ITEMIDLIST を
SHGetSpecialFolderLocation で取得すると、
IShellFolder で列挙して取得できるものと違う問題に対応しました。

何のこっちゃわからない人は、
このページに辿りつかない気がしますが、
一応、説明しときます。

「ドキュメント」は、エクスプローラーのツリーの
「PC」の下にある仮想フォルダーのこと。

ITEMIDLIST はファイルパスに近いですが、
ルート (一番の親) はデスクトップになっていて、
エクスプローラーのツリーの各項目の場所を
表すのに使うものです。ファイル名に対応するのが
ITEMID でパスに対応するのが、ITEMIDLIST です。

で、SHGetSpecialFolderLocation という API で、
ドキュメントの ITEMIDLIST を取得すると、
「PC」と「ドキュメント」をつないだ
ITEMIDLIST が取得できるのですが、
「ドキュメント」の方の ITEMID が、
「PC」の子を列挙して取得できる
ITEMID と違うものが返ってきます。

なんでかよくわかりませんが、困りますね。

SHGetSpecialFolderLocation のかわりに、
SHGetKnownFolderIDList という別の API を使用してみたり、
KF_FLAG_DEFAULT_PATH フラグを立てたり、立てなかったり、
色々と条件を変えてテストしてみたのですが、
列挙したときに取得できる方の ITEMID は取得できませんでした。

で、しょうがないので、別の方法を取りました。

まずは、普通に「ドキュメント」の
ITEMIDLIST を取得して、名前を取得します。

名前は、日本語環境だと「ドキュメント」ですが、
英語環境だと「Documents」になったりします。

次に親の ITEMIDLIST を計算し、
IShellFolder で子を列挙して、
同じ名前のものを探します。

で、見つかった場合は、その ITEMID を
ドキュメントの ITEMID として再構成します。

ローカルブラウザのダウンロードはこちら からどうぞ。

・・・

うーん。何でこんな
面倒なことになっちゃうんだろう。

謎だわ。

ローカルブラウザ
ローカルブラウザのダウンロード
ローカルブラウザの更新履歴
ご意見・ご要望連絡窓口


2017年09月25日(月)

静的変数の初期化タイミング

今日は、ピグアイランドタイマー
Visual Studio 2015 でコンパイルできるように修正してました。

で、静的変数のリストに要素を追加して、
後で使おうとしたら、空っぽだったので、ビックリしました。

こういう場合、よくあるのは、
同じものに追加してるつもりが
別のものに追加している間違いです。

確認するには、追加してる場所と、
使おうとして空になっている場所の
双方でブレークして、変数のメモリーアドレスを
比較するのが速いです。

今回は変数名が g_soilItems なので、
&g_soilItems をウォッチすれば OK。

・・・

同じですね。

ということは、追加した後
どこかでクリアーしてしまってるのかな
と思って、g_soilItems で検索してみても
空にしてる個所はありませんでした。

あり???

あ、ひょっとして静的変数の初期化のタイミングかも。

で、リストに追加するコードの実行を
遅らせてみると、無事直りました。まじか。

今回のエラーが起き条件は以下の通り。

静的にリンクするライブラリーで、
静的なリスト変数を定義。

ライブラリーをリンクするアプリケーションプログラムでも
静的変数を用意して、その変数のクラスの
コンストラクターで、静的なリスト変数に項目を追加です。

この場合、静的なリスト変数が先に初期化されれば
問題無いはずなので、おそらく、項目に追加するための
クラス変数が初期化された後で、静的なリスト変数が
初期化されたんだと思います。

うーん。なんかしらのエラーが発生しないもんかのー。不思議。

まぁ、そんなわけで、静的なグローバル変数の
初期化タイミングには気をつけた方がいいですね。

ブログ著者のホームページはこちら です。


| 1/4PAGES | >>