カテゴリー別

お絵描き、デザイン

写真、動画関連ソフト

アメーバピグ専用ソフト

ホームページ関連

画像処理

スキャナー用

SEO 関連

お楽しみ

その他

過去ログ

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 で検索してみても
空にしてる個所はありませんでした。

あり???

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

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

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

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

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

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

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

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

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


2017年09月22日(金)

HEAP CORRUPTION DETECTED エラーの修正

今日は、メディアからファイルを移動するノ
Visual Studio 2015 でコンパイルできるように修正してたら、
HEAP CORRUPTION DETECTED エラーが発生しました。

assert した場所のソースを見ると確保した
メモリーサイズを超えて書いちゃってるみたいです。
バッファーオーバーランってやつですね。

プログラム終了時の delete で落ちてたんですが、
それだと、どこらへんがおかしいのかわからんので
とりあえず、_CrtCheckMemory しまくる作戦にでました。

ATLASSERT(_CrtCheckMemory());

原理的には、1 行置きに _CrtCheckMemory すれば
メモリーが壊れた場所が特定できるわけですな。

今回の場合は、あやしい個所がある程度、特定できてたので、
2 分探索的に、トラップをしかけていくと 1 行が特定できました。

で、不具合の原因は、静的リンク用のライブラリーのコンパイル時と、
アプリケーションのコンパイル時とで、NOTIFYICONDATA 構造体
のサイズが違うのが原因でした。

↓ 例えば、ヘッダー (.h) は、こんな感じで、

class CShellNotifyIcon
{
  CShellNotifyIcon();
protected:
  NOTIFYICONDATA m_data;
};

↓ 実装 (.cpp) がこんな感じだと、

CShellNotifyIcon::CShellNotifyIcon()
{
  ::ZeroMemory(&m_data, sizeof(NOTIFYICONDATA));
}

あんまり、よくないです。

というのも、上記のコードをコンパイルするときと
アプリケーション (それを使う側) をコンパイルするときの
_WIN32_WINNT 等が違う場合、ヘッダーは両方のコンパイル時に
解釈されるので、構造体のサイズが、コンパイル毎に変わります。

結果、アプリケーションをコンパイルしたときの、
NOTIFYICONDATA サイズが小さい場合は、
バッファーオーバーランになります。

.cpp ファイルの sizeof(NOTIFYICONDATA) はライブラリ
コンパイル時のサイズですが、ヘッダーで定義されている
NOTIFYICONDATA はアプリのコンパイル時のサイズになるからです。

簡単に解決するには、ライブラリーとアプリケーションで
完全に _WIN32_WINNT 等を一致させることですが、
あまりよい解決法ではありませんね。

普通に、間違えるのが人間だし、全てのアプリケーションの
ターゲット OS を同じにできるとは限らないからです。

・・・

まぁ、いい解決方法は 2 つくらいあるかな。

1 つは、アプリケーションコンパイル時の
sizeof(NOTIFYICONDATA)
をライブラリーに渡して賢く処理する方法。

もう 1 つは、アプリケーションコンパイル時の
NOTIFYICONDATA の定義は絶対に使わない方法です。

後者は例えば、ヘッダーでは、std::vector m_data
みたいなサイズ可変のデーター領域を定義しておいて、
.cpp で m_data.assign(sizeof(NOTIFYICONDATA), 0);
みたいにして使えば、ライブラリーコンパイル時の
定義のみに依ったコードにできますね。

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


2017年09月19日(火)

Visual Studio 2005、error LNK2019: 未解決の外部シンボル __vsnwprintf

下記エラーが発生したときの対処方法です。

1>DxErr.lib(dxerrw.obj) : error LNK2019: 未解決の外部シンボル __vsnwprintf が関数 "long __stdcall StringVPrintfWorkerW(unsigned short *,unsigned int,unsigned int *,unsigned short const *,char *)" (?StringVPrintfWorkerW@@YGJPAGIPAIPBGPAD@Z) で参照されました。

DxErr.lib のリンク時に発生しますが、同様のエラーは
他のライブラリーでも発生する可能性があるでしょう。

DxErr.lib で使用されている StringVPrintfWorkerW 関数が、
Visual Studio 2015 でリンクされる標準ライブラリーには
含まれていないために発生します。

解消するには、エラーの発生するプロジェクトのプロパティの
構成プロパティ > リンカー > 入力 ページ内にある
追加の依存ファイルに、legacy_stdio_definitions.lib を追加します。

もちろん、プラグマで指定しても OK です。

#pragma comment(lib, "legacy_stdio_definitions.lib")

・・・

前に別のプロジェクトをビルドするときにも発生したのですが
直し方を忘れてて、また調べ直しちゃったわ。

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


2017年09月15日(金)

fatal error LNK1241: リソース ファイル XXX.res は既に指定されています

静的リンク用ライブラリーのプロジェクトにリソースファイルを
追加したら、ブログタイトルのエラーが発生しました。

ググると静的リンク用ライブラリーに
rc ファイルを 2 つ以上追加すると、
発生するみたいですね。

Resources in static library question

読めばわかりますが、プロジェクトのプロパティを開き、
リソース > 全般 ページにある「カルチャ」「リソースファイル名」
を空にすると直るとかいてあります。

で、自分の環境でも、直りました。
Microsoft Visual Studio Community 2015 です。

・・・

お試しあれ。

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


2017年08月18日(金)

簡単な XML を読み書きするクラス

今日は簡単な xml を書いたり
読んだりするコードを書きました。

真面目にやるには、IXMLDOMNode とかを使うとよいのですが、
あまりにも簡単な XML の読み書きに使うのも、
何だな〜 と思って、てきとーなクラスを書いてみました。

↓ こんな感じ。

class CSimpleXmlWriter : public CSimpleXmlParser
{
public:
  CSimpleXmlWriter();
  ~CSimpleXmlWriter();

  void Open(const wstr& path, const str& rootTag);
  void Write(const str& tag, const str& value);
  void Close();

protected:
  std::ofstream m_out;
  str m_rootTag;
};

書ける XML は 1 つのルートタグからなるやつで、
Write で直属の子ノードを書けるだけです。

Open でルートノードの開始タグを書いて、
Close で終了タグを書けば OK です。

デストラクターでも、一応、Close() を呼びだすので、
終了タグを 2 回書き込まないように、m_out.is_open()
のときに終了タグを書いて、m_out.close() します。

ま、なんとなく実装できるでしょ。

読み込みの方も似たようなインタフェースを用意し、
Open でファイルをメモリーに全部読み込んじゃいます。

で、Read (Write の逆のやつ) では開始タグと終了タグを検索して
その間の値を、value に設定します。

難しくはないわな。

ご意見・ご要望連絡窓口


<< | 3/6PAGES | >>