過去の桐井戸端ＢＢＳ　（桐ver.９）

20009	印刷時にだけ使う項目を作ったがたくさんあるのでこれをなくしたい	しぼうかん	2003/04/17-19:02
えーと質問は最後の方にあります。 abc.tbl 連番|種|NO.|数|頁|a番|a頁|b番|b頁|c番|c頁| １ |ａ|001|10|１| １| １| ０| １| ０| １| ２ |ａ|002|12|１| ２| １| ０| １| ０| １| ３ |ｂ|101|23|１| ２| １| １| １| ０| １| ４ |ｂ|102|15|１| ２| １| ２| １| ０| １| ５ |ａ|003|39|２| ３| ２| ２| １| ０| １| ６ |ｃ|201|14|１| ３| ２| ２| １| １| １| ７ |ｃ|202|28|１| ３| ２| ２| １| ２| １| ８ |ｂ|103|22|２| ３| ２| ２| ２| ２| １| ９ |ｂ|104|11|２| ３| ２| ２| ２| ２| １| [連番]の項目計算式 ※#直前値([連番],0)+1 [a番]の項目計算式 ※#cond([種]="ａ",#直前値([a番],0)+1,1,#直前値([a番],0)) [a頁]の項目計算式 ※[a番]を#cond(#MOD([a番],2)=0,[a番]/2,1,#INT([a番]/2)+1) [頁]の項目計算式 ※#CASE(#対応番号("ａ,ｂ,ｃ",[種]),[ａ頁],[ｂ頁],[ｃ頁]) abc.wfm 『連続この種印刷』 種　|ａ | NO. |001|　　『この種印刷』 数　|10 | 頁　|１ | −−−−−−−−−−−−− 種　|ａ | NO. |002| 『この種印刷』 数　|12 | 頁　|１ | −−−−−−−−−−−−− 種　|ｂ | NO. |101| 『この種印刷』 数　|23 | 頁　|１ | −−−−−−−−−−−−− 種　|ｂ | NO. |102|　　『この種印刷』 数　|15 | 頁　|１ | −−−−−−−−−−−−− 種　|ａ | NO. |003|　　『この種印刷』 数　|39 | 頁　|２ | 『この種印刷』のコマンドボタンには次のイベントが記述してあります。 メソッド呼び出し　@フォーム.更新モード設定(0) 行マーク定義　1 置換　[連番] ジャンプ　行マーク　=　1 代入　&種　=　[種] 代入　&頁　=　[頁] 絞り込み　[種]　=　&種 置換　[連番] 絞り込み　[頁]　=　&頁 レポート印刷　"abc.rpt",　プレビュー　=　する 絞り込み解除　1 絞り込み解除　1 置換　[連番] ジャンプ　行マーク　=　1　,終了状態　=　&ok 行マーク解除　1 手続き定義終了 abc.wfmの各レコードにある『この種印刷』ボタンを押したときに 印刷されるabc.rpt(明細繰り返しの数"２"の伝票形式)のイメージです。 １レコード目のボタンを押したときのabc.rptプレビュー −−−−−−−− 連番|種|NO.|数| −−−−−−−− １ |ａ|001|10| −−−−−−−− ２ |ａ|002|12| −−−−−−−− 合計(a1頁) |22| −−−−−−−− ２レコード目のボタンを押したときのabc.rptプレビュー −−−−−−−− 連番|種|NO.|数| −−−−−−−− １ |ａ|001|10| −−−−−−−− ２ |ａ|002|12| −−−−−−−− 合計(a１頁)|22| −−−−−−−− ３レコード目のボタンを押したときのabc.rptプレビュー −−−−−−−− 連番|種|NO.|数| −−−−−−−− １ |ｂ|101|23| −−−−−−−− ２ |ｂ|102|15| −−−−−−−− 合計(b１頁)|38| −−−−−−−− ４レコード目のボタンを押したときのabc.rptプレビュー −−−−−−−− 連番|種|NO.|数| −−−−−−−− １ |ｂ|101|23| −−−−−−−− ２ |ｂ|102|15| −−−−−−−− 合計(b１頁)|38| −−−−−−−− ５レコード目のボタンを押したときのabc.rptプレビュー −−−−−−−− 連番|種|NO.|数| −−−−−−−− １ |ａ|003|39| −−−−−−−− ２ |　|　 |　| −−−−−−−− 合計(a２頁)|39| −−−−−−−− abc.tblの[a番],[a頁],[b番],[b頁]等はabc.rpt印刷時に使う[頁]の値を求める為だけに作っている項目で、 また項目数が多すぎるので出来れば無くしたいと思っています。 質問内容は、このabc.tblファイルの[a番],[a頁]などの項目を減らす、 何かうまい方法は無いでしょうか？ということです。 よろしくお願いします。 実際のabc.tblファイルにはa番とa頁を１セットとして60セット120以上の項目があり、 abc.rptファイルの明細繰り返し数も20ありその他、 もうすこしごちゃごちゃしていますが質問の要点に関係がないと思う部分は省略し、 簡略化しました。 なおこのabc.tblファイルのレコード数は2500を超えることはありません。 ※追伸.ちなみにこの質問は最近よく質問している販売管理関係の質問とは 全く関係がありません。
20012	Re:項目数を減らしたい（タイトル例）	悲しげ	2003/04/17-21:19
記事番号20009へのコメント TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 連番|種|NO.|数|頁|a番|a頁|b番|b頁|c番|c頁| １ |ａ|001|10|１| １| １| ０| １| ０| １| ２ |ａ|002|12|１| ２| １| ０| １| ０| １| ３ |ｂ|101|23|１| ２| １| １| １| ０| １| ４ |ｂ|102|15|１| ２| １| ２| １| ０| １| ５ |ａ|003|39|２| ３| ２| ２| １| ０| １| ６ |ｃ|201|14|１| ３| ２| ２| １| １| １| ７ |ｃ|202|28|１| ３| ２| ２| １| ２| １| ８ |ｂ|103|22|２| ３| ２| ２| ２| ２| １| ９ |ｂ|104|11|２| ３| ２| ２| ２| ２| １| abc.tblの[a番],[a頁],[b番],[b頁]等はabc.rpt印刷時に使う[頁]の値を求める為だけに作っている項目で、 また項目数が多すぎるので出来れば無くしたい LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 最終的には、挙げられた条件を満たすように[頁]の値を出せばいいと云うことだけで考えてみます。 試しに項目計算式を一切使わない方法をひとつ。 １）ひとつだけ[仮番]なる数値系項目を用意。 ２）まず[種]について並べ替えを実行します。 連番|種|NO.|数|頁|a番|a頁|b番|b頁|c番|c頁|仮番 １ |ａ|001|10|１| １| １| ０| １| ０| １| ２ |ａ|002|12|１| ２| １| ０| １| ０| １| ５ |ａ|003|39|２| ３| ２| ２| １| ０| １| ３ |ｂ|101|23|１| ２| １| １| １| ０| １| ４ |ｂ|102|15|１| ２| １| ２| １| ０| １| ８ |ｂ|103|22|２| ３| ２| ２| ２| ２| １| ９ |ｂ|104|11|２| ３| ２| ２| ２| ２| １| ６ |ｃ|201|14|１| ３| ２| ２| １| １| １| ７ |ｃ|202|28|１| ３| ２| ２| １| ２| １| ３）この状態で、次の置換を実行。 [仮番]=#cond([種]<>#直前値([種],""),1,1,#直前値([仮番],0)+1) \ ,[頁]=#ceil([仮番]/2) ４）並べ替え解除して[連番]で置換。置換計算式は３つ考えられます。 　　　#行番号 　　　#直前値([連番],0)+1 　　　#連番 ＊ これらの置換を「置換条件」に登録して随時利用する方法もありますし、 あるいは履歴に登録しておいてcmdかkevに流用することもできます。 以上のやり方なら、追加項目はただひとつ[仮番]のみで済むように思えます （[a番]〜[c頁]等も不要）。 ただし、これは[頁]の値を算出するところまでで、それ以降のやりたいことは、 すいません、解読への気力が出ませんでした。(^^;)
20013	余談ながら	悲しげ	2003/04/17-21:28
記事番号20012へのコメント 投稿した際に、連続する複数の半角スペースがひとつの半角スペースに置き換えられることは知っていましたが、 行頭の半角スペースは除去されるんですね。 これは初めて知りました（あるいはすっかり忘れていました）。
20027	新タイトル「項目数を減らしたい」	しぼうかん	2003/04/18-19:05
記事番号20012へのコメント 悲しげさん、いつもお世話して頂きありがとうございます。 早速、教えて頂いた事を参考にテスト中です。 現在の方式である項目計算式を持つ多数の項目を使う方法では行挿入で入力を開始した時点で 正しい[頁]がフォーム上に表示されるのですが、 置換用のボタンを使う方法では押し忘れが発生してしまうので、編集後に必ず発生する 行挿入終了イベントや行訂正終了イベント(テストは行訂正終了イベントでやってみました)で 更新モードを表示状態に変更させて、さらに教えて頂いた計算式を表の[頁]と[種]の 項目計算式に設定しておいてレコード数1600件項目数67で置換コマンドを実行してみました。 これでうまくいったのですが２秒近くかかってしまいました。 入力作業完了後にイベントで表示状態に戻すのであれば２秒ぐらいの待ち時間は問題ないのですが、 このフォーム上では入力作業途中に"一旦表示状態にしてまた訂正をするという事を 繰り返す事が多いので２秒近くの待ち時間はイライラしてしまいます。 そこで、とりあえず表の項目計算式をはずして、イベントのみで#直前値や置換をやってみようと 以下の通り記述して見たのですが、カーソルが終端行へ移動して"処理対象行がありません"とエラーメッセージがでて、 さらに[仮番]に&仮番2＋１の値が代入されておらずうまく行きません。 手続き定義開始　フォーム::行訂正終了(長整数　&明細番号，長整数　&モード) 行マーク定義　1 メソッド呼び出し　@フォーム.更新モード設定(0) 並べ替え　{[種]昇順} 繰り返し(.not　#eof) method　@種.ソース値取得(&種1,0) ジャンプ　行番号=前行 method　@種.ソース値取得(&種2,0) method　@仮番.ソース値取得(&仮番2,0) ジャンプ　行番号=次行 ケース開始 ケース(&種1><&種2) 行訂正　[仮番]=1　 */この行が原因で"処理対象行が・・・"とエラーが出ます。 行訂正　[頁]=1 ケース(&種1=&種2) 行訂正　[仮番]=&仮番2+1 行訂正　[頁]=#ceil((&仮番2+1)/2) ケース終了 繰り返し終了 解除　* ジャンプ　行マーク=1 行マーク解除　1 手続き定義終了 そこで原因究明の為もうしばらくイベントでする方法をやってみてから、 もう一度報告したいと思います。
20037	印刷のページ割りに必要なデータ項目	佐田　守弘	2003/04/18-23:20
記事番号20009へのコメント しぼうかんさん 最初に書かれている部分を良く理解できたわけではないのですが、 印刷時のページ割りなどに使うデータ項目をどの様に持つべきかとの課題と解釈してコメントします。 実は私もページ割りのための項目を持っているものがあります。 シェアウエアで公開している名刺管理の中にそれがあるはずですが、 簡単に言うと、A4版の用紙を１枚ずつ２つ折りにし、２つ折りの紙を 重ねて折った部分に糊付けした時に、本の様に左からページ順に並べたいというページ割りです。 これは大変に複雑で、表に左から4,1ページ、 裏には左から2,3ページの順で割付けなければならないわけです。 しぼうかんさんと同じで、概ね1,000件近いレコードを、 ページごとにグルーピングし、かつ、それを印刷ページの順で並べ替える訳です。 私はこの処理に、[連番][頁][印刷順][面]の４項目を使っています。 私の考えですが、この様なバックで処理をするためのデータでも、 それを項目として持つ事は間違ってはいないと考えています。 もちろん、項目を少なくする事も必要ですが、複雑な計算式を考えるのに 苦労するのであれば、中間項目を項目値で持つのも、必ずしも間違っているとは思いません。 要は、自分の力量に合わせて、考えやすく、間違いを見つけやすく、 必要な時に訂正がやりやすい方法がベストです。 申し添えますと、私の方法では、上記の項目に項目計算式を設定し、 計算項目として値を自動的に求める事をしています。 イベントで行っているのは、それらの計算項目の再計算の指示だけです。 これは私が良く言う事ですが、 ・各種の処理は可能な限り表の定義の中に組み込む。 ・イベントなどで行うのは、表定義でできない部分だけを補助的に行う。 のためです。 言い換えれば、マニアックな難しい方法ではなく、初心者向けの基本的な方法でもあります。 また、フォームにデータを表示しながら、イベントで各行を逐次計算する処理は案外と時間が掛ります。 計算は項目計算式に任せ、フォームを開く時や、１レコード入力後に再計算させる方が、 処理時間も短いと思います。 佐田守弘(KS-00119)
20038	「項目数を減らしたい」ではなかった？	悲しげ	2003/04/19-00:09
記事番号20027へのコメント どもっ、しぼうかんさん、 すいません。 先にも書いたとおり、私が解読できたのは[頁]の値を算出するところまでです。 それ以上は、#20009も#20027も、そもそも何をしたいのかが、殆ど解読できませんでした。 特に、#20027なんかは全然「項目数を減らしたい」と云う中身でもないので、 タイトルのつけ方も外していたらしいことも含めて、私としてはここまでとさせて戴きたく。<(_ _)>
20040	Re:新タイトル「項目数を減らしたい」	桐野港	2003/04/19-02:32
記事番号20027へのコメント しぼうかんさん　こんばんは >そこで、とりあえず表の項目計算式をはずして、イベントのみで#直前値や置換をやって >みようと以下の通り記述して見たのですが、カーソルが終端行へ移動して"処理対象行が >ありません"とエラーメッセージがでて、さらに[仮番]に&仮番2＋１の値が代入されてお >らずうまく行きません。 > >手続き定義開始　フォーム::行訂正終了(長整数　&明細番号，長整数　&モード) >行マーク定義　1 >メソッド呼び出し　@フォーム.更新モード設定(0) >並べ替え　{[種]昇順} >繰り返し(.not　#eof) >method　@種.ソース値取得(&種1,0) >ジャンプ　行番号=前行 >method　@種.ソース値取得(&種2,0) >method　@仮番.ソース値取得(&仮番2,0) >ジャンプ　行番号=次行 >ケース開始 >ケース(&種1><&種2) >行訂正　[仮番]=1　 */この行が原因で"処理対象行が・・・"とエラーが出ます。 >行訂正　[頁]=1 >ケース(&種1=&種2) >行訂正　[仮番]=&仮番2+1 >行訂正　[頁]=#ceil((&仮番2+1)/2) >ケース終了 >繰り返し終了 >解除　* >ジャンプ　行マーク=1 >行マーク解除　1 >手続き定義終了 どんな処理をしたいのか解かりませんが、このイベントのエラーの原因は並べ替えのあと 処理対象行が先頭に来ますが、その位置でジャンプ　行番号=前行を　実行しますと終端行に 移動してしまいます。これが原因です。 それから　この繰り返しでは　ジャンプ　前行　と次行の往復だけでエラーがでなければ 終わりの無いループ状態に陥ります。 先頭行の行位置判断と、１行戻って２行前進すれば　エラー回避できると思います。
20095	またご迷惑をお掛けしました＆ありがとうございました。	しぼうかん	2003/04/21-19:16
記事番号20038へのコメント 今回はうまく説明出来たとひそかに思っていたのですが・・・ やはり全然ダメだったみたいです。 やりたい事は確かに実際の作業としては"項目数を減らしたい"であっているのですが、 項目を減らす方法を実行後に減らした項目が果たしていた役割を完全に代替しなければなりません。 その方法を求める為に必要不可欠な"減らそうとしている項目の役割"の説明が 不十分だったみたいです。 その上[ｂ頁]と[ｃ頁]の付け方に問題もありました。 これではイメージがうまく伝わらないのも仕方が無いです。 "今の項目を減らして[頁]の値を算出するだけでなく、その算出される[頁]の値が [種]入力後すぐに算出され無ければならないという隠れた条件がある事に気がつきませんでした。 前回よりうまく説明出来るように工夫はしたのですが・・・ せっかくのアドバイスも説明不足で無駄骨を折らせてしまいすいませんでした。 m(_ _)m
20096	ありがとうございました。	しぼうかん	2003/04/21-19:19
記事番号20040へのコメント 桐野港さんはじめまして、こんばんは。 教えて頂いたポイントを修正して 手続き定義開始　フォーム::行訂正終了(長整数　&明細番号，長整数　&モード) 行マーク定義　1 メソッド呼び出し　@フォーム.更新モード設定(0) 並べ替え　{[種]昇順} 行訂正　終了状態=&cok,[仮番号]=1 行訂正　終了状態=&cok,[頁]=1 ジャンプ　行番号=次行 繰り返し(.not#eof) method　@種.ソース値取得(&種1,0) ジャンプ　行番号=前行 method　@種.ソース値取得(&種2,0) method　@仮番.ソース値取得(&仮番2,0) ジャンプ　行番号=次行 ケース開始 ケース(&種1><&種2) 行訂正　終了状態=&cok,[仮番]=1 行訂正　終了状態=&cok,[頁]=1 ケース(&種1=&種2) 行訂正　[仮番]=&仮番2+1 行訂正　[頁]=#ceil((&仮番号2+1)/2) ケース終了 ジャンプ　行番号=次行 繰り返し終了 解除　* ジャンプ　行マーク=1 行マーク解除　1 手続き定義終了 先頭行で　ジャンプ　行番号=前行　を実行すると最終行に移動するとはしりませんでした。（何でだろう？） そこで以上の様に書き換えてやってみるとうまくいきました。 しかしこのイベントをやってみると佐田先生もおっしゃっているとおり各行を逐次計算する処理は案外と時間が掛かりました。（３０秒） そこで、残念ながらこのイベントの実用化は諦めました。 現在の方法は項目は多いのですが、かかる時間は[種]入力後瞬間に[頁]の値が出るので、 これまで通りの方法でやっていくことにします。 ただ助言のおかげでテストの為にこのイベント作成に悩む時間を大幅に短縮することが出来ました。
20097	今まで通りの方法でやる事にしました＆ありがとうございました。１	しぼうかん	2003/04/21-19:24
記事番号20037へのコメント 自分ではうまく説明したつもりだったのですが、悲しげさん、桐野港さん、にも よく理解できない分かりにくい説明だった様です。 さらに[c頁]と[b頁]の値の設定にも誤解を招く様な誤りがありました。 これじゃうまく理解してもらえなくても当たり前ですね。 最初の説明時には簡略化の為abc.tblに有る[種]はa,b,c,dの４つ、abc.rptの明細 繰り返し数は２としていましたが、実際は[種]の種類は受注先分の32種類あり、 abc.rptの明細繰り返し数は20です。 そこで、印刷時の頁割とはちょっと違ってまして、う〜ん、もう一度より現物に 近い別パターン（省略しないで最初からこの図のほうがよかったのかも？）で説明しますと、 ある特定の商品(１種類）の受注を管理する表がありまして、受注先（３２社）ごとに [種]を区別して割付て受注順に001,002または101,102のように番号を付けて 受注を管理する表に入力していき、その受注を管理する表（１つです）から受注先に 区別して割付けた[種]で絞りこんで受注先毎の受注台帳（Ａ４用紙に20件の受注明細有り）を 印刷するときにその受注先毎の受注台帳につける頁の連番をつけたかったのです。 そこで別の表を使って説明し直してみると例えば abc.tbl 連番|種|NO.　|　数|頁|ａ番|ａ頁|ｂ番|ｂ頁|ｃ番|ｃ頁| 　１|ａ|001　|　20|１|　１|　１|　０|　０|　０|　０| 　２|ａ|002　|　10|１|　２|　１|　０|　０|　０|　０| 　３|ｂ|101　|　20|１|　２|　１|　１|　１|　０|　０| 　４|ａ|003　|　10|１|　３|　１|　１|　１|　０|　０| 　５|ａ|004　|　10|１|　４|　１|　１|　１|　０|　０| 　６|ｂ|102　|　20|１|　４|　１|　１|　１|　０|　０| 　７|ａ|005　|　10|１|　５|　１|　１|　１|　０|　０| 　８|ａ|006　|　10|１|　６|　１|　１|　１|　０|　０| 　９|ａ|007　|　10|１|　７|　１|　１|　１|　０|　０| １０|ａ|008　|　10|１|　８|　１|　１|　１|　０|　０| １１|ａ|009　|　10|１|　９|　１|　１|　１|　０|　０| １２|ａ|010　|　10|１|１０|　１|　１|　１|　０|　０| １３|ａ|011　|　10|１|１１|　１|　１|　１|　０|　０| １４|ａ|012　|　10|１|１２|　１|　１|　１|　０|　０| １５|ａ|013　|　10|１|１３|　１|　１|　１|　０|　０| １６|ｂ|103　|　20|１|１３|　１|　１|　１|　０|　０| １７|ａ|014　|　10|１|１４|　１|　１|　１|　０|　０| １８|ａ|015　|　10|１|１５|　１|　１|　１|　０|　０| １９|ａ|016　|　10|１|１６|　１|　１|　１|　０|　０| ２０|ａ|017　|　10|１|１７|　１|　１|　１|　０|　０| ２１|ａ|018-1|　10|１|１８|　１|　１|　１|　０|　０| ２２|ａ|018-2|　20|１|１９|　１|　１|　１|　０|　０| ２３|ａ|019　|　10|１|２０|　１|　１|　１|　０|　０| ２４|ａ|020　|　10|２|２１|　１|　１|　１|　０|　０| ２５|ａ|021　|　10|２|２２|　１|　１|　１|　０|　０| abc.wfm 総合受注台帳入力フォーム 　|種|ａ|NO.|001　| １|社名|あいう�梶b　　[印刷] 　|頁|１| −−−−−−−−−−−−−− 　|種|ａ|NO.|002　| ２|社名|かきく�掛　　［印刷］ 　|頁|１| −−−−−−−−−−−−−− 　|種|ｂ|NO.|101　| ３|社名|さしす�掛　　［印刷］ 　|頁|１| −−−−−−−−−−−−−− このテーブルを対象表とする"明細部を３分割した伝票フォーム"の各分割部分に １つ、合計３つの印刷ボタンを作り、このボタンを押した時にそのレコードの [種]と[頁]の値を変数にとってその変数で[種]と[頁]を絞り込み印刷します。 例えば[連番]が２２が表示されているレコード部分にある印刷ボタンを押すと abc.rptには次の様に印刷されます。 abc.rpt 連番|種|NO.　|　数| 　１|ａ|001　|　20| 　２|ａ|002　|　10| 〜〜〜〜〜〜〜〜〜 〜〜〜〜〜〜〜〜〜 １８|ａ|018-1|　10|　 １９|ａ|018-2|　20| ２０|ａ|019　|　10| 合計 　 　　 | 220| 　頁(ａ−１) また[連番]２４が表示されているレコード部分にある印刷ボタンを押すと次の様に印刷されます。 abc.rpt 連番|種|NO.　|　数| 　１|ａ|020　|　10| 　２|ａ|021　|　10| 〜〜〜〜〜〜〜〜〜 〜〜〜〜〜〜〜〜〜 １８|ａ| 　 |　 |　 １９|ａ| 　|　 | ２０|ａ| 　|　 | 合計 　 　 　| 20| 　頁(ａ−２)
20098	今まで通りの方法でやる事にしました＆ありがとうございました。２	しぼうかん	2003/04/21-19:27
記事番号20037へのコメント NO.20097での説明でもうまく伝わったかどうかは甚だ自信がないのですが、 この様な、"特定の項目でグループ化（桐の機能名ではない）して印刷する"ときの グループごとに頁に連番をつける"処理は普通によくある処理の様な気がするのですが、 やはり皆さん項目計算式を使っているということなんでしょうね。 ＞もちろん、項目を少なくする事も必要ですが、複雑な計算式を考えるのに苦労 ＞するのであれば、中間項目を項目値で持つのも、必ずしも間違っているとは思 ＞いません。 この説明に少し安心してとりあえず、いまのままで（残念ですが）行くことにします。 ＞また、フォームにデータを表示しながら、イベントで各行を逐次計算する処理 ＞は案外と時間が掛ります。 桐野港さんの返答にも書きましたがイベントで実行してみた所、まさにその通りでした。 前回よりうまく説明出来るよう工夫はしたのですが・・・ いつもの事ながら訳のわからない説明でご迷惑をお掛けしました。
20099	[頁]は何のため？	悲しげ	2003/04/21-21:14
記事番号20009へのコメント 中味の細部には言及できませんので、どちらかと云うと外側めいた感じでコメントします。 [頁]と云うのは、印刷する頁のことだと思います（ですよね？）。 で、印刷と云うのは、それなりに時間がかかります（数秒以上）。 とすれば、通常は、印刷に使う頁数の算出*1からプリンタでの実印刷の過程*2は連続していますから、 所要時間としては、*2が*1を吸収して余りあること（いわゆる律速段階）が多いと思います。 （そもそも解読できていないので）誤読の可能性の方が高いけれども(^^;)、 しぼうかんさんがやろうとしていることは、１レコード入力する度に （いつの日か印刷に使うであろう）[頁]の値を算出しているように見えます。 この[頁]値の算出に際しては、全レコード（あるいは前後の少なからぬレコード）を 総洗いする必要があるのだとすれば、時間がかかるのは当然です。 果たして、１レコード入力する度に、[頁]値を出す必要があるのでしょうか？ 全くの的外れを恐れずに云えば、私なら、[頁]値は個々のレコード 入力の際には算出させず、印刷する前に一括して取得させてそのまんま実印刷に持ち込むと思います。 一般的にはそれで十分かと。 もしかしたらしぼうかんさんは、[頁]なるものに、 印刷ではない何らかの独自な意義を付与しているのかもしれませんが・・・・。
20104	Re:[頁]は何のため？	悲しげ	2003/04/21-23:45
記事番号20099へのコメント 一部訂正します。 《訂正前》 [頁]と云うのは、印刷する頁のことだと思います（ですよね？）。 で、印刷と云うのは、それなりに時間がかかります（数秒以上）。 とすれば、通常は、印刷に使う頁数の算出*1からプリンタでの実印刷の過程*2は連続していますから、 所要時間としては、*2が*1を吸収して余りあること（いわゆる律速段階）が多いと思います。 《訂正後》 [頁]と云うのは、印刷する頁のことだと思います（ですよね？）。 で、印刷と云うのは、それなりに時間がかかります（数秒以上）。 とすれば、もし印刷に使う頁数の算出*1からプリンタでの実印刷*2の過程が連続しているなら、 所要時間としては、*2が*1を吸収して余りあること（いわゆる律速段階）が多いと思います。 私はよくこの錯覚を利用しています。
20107	Re:ありがとうございました。	桐野港	2003/04/22-14:19
記事番号20096へのコメント しぼうかんさん　こんにちは >先頭行で　ジャンプ　行番号=前行　を実行すると最終行に移動するとはしりませんでした。（何でだろ >う？） おそらく書き間違いと思いますが、最終行ではなく終端行に移動します。 最終行と終端行は１行違うだけですが、一括処理等での行の処理の仕方がまったく異なりますので チョット気になりました。
20111	Re:終端行対策	悲しげ	2003/04/22-18:44
記事番号20107へのコメント ちなみに私はよく次のようにしています。 　　条件(#行番号>1) ジャンプ　行番号=前行 とか 　　条件(#行番号<#総件数) ジャンプ　行番号=次行 とか。
20113	はて？何の為でしょう（ボケモード）	しぼうかん	2003/04/22-20:29
記事番号20099へのコメント 根気強いお返事有り難うございます。 悲しげさんがNO20099で書いて頂いた私の投稿に関しての解釈は全てあっています。 しかし昨日の時点では１レコード入力する度に[頁]の値を出さなければならないと思い込んでいました。 [頁]の値を[種]入力後すぐに求めなければ成らない訳はフォーム上に[頁]が 表示されている為です。これがNO.20095で述べた隠れた条件でした。 しかしなぜフォーム上に[頁]が必要なのかをじっくり考えてみて、 例えばあるレコードを修正した場合そのレコードを含む頁を再印刷する時の頁指定の為だったのかなと思ったのですが、 別に頁指定をしなくてもその修正したレコードを含む頁を印刷する事さえ出来ればいいのですから、 印刷ボタンを押した時に項目置換をしてそのレコードに正しい[種]と[頁]を代入して、 [種]と[頁]の値を変数に取り、その値で絞り込んで印刷すれば、 印刷する頁が何頁で有るかは意識する必要が無いことになります。 なぜフォーム上に[頁]を配置したのか当時（１年前）の事を思い出そうとして見たのですが、 頭の中のデータベースソフトの復活機能は壊れている様でダメでした。 たぶん印刷用に求めた[頁]を余り苦労なくフォーム上にも配置出来るので、 無いよりましという理由で配置しただけなのかもしれません。 そこでフォーム上に[頁]を表示しなければ成らない理由が無くなったので [頁]はフォーム上から削除することにしました。 という事は[種]入力後直ちに[頁]を表示する必要もなくなったことになります。 という訳で最初に悲しげさんに教えて頂いたことを参考にして置き換え条件に登録する代わりに、 [仮番]の項目計算式に#cond([種]<>#直前値([種],""),1,1,#直前値([仮番],0)+1) [頁]の項目計算式に#ceil([仮番]/2) と書いて印刷のコマンドボタンを押した時にイベントの中で再計算をさせる方法でいくことにしました。 （この場合は２秒ぐらいの待ち時間は全く問題ないので） 本来なら悲しげさんの最初のお返事で問題解決のはずだったのが、 自分で問題をよく把握していなかったために自分や答えて頂いた皆さんを混乱させてしまいました。 どうもすいませんでした＆一件落着のつもりです。
20114	ありがとうございました。２	しぼうかん	2003/04/22-20:58
記事番号20107へのコメント 桐野港さん、文字校正ありがとうございます。 >おそらく書き間違いと思いますが、最終行ではなく終端行に移動します。 はい、書き間違えました。 同じ処理をするのにイベントのみでやると３０秒かかりテーブルの 項目計算式を併用する場合では２秒でした。 結構時間が違いました。 そこで今回はイベントのみで"置換"をするのは止めて 項目計算式を併用して置換する方法にしました。
20115	余談です。	しぼうかん	2003/04/22-20:59
記事番号20111へのコメント 今回の投稿とは関係ないのですが、少し前の投稿で全ての計算式をはずして イベントでやったらどうなるんでしょう？と質問していたのですが、 さっそくイベントのみでやるよりもテーブルの計算式を使った方が良いパターンを 体験してしまいました。(^_^)
20117	Re:余談です。	悲しげ	2003/04/22-23:58
記事番号20115へのコメント >今回の投稿とは関係ないのですが、少し前の投稿で全ての計算式をはずして >イベントでやったらどうなるんでしょう？と質問していたのですが、さっそ >くイベントのみでやるよりもテーブルの計算式を使った方が良いパターンを >体験してしまいました。(^_^) 「今回の投稿とは関係ない」とのことですから、では何のことに ついての言及なのかは藪の中ってことになりますが・・・(^^;) もし、もしも「今回の投稿とは関係」あって「イベントのみでやるよりもテーブルの計算式を使った方が良いパターン」と 感じたのであれば、私は全くそうは感じませんでした。 単に、イベントの書き方がたまたまよくなかっただけのことではないか、とか。(^^;) あ、しぼうかんさんがイメージする「テーブルの計算式」ってのは、 もしかすると独特なものだったのかもしれませんが、 ここでは普通に考えて「項目計算式」のことだとします。 とすれば、しぼうかんさんが「イベント？」vs「項目計算式」として立てた命題は、 実は「非計算項目」vs「項目計算式」に置き換えることができるのではないか……とちょっと深読みしてしまいました。 とすれば、何だか違うんじゃないかな〜と云うことで、 少し書いておきます。 例えば、私が#20012では、なぜ項目計算式を使わず、非計算項目として置換の計算式を使ってみたかと云うと、 複数の並べ替え状態において#直前値関数を使ってみたからです。 #直前値の返り値は、並べ替えの状態によって全く変わって来ますから。 項目計算式でこれを設定している場合には、並べ替えの状態が変わることによって、 全く予期せぬ再計算結果を招いてしまう危険 と隣り合わせであることを意識しておく必要があります。 このことがひとつ。 もうひとつは、項目計算式の置換（再計算）と、置換条件等を使っての非計算項目の置換とは、 速さは（前者が微かに速いかもしれませんが）殆ど変わらないだろうことを付記しておきます。 この点、承知の上だろうとは思いつつ、もしかしたら誤解しているかもしれないので。(^^;) 総じて、もしこの度の「非計算項目」vs「項目計算式」において、 「項目計算式」に分があったと見なしているのならば、 それは勘違いではないだろうか？ これが結論です、老婆心ながらの。 ※なお「非計算項目」の方が優れていると主張している訳ではありません。組み方次第です。
20122	為になる余談でした。	しぼうかん	2003/04/23-20:17
記事番号20117へのコメント >項目計算式でこれを設定している場合には、並べ替えの状態が変わること >によって、全く予期せぬ再計算結果を招いてしまう危険と隣り合わせである >ことを意識しておく必要があります。 私が項目計算式を使った方法をとったのは処理時間も変わらないなら単純に "置換条件"という場所に計算式を登録するより、項目計算式に書いた方が 計算式の記述場所がわかりやすくて後でメンテナンスもしやすいかな？ という単純な理由でした。 どんな時に危険なのかはぼんやりとしか想像出来てはいないのですが、 #直前値関数などを使った項目が有る場合その項目の値が 崩れてしまうことによる危険回避の為に項目計算式を使わなかったという 深い訳がある事はわかりました。 という訳で項目計算式に記述するのをやめて"項目計算式＋イベント方式"から "置換条件＋イベント方式"に替えました。 >イベントのみでやるよりもテーブルの計算式を使った方が良いパターンを >体験してしまいました。(^_^) これはNO.20096で私が書いたイベントとNO.20113で書いた項目計算式をつかう方式を比較して （一般的な比較ではなくてこの場合のみに限定）書いた つもりで「非計算項目」vs「項目計算式」というつもりではなかったのですが、 たぶん、またいつもの様に私の書き方が誤解を与えるような書き方になっていたのだと思います。 余談のつもりだったのにまた勉強させてもらいました。
20123	Re:為になる余談でした。	悲しげ	2003/04/23-21:01
記事番号20122へのコメント >どんな時に危険なのかはぼんやりとしか >想像出来てはいないのですが、 例えば[No]に 　#cond([某]<>#直前値([某],""),1,1,#直前値([No],0)+1) なる項目計算式が設定されていたとします。 併せて、[FLAG]の項目計算式が 　#ceil([No]/2) のように[No]値に依存するものだったとします。 この時、並べ替えが[某]について昇順であった場合、[No]等の値は次のようになります。 [某]　[日付]　[No]　[FLAG] Ａ　　４／１　　１　　１ Ａ　　４／３　　２　　１ Ａ　　４／８　　３　　２ Ａ　　４／９　　４　　２ Ｂ　　４／２　　１　　１ Ｂ　　４／４　　２　　１ Ｂ　　４／５　　３　　２ 並べ替えがたまたま[日付]について昇順となっていた場合は、次のようになります。 [某]　[日付]　[No]　[FLAG] Ａ　　４／１　　１　　１ Ｂ　　４／２　　１　　１ Ａ　　４／３　　１　　１ Ｂ　　４／４　　１　　１ Ｂ　　４／５　　２　　１ Ａ　　４／８　　１　　１ Ａ　　４／９　　２　　１
20137	めでたし、めでたし。	しぼうかん	2003/04/24-19:01
記事番号20123へのコメント 悲しげさん、わざわざ実例を挙げて頂きありがとうございました。 よくわかりました。(^_^)v

戻る