議題のスタートはDelphi側のフォーラムなのですが含んでいる要素が多いので
いったんここに書かせて貰います
Embarcaderoのフォーラムも含め適切な場所があれば指定をお願いします

○元ネタ
LightReport2 Unicode 版を 64bit 対応にしてみる
http://ht-deko.minim.ne.jp/delphiforum/?vasthtmlaction=viewtopic&t=1222.0

○状況
上記ソースを自パッケージに追加、C++BuilderXE3で利用
コンポーネントを利用するソースはBCB5からの移植

○その１：XE3にユニット出力ディレクトリの設定がない？
XE3にはDelphiユニットの出力ディレクトリの指定がありませんでした
今は仕方なくobj等の生成物を手動でコピーしました

○その２：複数のFormで使用した場合の問題
この問題はBuilderのTPrinterの仕様から昔のLightReport2から持ってる問題（と思います）
Printer()でアプリケーション内で１つだけインスタンスを作るらしいのですが
どうもこれがFormごとに独立している感じがします

で、LightReport2はCreate時にTPrinterのアドレスを保持するのですが
複数Formで使用していると片側が正しく動かない状態でした
BCB5の時はNkPrinterを併用してSetPrinterStatusを外から呼び出せるように改良していました
今回のunicode版だとBeginDocが無反応になるのでどうすればいいか悩んでます

○その３：SetPrinterとGetPrinterがぶつかる
これもBuilder側だけの仕様と思うのですがLightReportが抱えてるPrinterを触りにいくと
APIのSetPrinterとGetPrinterとかぶります
BCBの時はLRSetPrinterとLRGetPrinterに変更して対処してました

○その４：TPrinterの仕様の謎
これはLightReport2から外れてしまうのですが印刷前にDocInfoをすっぱり消してしまいます
消すのはいいですが消した後はTitleくらいしか書かないために印刷ジョブをファイル保存する
lpszOutputまでクリアされてしまいます
これの処理の意図が不明、Embarcaderoの方に書いたら改善される可能性あるのかなぁ
Delphiの初期からの仕様ですけど・・・・

○その５：用紙方向がリセットされる（※書き忘れ追加）
書き忘れてました、プロジェクトの読み直しをした時にプロパティの値にかかわらず
縦方向にリセットされます
LightReport2のGridPanelも以前から近い挙動がありました

情報や対策などがありましたらよろしくお願いします
またこの場所に不適切な書き込みでしたら指摘をお願いします

おはようございます

引用 a-and on 2013/07/07 18:30 Sun
○その２：複数のFormで使用した場合の問題
○その４：TPrinterの仕様の謎

引用 DEKO on 2013/07/07 20:57 Sun
ぐぅ…この辺りはあまり詳しくないので私にはわからないかもです。

一番の問題はBeginDocが無反応になる所ですね
これさえなんとかなれば当面は抜けれるのですが

TPrinterについてもPrinters.pasに手を入れないといけないので
いつかは根本的に解決したい所です

引用 a-and on 2013/07/07 18:30 Sun
○その３：SetPrinterとGetPrinterがぶつかる

引用 DEKO on 2013/07/07 20:57 Sun
これを変えてしまうと既存のアプリケーション (のソース) に影響を及ぼすので、ネームスペース指定で回避するしかないかもですね。
"コンポーネントインストール時 (のコンパイル) に発生する" という事であれば、どうにか対処したいと思います。

問題はコンパイル時では無くLightReport2のPrinterを触りに行った時に出ます
SetPrinterStatusを外から呼べるようにしたのもPrinterの値があやしい時に無理矢理同期させるためでした

引用 a-and on 2013/07/07 18:30 Sun
○その５：用紙方向がリセットされる（※書き忘れ追加）

引用 DEKO on 2013/07/07 20:57 Sun
Delphi でもそうなのかな？ちょっと調べてみます。

自分はコンポーネントの作法が解らないのですが何かのタイミングでコントロールのサイズを再調整している気がします
上記の用紙方向もプロパティでは正しい指定が入っているのにForm上のサイズがおかしくなります

同様にLRSubPanelもLRGridPanelからサイズを引っ張る所でおかしくなります
こちらはLightReport2の初期から発生していました
（SubPanelの初期サイズ取得だけ連携して後は動的に指定し直してました）

引用 a-and on 2013/07/07 18:30 Sun
またこの場所に不適切な書き込みでしたら指摘をお願いします

引用 DEKO on 2013/07/07 20:57 Sun
いえいえ、ここで大丈夫ですよ。不適切な書き込みだとは思いません…むしろ大歓迎です。

ありがとうございます
LightReport2の使用者(Builderのユーザ数的にｗ)を考えるとDelphi側の方が内容的に適切かとも思っていますが今回のようにBuilder側でしか出ない問題も含むためこちらに書かせて貰いました

「本来あるべき仕様」としては
・TPrinterのインスタンスを正しく掴む
・DocInfoの内容を勝手に消さない（これはTPrinterの仕様ですが）
この２つくらいでしょうか

LightReport2の(Delphiの)コアユーザがここで情報共有してくれることを期待してます♪

ちょっと納期に追われてました；；

引用 igy on 2013/07/14 09:55 Sun
BeginDocが無反応になりますか？
また、無反応というのは、具体的にはどのような状態になりますか？
（エラーメッセージもなく、キーも受け付けず、プログラムを強制終了するしかないような状態ですか？）

調査を続けていた所、無反応になるのはAdobePDFを選択していた場合に
特定のForm以外で印刷を行った時にのみ発生しました
同じ処理で通常のハードプリンターを選択した場合は正しく出力されていました

無反応についてはAdobePDFの出力ファイルの保存ダイアログが出ないでそのまま処理が続行される状態で
上記のように複数Formでの印刷処理においてメイン(正しく出力される)以外のFormでのみ発生する現象です

現状で行った対策は

・NkPrinterを追加
・NkPrinterでプリンタの初期化を行った後に複数Form間でなるべくTPrinterのアドレスを共用
　（LightReportのPrinterをBuilderで外から扱えるように改造）
・改造したTPrinter経由でDocInfoによる保存ファイルの指定

これでPDFの保存ダイアログは出なかった処理も正しく動作しました
でも相変わらず複数Formで使用した場合のTPrinterの振る舞いにもやもやしたままです
Printer()を最初に呼んだ時に共通のインスタンス生成ってのをどこまで信用してよいのやら・・・