カテゴリー別

お絵描き、デザイン

写真、動画関連ソフト

アメーバピグ専用ソフト

ホームページ関連

画像処理

スキャナー用

SEO 関連

お楽しみ

その他

過去ログ

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 に設定します。

難しくはないわな。

ご意見・ご要望連絡窓口


2017年08月15日(火)

win32、php で、base64 エンコード、デコードするには

今日も、こつこつコーディングしてたのですが、
特に、書くことも無いので、API の情報でも。

win32 API で、base64 エンコードするには、
CryptBinaryToString
base64 デコードするには、
CryptStringToBinary
を使います。

フラグには、CRYPT_STRING_BASE64 を指定すれば OK です。

ToString の方では、改行コードが挿入されますが、
CRYPT_STRING_NOCRLF も指定すると無しにできそうです。
(今、発見したので、試してない。やってみよっ)

一方、php で、base64 エンコードするには、
base64_encode
base64 デコードするには、
base64_decode
を使います。

ご意見・ご要望連絡窓口


2017年08月14日(月)

c++、http / https で php に接続 (その2)

c++ で暗号化したデーター (RSA) を php に送信し、
php でデコードするテストコードができました。

予想通りとはいえ、結構、時間かかったな〜。

HttpSendRequest を非同期で呼びだした場合、
なぜか、ヒープを破壊することがあって、
その破壊が自分のコードが原因じゃないことを
ある程度、確信するのに時間がかかりました。

そんなわけで、HttpSendRequest の挙動はかなり怪しいので
HttpSendRequestEx を使った方がいいよーな気がします。

もう一つは、x-www-form-urlencoded 形式で
フォームデーターを送った場合に、+ がスペースに
化けてたりすることに気づくのに少し手間取りました。

なんとなく、気持ち的に base64 エンコードしてるんだから
普通に送れるだろうと思いこんでいたのですが、
base64 エンコードに使用される記号 +、/、= は
3 つとも、URL には使用できない文字でした!

・・・

全然、だめじゃん^^

ご意見・ご要望連絡窓口


2017年08月08日(火)

http / https で php に接続

今日は、c++ コードから、http / https で
php に接続するテストコードを作成しました。

WinInet というライブラリーを使えばいいのですが、
真面目にやると、結構なコード量になります。

http / https の切り替え個所は 2 つ。

1 つ目は、InternetConnect で接続するポートを
INTERNET_DEFAULT_HTTP_PORT (http の場合)
INTERNET_DEFAULT_HTTPS_PORT (https の場合) にする。

2 つ目は、HttpOpenRequest のフラグに、
https の場合は、INTERNET_FLAG_SECURE を加える。

です。後は共通のコードで OK みたいですね。

で、フォームデーターをポストする部分ですが、ヘッダーで
Content-Type: application/x-www-form-urlencoded
を指定して、それっぽいデーターを送れば OK です。

現在のテストコードでは、
HttpAddRequestHeaders で、ヘッダーを指定してから
HttpSendRequest で、ポストデーターを書き込みでうまくいってます。

SendRequest にもヘッダーを指定する引数が
あるので、そこで指定してもよさそうです。

ところが、HttpSendRequest のかわりに、
HttpSendRequestEx してから、
InternetWriteFile でポストデーターを
書き込む方法がうまくいきません。

まぁ、うまくいく方法を使えばいいんですけど、
なんか釈然としないなー。

・・・

もちっと調べてみるかな。

・・・

追記
----
で、調べてみたら原因がわかりました。

php の方で、var_dump(getallheaders()); して
違いを見てみると、HttpSendRequestEx の方では、
Content-Length が 0 になってたので、
Write する予定のデーターサイズをヘッダーに加えると
あっさり、うまくいきました。

なるほどね。

ご意見・ご要望連絡窓口


2017年08月07日(月)

c++、RSA の鍵を XML 形式で出力するには?

今日は、c++ で RSA の鍵ペアーを
XML 形式で出力する方法を調べました。

c# だと、 RSACryptoServiceProvider::ToXmlString
で生成できるやつです。

結論からいうと、できました。

が、ずばりの関数とかは無さそうなので
自分でフォーマットする必要があります。

ちなみに、c# < - > c++ 間で
鍵を交換するだけなら、BLOB 形式ってのを
使うと、簡単にできます。

c# では、
RSACryptoServiceProvider::ExportCspBlob
RSACryptoServiceProvider::ImportCspBlob

c++ では、
CryptImportKey
CryptExportKey
を使います。

で、本題の XML 形式での出力方法ですが、
この BLOB 形式がほぼ XML 形式での表現
と一対一で対応する値を持つので、
フォーマットして出力すれば OK です。

結構なコード量になったりしますが、
必要な方のためにヒントだけ書いときますね。

値は、base64 エンコードして出力しますが
XML での出力はビッグエンディアン形式なので、
エンコード前に数値のバイトオーダーを逆転します。

Exponent の数値は、DWORD (4 バイト) ですが、
3 バイトで納まる数値が使われているため、.NET では、
3 バイトの数値を、base64 エンコード出力してるみたいです。

別に、4 バイトのままエンコードしても
読み取ってくれそうですが .NET の出力に合わせるには、
不要な上位バイトを削る必要があるようです。

以上。

あ、BLOB の内部形式はココ にありますよ。

