プレビューウィンドウが背面に移動してしまう
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
ISHIJIMA
居住地: 静岡県
投稿数: 1827
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
キャンセルの後に実行しているのですよね
それでだめであればプロクラムの構造を考え直した方がよいかもしれませんね・・・
それでだめであればプロクラムの構造を考え直した方がよいかもしれませんね・・・
投票数:0
平均点:0.00
k_noguchi
投稿数: 7
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
ISHIJIMA さん返信ありがとうございます。
SetWindowFocusは気付かなかったので試してみました。
もともとの構造が良くないせいか、登録の一連処理の最後に追加してみた状態では最前面の表示にはなりませんでした。
確認として、タイマーイベントの処理でSetWindowFocusを実行してみたところ、
プレビューウィンドウ表示->入力フォームが前面に表示される->プレビューウィンドウが前面に表示される
という状態になったので、関数自体は正常に動作しているが、実行される順序が想定通りにならないという状態のようです(画面表示がちらつく点を許容できれば問題ないのですが)。
何はともあれ、情報提供ありがとうございました。
時間が出来たら、もう少し深く検証してみたいと思います。
SetWindowFocusは気付かなかったので試してみました。
もともとの構造が良くないせいか、登録の一連処理の最後に追加してみた状態では最前面の表示にはなりませんでした。
確認として、タイマーイベントの処理でSetWindowFocusを実行してみたところ、
プレビューウィンドウ表示->入力フォームが前面に表示される->プレビューウィンドウが前面に表示される
という状態になったので、関数自体は正常に動作しているが、実行される順序が想定通りにならないという状態のようです(画面表示がちらつく点を許容できれば問題ないのですが)。
何はともあれ、情報提供ありがとうございました。
時間が出来たら、もう少し深く検証してみたいと思います。
投票数:0
平均点:0.00
Tanda
投稿数: 2151
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
ISHIJIMAさん、お久しぶりです。
いいですね。2.3からの新しい関数ですね。
いいですね。2.3からの新しい関数ですね。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
SetWindowFocus('Magic 印刷プレビュー')を使用してはいかがでしょうか
投票数:1
平均点:10.00
k_noguchi
投稿数: 7
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
顛末として報告させていただきます。
レポートの作成・プレビューウィンドウ表示処理を更新の一連処理から切り離し、タイマで起動する事で取り敢えずそれらしい動作になりました。
タイマイベントを作成して条件に論理型変数を設定
1.伝票番号などのパラメタを変数に退避
2.更新処理を実施
3.タイマ処理を有効にするよう変数を更新
4.タイマイベントで印刷処理呼び出し
5.タイマイベントでタイマ処理を無効にするよう変数を更新
タイマ間隔が処理に追いついてしまうと、また背面へ移動してしまったり、今後のバージョンでどのように動作するか心配で満足な対応策とは思えませんが、他に考えられる対応策と比較して今回はこの状態で提供する事にしようと思います。
レポートの作成・プレビューウィンドウ表示処理を更新の一連処理から切り離し、タイマで起動する事で取り敢えずそれらしい動作になりました。
タイマイベントを作成して条件に論理型変数を設定
1.伝票番号などのパラメタを変数に退避
2.更新処理を実施
3.タイマ処理を有効にするよう変数を更新
4.タイマイベントで印刷処理呼び出し
5.タイマイベントでタイマ処理を無効にするよう変数を更新
タイマ間隔が処理に追いついてしまうと、また背面へ移動してしまったり、今後のバージョンでどのように動作するか心配で満足な対応策とは思えませんが、他に考えられる対応策と比較して今回はこの状態で提供する事にしようと思います。
投票数:0
平均点:0.00
k_noguchi
投稿数: 7
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
mokomoko101さん御返答ありがとうございます。
返答が遅くなりまして大変失礼しました。
ご指摘の通り、キャンセルイベントを実行しなければプレビューウィンドウが背面へ移動することはありません。
遅ればせながら、ざっくりと実施している内容を説明させていただきますと
1.売上伝票を入力して登録する
2.登録した伝票をプレビュー画面で表示する
2-1.入力内容の更新処理
2-2.レポートの作成・プレビューウィンドウ表示
2-3.入力画面を初期状態に戻して次の操作に備える(キャンセルイベント実行)
3.次の伝票を入力するまたは画面を終了する
このような状態です。
キャンセルイベントを省略するとVarMod関数の戻り値がFalseを返してくれない等で不都合が発生している状態で……。
一般的ではない構造なのかもしれませんが、uniPaaSまでは想定通り動作していたので、できれば同じ動作を実現したいと思っていました。
Magic社からも動作が変わったことは認知しているという返答をいただき、一度は対応可能かを検討していただいたようでしたが、本日これは制限事項となる見込みだという返答を受けました。
私の思いつく対処として
1.プレビュー機能を廃止して直接印刷する。
2.プレビューウィンドウを表示した後で、オペレータにキャンセルイベントを実行してもらう。
3.プレビューウィンドウが背面に移動する仕様に変わった事にする。
どれも利用者の評価を落としそうだと思っています。
ほぼ見切り時と考えていますが、外部ツールの利用やプログラム構造の変更等の情報をいただけて今後の参考にできればとも思っております。
何か情報・考えをお持ちでしたら教えていただけると有難いです。
返答が遅くなりまして大変失礼しました。
ご指摘の通り、キャンセルイベントを実行しなければプレビューウィンドウが背面へ移動することはありません。
遅ればせながら、ざっくりと実施している内容を説明させていただきますと
1.売上伝票を入力して登録する
2.登録した伝票をプレビュー画面で表示する
2-1.入力内容の更新処理
2-2.レポートの作成・プレビューウィンドウ表示
2-3.入力画面を初期状態に戻して次の操作に備える(キャンセルイベント実行)
3.次の伝票を入力するまたは画面を終了する
このような状態です。
キャンセルイベントを省略するとVarMod関数の戻り値がFalseを返してくれない等で不都合が発生している状態で……。
一般的ではない構造なのかもしれませんが、uniPaaSまでは想定通り動作していたので、できれば同じ動作を実現したいと思っていました。
Magic社からも動作が変わったことは認知しているという返答をいただき、一度は対応可能かを検討していただいたようでしたが、本日これは制限事項となる見込みだという返答を受けました。
私の思いつく対処として
1.プレビュー機能を廃止して直接印刷する。
2.プレビューウィンドウを表示した後で、オペレータにキャンセルイベントを実行してもらう。
3.プレビューウィンドウが背面に移動する仕様に変わった事にする。
どれも利用者の評価を落としそうだと思っています。
ほぼ見切り時と考えていますが、外部ツールの利用やプログラム構造の変更等の情報をいただけて今後の参考にできればとも思っております。
何か情報・考えをお持ちでしたら教えていただけると有難いです。
投票数:0
平均点:0.00
mokomoko101
居住地: 大阪
投稿数: 53
![常連 常連](../../uploads/rank3dbf8e9e7d88d.gif)
こんにちは。
いまさらですが、みんな見てるのにだーれも検証/返信もしないchicken guysだらけなので、参加させていただきます。
間違えるのが怖くて手が出せないのでしょうかね?
…さて、キャンセルイベントのヘルプをみると、
「レコードをキャンセルすると、レコードに入り直すため[レコード前]ロジックユニットが実行されます。」
とあります。
つまり、プレビュー画面表示後にキャンセルイベントでレコード前処理を再度実行し、その際に再度画面表示が行われるから、上かぶせでプレビュー画面が背面へ行ってしまうのではないでしょうか。
間違っておりましたら、ご指摘お願い致します。
首を突っ込んだので、お互いに納得するまでいきますよ〜b
いまさらですが、みんな見てるのにだーれも検証/返信もしないchicken guysだらけなので、参加させていただきます。
間違えるのが怖くて手が出せないのでしょうかね?
…さて、キャンセルイベントのヘルプをみると、
「レコードをキャンセルすると、レコードに入り直すため[レコード前]ロジックユニットが実行されます。」
とあります。
つまり、プレビュー画面表示後にキャンセルイベントでレコード前処理を再度実行し、その際に再度画面表示が行われるから、上かぶせでプレビュー画面が背面へ行ってしまうのではないでしょうか。
間違っておりましたら、ご指摘お願い致します。
首を突っ込んだので、お互いに納得するまでいきますよ〜b
投票数:0
平均点:0.00
k_noguchi
投稿数: 7
![新米 新米](../../uploads/rank3e632f95e81ca.gif)
XPAのプレビューウィンドウがXPAのフォームウィンドウの背面
に移動してしまう現象で悩んでいます。
大雑把には下記の処理を行っていますが、プレビューウィンド
ウが背面へ移動する現象を回避する事は可能なものでしょうか?
XPA Version 2.3b PT3
--前提
MagicV8からのマイグレーションでRM互換ロジックあり
親タスクの
フォームにヘッダ項目の変数を貼り付け
循環入力:YES
子タスク
フォームテーブルコントロールに入力用一時テーブル
の明細項目貼り付け
印刷タスク
ウィンドウ表示:No
--
子タスクの明細入力終了後、親タスクのプッシュボタン
に指定した実行イベントで更新処理を実行
1.ヘッダ項目の変数値を入力用一時テーブルに書込む
2.入力用一時テーブルの内容を保存用のテーブルに書き込む
3.印刷タスクで入力した内容を印刷するプレビューウィンドウを表示
4.キャンセルイベントを実行
上記の処理で3.キャンセルイベントを実行するとプレビュー
ウィンドウが背面へ移動してしまいます。
参考までに3と4の実行順を入れ替えるとキャンセル処理が実行
されない様でした。
1.ヘッダ項目の変数値を入力用一時テーブルに書込む
2.入力用一時テーブルの内容を保存用のテーブルに書き込む
3.キャンセルイベントを実行
4.印刷タスクで入力した内容を印刷するプレビューウィンドウを表示
に移動してしまう現象で悩んでいます。
大雑把には下記の処理を行っていますが、プレビューウィンド
ウが背面へ移動する現象を回避する事は可能なものでしょうか?
XPA Version 2.3b PT3
--前提
MagicV8からのマイグレーションでRM互換ロジックあり
親タスクの
フォームにヘッダ項目の変数を貼り付け
循環入力:YES
子タスク
フォームテーブルコントロールに入力用一時テーブル
の明細項目貼り付け
印刷タスク
ウィンドウ表示:No
--
子タスクの明細入力終了後、親タスクのプッシュボタン
に指定した実行イベントで更新処理を実行
1.ヘッダ項目の変数値を入力用一時テーブルに書込む
2.入力用一時テーブルの内容を保存用のテーブルに書き込む
3.印刷タスクで入力した内容を印刷するプレビューウィンドウを表示
4.キャンセルイベントを実行
上記の処理で3.キャンセルイベントを実行するとプレビュー
ウィンドウが背面へ移動してしまいます。
参考までに3と4の実行順を入れ替えるとキャンセル処理が実行
されない様でした。
1.ヘッダ項目の変数値を入力用一時テーブルに書込む
2.入力用一時テーブルの内容を保存用のテーブルに書き込む
3.キャンセルイベントを実行
4.印刷タスクで入力した内容を印刷するプレビューウィンドウを表示
投票数:0
平均点:0.00