2017-11-07 16 views
0

私のアプリケーションでは、複数のドキュメントを開いて、印刷ダイアログウィンドウでプロンプトが表示されたときに "Microsoft print to pdf"オプションを使用してすべてのドキュメントをPDFに印刷できます。コピー先のフォルダを選択します。さて、印刷のために選択された30のドキュメントがある場合、実行するたびに、不一致の量が目的のフォルダのpdfに正常に印刷されます。時にはすべてが成功し、それ以外の時はありません。私は、このようなpdfプロセスを含むコードファイルと同じディレクトリに作成されている、この "敥敥敥敥敥敥敥敥like"のようなUnicode文字名のファイルを見つけました。私はこれらのファイルを ".pdf"拡張子で名前を変更することができ、彼らはpdfドキュメントを操作しています。ここでGDI Print API StartDoc関数の結果が矛盾しています

は、関係するコードの一部です:

DOCINFO docInfo; 

memset(&docInfo, 0, sizeof(docInfo)); 
docInfo.cbSize = sizeof(docInfo); 
docInfo.lpszDocName = csPlanoName; 
docInfo.lpszOutput = csOutputDir + csPlanoName + csExtension; 

if(dc.StartDoc(&docInfo) > 0) { 

    //printing process continues 
} 

私は敥敥敥敥敥敥敥」コードのステップにより、StartDoc関数呼び出しが同じUnicode文字にdocInfo.lpszOutputを変更するだろうことがわかりました敥 "。これは常に起こるとは限らず、テスト時には特定のファイルでは発生しません。 1つのドキュメントがpdfに正常に印刷されることをテストし、同じドキュメントで別のテストが実行され、 "敥敥敥敥敥敥敥敥name"という名前のファイルが作成されます。

これについてのお手伝いがあれば幸いです。

よろしく、 クリス

+0

https://msdn.microsoft.com/en-us/library/awkwbzyc.aspx#_core_using_cstring_as_a_c.2d.style_null.2d.terminated_string –

+0

おかげで、私が働いて、それを持って前にこれを見ていました。 – Hawkzee

答えて

0

文字列変換マクロを使用して私の問題を解決したようですが、結果は10回以上成功しました。

CString csFullpath = csOutputDir + csPlanoName + csExtension; 
docInfo.lpszOutput = CT2W(csFullpath); 
+1

実際には、あなたの問題は、範囲外になった一時的な文字列のバッファを使用したことによって引き起こされました。そして、適切な変数 'csFullpath'として格納するので、十分に長く存続します。 – VTT

+0

マクロを使わずに上記を試したので、同じ問題に遭遇したので、私はそうは思わない。 – Hawkzee

0

csPlanoNamecsOutputDir何ですか? docInfo.lpszDocNamedocInfo.lpszOutputはヌルで終了する文字列へのポインタでなければならず、通常のポインタでは機能しないcsOutputDir + csPlanoName + csExtensionを使用しているので、ここで何か他のことが起きている可能性があります。 csOutputDir + csPlanoName + csExtensionの結果が暗黙的にポインタにキャストされておらず、スコープから外れていないことを確認してください。

+0

'csPlanoName'は' csOutputDir'はCString変数です – Hawkzee

+0

ありがとう@VTTあなたの答えは私の思考の方向性を変えました。 – Hawkzee

関連する問題