ご意見・ご要望連絡窓口


2017年03月21日(火)

GetGlyphOutline で取得できる GLYPHMETRICS の性質について、調査終了

前の記事 の続きです。

私のパソコンにインストールされている全てのフォントの
全ての文字について GetGlyphOutline する実験が終了しました。

やはり、得られるグリフを - gmptGlyphOrigin.x + 1
平行移動すると、図形の描かれる x 座標を 0 以上にできました。

もちろん、未知のフォントでそうならない可能性もありますが、
gmptGlyphOrigin.x の定義からいって、そうならないとしたら、
フォントか OS の不具合と考えてよさそうです。

次に、- gmptGlyphOrigin.x + 1 平行移動したグリフの x 座標が、
常に、gm.gmBlackBoxX + 2 以下になるかのテストもしました。

これについてはならないフォントが見つかりましたが、
やはり、gm.gmBlackBoxX の定義からいって、
OS か フォントの不具合と考えてもよさそうです。

で、そうならないフォントは、@Malgun Gothic、
ハングル文字用のフォントみたいですね。(@ なので縦書き用)

うまくいかない文字は、U+302E、U+303E。
それぞれ、文字コード表によると、
Hangul Single Dot Tone Mark、
Hangul Double Dot Tone Mark。

このページ にある、去声、上声 記号だと思われます。

ま、縦書き用のフォントだし、
現在ではあんまり使われない記号っぽいですね。

ちなみに、この実験は、 文字に縁取りするノ の改良のために行いました。

文字に縁取りするノは文字や文章を画像に一括変換するソフト
です。 ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

で、この実験結果を受けて、文字に縁取りするノを
ちょっとだけ高速化する予定です。お楽しみに〜。

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年03月17日(金)

GetGlyphOutline で取得できる GLYPHMETRICS の性質について、またまた調査

前の記事 で、再調査した GetGlyphOutline ですが、今度は
インストール中の全てのフォントについて調べてます。

まだ、途中ですが、次のようなことがわかりました。

ABC の abcA と、GetGlyphOutline で得られる gmptGlyphOrigin.x
は、ほとんどの文字で同じですが、全然違う値の場合がありました。

なのでおそらく GetGlyphOutline で得られるグリフの出力位置は、
- gmptGlyphOrigin.x + abcA で求めるのがよさそうです。

次に、全てのフォントでの調査が終わっていませんが、
得られるグリフを - gmptGlyphOrigin.x + 1 並行移動すると、
グリフの座標を常に 0 以上にできるっぽいです。

ちなみに、- abcA + 1 ではダメな文字が結構見つかりました。

さらに、そのときの、グリフの幅は、gmBlackBoxX + 2 で抑えられる
かと思いきや、ダメな (大幅にはみだす) 文字もありました。

ちなみに、この実験は、文字に縁取りするノ
の改良に必要なのでやってます。

文字に縁取りするノは文字や文章を画像に一括変換するソフト
です。 ホームページとかで気軽にカラフルな文字を
使ってみたい人は、是非、お試しあれ♪#

最新版は、こちらのページからダウンロードできます

うーん。なかなか複雑。

アラビア語の出力処理とか
作る人はもっと大変なんでしょうね〜。

文字に縁取りするノ
文字に縁取りするノ - ダウンロード
文字に縁取りするノ - 更新履歴
ご意見・ご要望連絡窓口


2017年03月14日(火)

ディスプレイの GetDeviceCaps の DPI、変じゃない?

わけあって、ディスプレイのデバイスコンテキストの
DPI 回りを調べてるんだけど、何かおかしいような。

GetDeviceCaps(LOGPIXELSX) で得られる DPI と、
HORZSIZE、HORZRES から計算される DPI が違いすぎない?

うちの環境だと、得られる DPI は 96 なのに、
計算される DPI は、92 あたりです。

↓ 実験の出力結果

531mm = 1920px 96/91.8418 DPI
299mm = 1080px 96/91.7458 DPI

↓ 実際のプログラム、抜粋

CClientDC dc(NULL);
const double INCH_MM = 25.4;
 
CSize sizeMm, sizePx, sizeDpi;
sizeMm.cx = dc.GetDeviceCaps(HORZSIZE);
sizeMm.cy = dc.GetDeviceCaps(VERTSIZE);
sizePx.cx = dc.GetDeviceCaps(HORZRES);
sizePx.cy = dc.GetDeviceCaps(VERTRES);
sizeDpi.cx = dc.GetDeviceCaps(LOGPIXELSX);
sizeDpi.cy = dc.GetDeviceCaps(LOGPIXELSY);

double dpiX = (double)sizePx.cx / ((double)sizeMm.cx / INCH_MM);
double dpiY = (double)sizePx.cy / ((double)sizeMm.cy / INCH_MM);

std::wcout
  << sizeMm.cx << L"mm = "
  << sizePx.cx << L"px"
  << L" " << sizeDpi.cx << L"/" 
  << dpiX << L" DPI" << std::endl;

std::wcout
  << sizeMm.cy << L"mm = "
  << sizePx.cy << L"px"
  << L" " << sizeDpi.cy << L"/" 
  << dpiY << L" DPI" << std::endl;

うーん、何でやねん?
わかる人いたら、コメントでも残してね。

ご意見・ご要望連絡窓口


| 1/3PAGES | >>