| ホームへ戻る｜Data Base 桐 User Board｜過去ログ一覧｜検索｜プロパティ ｜ほっ！ |
| ▼過去ログ No98 |
| 書き込み数 : 4900件 |
|
|
|
||||||||||||
|
>表 "salary.tbl" >読み込み条件登録 表,条件名="salary","salary.xvw",* >読み込み 表,条件名="salary" 横着者の本人です。 上記ですんなり実行できるので、すっかり忘れていました。 大抵、不具合らしきものはＫ３に連絡しているのですが と言い訳しつつ・・・ |
|
|
|
||||||||||||
|
一応，サポートに連絡したら確認したとの回答は頂きました。 皆さん，ちゃんと気付いた時にはサポートに連絡しておきま しょう！ (^^; 当時の私と言えば，まだ桐9は体験版で試していた時代であり サポートを受ける権利が無かったので，報告も出していな かったのですよね・・・ いくら，ここを K3 の方々が興味深く見ていると言っても？ だれも権限を持ち，自分で気付いた事は処置するって言う？ 気持ちでは見られていないので，正式なルートで報告され ない限り誰も責任は持って対応はしてくれないと思います。 ;-) と言う事で，不可解な現象やバグと思われる現象を発見した ら，積極的にサポートへ！ そして質を良くしてもらいま しょう！ (^^; |
|
|
|
||||||||||||
|
がぁ〜ん！ http://www2u.biglobe.ne.jp/~s_tanaka/cgi-bin/bbs/bbs.cgi?function=logview_html&no=69#3417 上記メッセージ関連で出た 「KD1557:ドライバ内部エラー20(接続ハンドルの異常)」 ですが，桐ver9sp1 でもエラーは同じでした！ (;_;) バグは直されなかったみたい？ 「桐9-2004」では どうなのでしょう？ 条件登録して使う方法は 桐ver9sp1 でも有効です。 熊本帯山在住の柳田でした。 (^^) |
|
|
|
||||||||||||
|
一晩過ぎて、よく考えてみると、お上の言い分は何だかおかしい。 #4888で挙げられたサイトで述べられていることの関心の中心は、 要するに「節税」（つまり預かり消費税を少なめに納税できるよ うな）制度の３年間存続（経過措置）の問題でした。 で、総額表示に全く未対応なレジはシステムを変更しなさい、と いうのはまあいいとして、次に、完全に（？）総額表示に対応し たレジなら「節税」の経過措置は認めないことになるのも、まあ いいとします。問題なのは、中途半端（？）にしか総額表示に対 応していないレジは、３年間の「節税」を経過措置的に認めると 云うことになります。 となると、敢えて、完全対応ではなく、中途半端な総額表示対応 のレジを使おう（開発しよう）、っつーことにはならないのだろ うか？(?_?) |
|
|
|
||||||||||||
|
>内税にする際に・・・・便乗値上げ？されそうだなあ。 どもっ、うにんさん、 強度なデフレ下で、強気に値上げできる業種が果たしてどれくらいあるだろうか？ 私はどちらかと云うと「便乗値下げ」が起きるのではないか、と心配しています。 例えば（税別で）９８０円だの２９８０円だのと云った、いわばネゴロ感で設定 されていた商品が、税込表示ではそれぞれ１０２９円だの３１２９円にスライド できるかどうか？ せいぜいが、１０００円とか３０００円どまり、場合によっ ては税込でも９８０円・２９８０円のまま据え置き（つまり５％弱の値下げ）に 動くものが出てくるのではないか？ 私んところの対応は、これまた４月以降の様子見でメジャーに合わせようと思っ てはいますが。 |
|
|
|
||||||||||||
|
今までは外税だったので >「税抜価格」を基に計算：150円×２個×1.05＝315円 だったものが、内税にする際に四捨五入にされて 「税込価格」を基に計算：158円×２個＝316円 に便乗値上げ？されそうだなあ。 |
|
|
|
||||||||||||
|
云い換えると、ある商品がＡ店では総額100円、Ｂ店では総額101円、Ｃ店では 総額99円であれば、価格志向な消費者は、内税の丸め方式に関係なく総額99円 の店で買うだろうし、 また別な商品がＡ店でもＢ店でも総額100円だとしたら、価格志向な消費者とし てはどっちの店で買っても同じことです。たとえその商品の内税額が、Ａ店では 切り捨てで4円、Ｂ店では四捨五入で5円だったとしても。 |
|
|
|
||||||||||||
|
>「総額表示」の問題でした。 あ、そうでしょうね。メーカーとしては単品の総額表示の問題であって、 末端消費者に販売される際に、レシートでどう表記されるかまでは関与 できる問題ではありませんでしたね。(^^;) >> ※157円の商品を２個販売した場合 >>「税込価格」を基に計算：157円×２個＝314円 >>「税抜価格」を基に計算：150円×２個×1.05＝315円 > >こんなのって、お客は314円しか、払わなくていいのですよね つーか、「そのような（外税）レジは変更しなさい」と云うことになる だろうと思います。当初は、レジは「間に合わなければ当面は外税のま までも仕方ない」的なニュアンスだったのですが、混乱を避けるとかで お上の云い方もちょっと変わって来たように私は読めました。 >>>消費税の丸めにおいて切り捨て・四捨五入・切り上げのどの方式を採用するかは、 >>>業者の自由であるとされていたはずです。 >と、紹介されてますが、消費者は、選択できないのでしょうか。 >最悪は、１個ずつ２回レジを通してもらえばいいのでしょうけど。 ま、たかだか１円を巡る問題なのではありますが、このことが問題とな るのは、外税の場合だけです。外税の時は、結果的に消費者は切り捨て の方を選択したようで、前述したように小売店の大半のレジは切り捨て になりました。 しかるに、内税の場合は総額表示ですから、販売業者が後日納税する預 かり消費税の額がどの丸めで計算されるかは全く関係ありません。百円 のものは、内税額の丸め方法が切り捨てだろうと四捨五入だろうと、と もかく百円払うことに変わりはありませんから。 |
|
|
|
||||||||||||
|
悲しげさん＞ >ついでにお訊きしゃいますと、(^^;) >そちらのメーカもやはり税込単価（単価でもって内税）なんでしょうか？ >それと内税額の丸めは？ 今日会社で確認しましたら、「内税・・」の話でなく、あくまで、 「総額表示」の問題でした。 つまり、本体＋税を表示する意味でした。 ところで、あっくん紹介の >レジの計算方法によっては、支払金額が多くなるケースがあります。 >（上記「総額表示についてお知りになりたい方はこちら」のＱ５参照） を、拝見したら、 >〔値札の表示〕１５７円(税抜き１５０円) の場合 > ※157円の商品を２個販売した場合 >「税込価格」を基に計算：157円×２個＝314円 >「税抜価格」を基に計算：150円×２個×1.05＝315円 こんなのって、お客は314円しか、払わなくていいのですよね 悲しげさんの、 >消費税の丸めにおいて切り捨て・四捨五入・切り上げのどの方式を採用するかは、 >>業者の自由であるとされていたはずです。 と、紹介されてますが、消費者は、選択できないのでしょうか。 最悪は、１個ずつ２回レジを通してもらえばいいのでしょうけど。 |
|
|
|
||||||||||||
|
>《規則第22条第1項と経過措置におけるレシートの ... >http://www.sapporo.nta.go.jp/1/kaiseisyouhizei/kaisei_9.htm の最後の例が、「◎ 経過措置が適用できない場合」として 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 『157円(内税7円)』というように単品ごとに消費税相当額の端数処理を行ったもの（157円×5/105＝7.47・・・円⇒7円）を明示し、一領収単位ごとに、この消費税相当額を合計しても経過措置の適用はありません。 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 とあることから、これが非特例＝つまり一般と見なすべきなのかも？ |
|
|
|
||||||||||||
|
どもっ、ド・モ・ONnojiさん 「昔の名前で出ています」ってことですね。 （この板の過去ログで云えば#93より昔） （でも、もっと昔は「ド・モ・」が付いていなかった） >つーことでお辞書登録をおよろしくお願いいたします。 「おんのじ」のヨミで辞書登録しました。(^^;) >コンビニやスーパーでは切り捨てですね。 と云うか、小売業の殆どが「切り捨て」らしいですよ。 もし「切り上げ」の店に出会ったとしても、私の感想は「不思議」と云うよりも 「よーやるよ」辺りですかね。(^^;) |
|
|
|
||||||||||||
|
どもっ、アックン君 色々なサイト紹介、ありがとうございました。べっ、勉強になりました。<(_ _)> でも、結局は判ったような、やはりよく判らないような・・・。(^^;) レシートについて色々な例示はありましたが、いずれも「特例措置」に関するも のであって、「これぞ一般（非特例）」と云うべき例（知りたい例）がないよう な印象でした。 それもそのはずで、ここで云う「特例措置」と云うのは、預かり消費税の納税に かかる特例であって、直接レジシステム（レシート出力）に関する特例ではない から、しょうがないのかもしれません。 ただ「特例措置」の意味は判りました。預かり消費税の年額が、これまではレジ 上での個々の取引の積算で認められていたのが、これからは「簡易課税や非課税 事業者でない場合、基本的に1年間の課税総売上額の5/105から仕入れの消費税を 控除したものが納税額となります」に変更になる。この点において、使っている レジの仕様いかんでは、税額の積算方式でも可とする「特例」を当面経過措置的 に認めると云う、ひたすら節税（？）がらみの問題。つまり、私が#4880で余談的 に書いた「単価20円以下のものは内税額はゼロになるので、幾ら大量に売っても 納税不要？」関連だったようで。 実は今日、ある得意先の経理担当の方にお訊きしてみました。 Ｑ「４月から総額表示になるので、消費税欄は無記載でも構わないっすか？」 Ａ「う〜ん、参考的に（内××円）と記載しておいて下さい」 Ｑ「うっ、額は計算方法によって結構バラツキそうですが・・・・」 Ａ「あ、それは業者毎の算定方法でかまいませんよって」 Ｑ「あら、そうなの」 レシート上では内税額は無記載でもよいようなのだが、請求書について、得意先 からこう云われちゃそうするしかないですよね。さてさて、参考的とは云え、内 税額をどの方法で算定すべきか？ 単価としてプライス表示しているのであるから、内税額も単価内包税額の累積と すべきなような気もするし、あるいは、預かり消費税の納税額に近い考え方を取 れば、伝票（レシート１件）総額×５／１０５で表示した方が妥当なような気が するし・・・。結局は４月以降のメジャーに合わせることになりそうな・・・。(^^;) |
|
|
|
||||||||||||
|
悲しげさん 以下のサイトを読んでください。具体的な表示例が出てます。 消費税の総額表示への対応（指針）（日本百貨店協会） http://search.goo.ne.jp/click.jsp?DEST=http://www.depart.or.jp/news/tax.pdf 天満屋の消費税の総額表示に関する考え方につ ... http://www.tenmaya.co.jp/newptag/s_ana01.html 消費税の総額表示について http://www.technoveins.co.jp/technical/explain/sougakuhyouji.htm ＰＯＳシステムの総額表示を考える http://www.busicom.co.jp/column/sougaku.html 消費税における総額表示に関する方針（日本チェーンストア協会） http://www.jcsa.gr.jp/jca/10-8shouhizei-housin.pdf 消費税総額表示について(日本アパレル産業協会) http://www.jaic.or.jp/activities/trade/0311tax/general.pdf 《規則第22条第1項と経過措置におけるレシートの ... http://www.sapporo.nta.go.jp/1/kaiseisyouhizei/kaisei_9.htm 総額表示の義務付け - 平成15年度消費税法改正 http://www.lan2.jp/support/tax002-004.html |
|
|
|
||||||||||||
|
>つー訳で、とくに問題なければ今後とも「おんのじー」さんで通しますし、 >そうでなければ「ド・モ・ONnoji」で辞書登録することもやぶさかではありません。ご希望は？ 悲しげさん、ボンジュール。 リプライをメルシーでございます。ド・モ・ONnoji でざます。カタカナで失礼。 この掲示板では、ド・モ・ONnoji でお願いします。（^^ゞ つーことでお辞書登録をおよろしくお願いいたします。 >もしかしたらご承知の上での発言かもしれませんが、 >消費税の丸めにおいて切り捨て・四捨五入・切り上げのどの方式を採用するかは、 >業者の自由であるとされていたはずです。 承知しております。 コンビニやスーパーでは切り捨てですね。 パリにて ド・モ・ONnoji でございました。(@^^)/~~~ |
|
|
|
||||||||||||
|
悲しげさん 国税庁のＨＰに、レシートの図入りで説明があります。 http://www.nta.go.jp/category/syouhizei/index.htm 下記リンク（↓）を読んでください。 ・総額表示についてお知りになりたい方は・・・ ・総額表示義務の創設に伴う消費税法施行規則第22条第1項の見直しについて・・・ Re:<4881> >>末端消費者にとっては全く無縁のことでしょうけど、 >そうですね。実際に支払いをする金額は同じですから。 レジの計算方法によっては、支払金額が多くなるケースがあります。 （上記「総額表示についてお知りになりたい方はこちら」のＱ５参照） |
|
|
|
||||||||||||
|
どもっ、ド・モ・ONnoji（おんのじー）さん、 >私のハンドルネームは ド・モ・ONnoji です。 過去ログ#93-95にかけて、ド・モ・ONnojiさん自ら「おんのじー」を名乗っていたので（正確には「おんのじー(ド・モ・ONnoji)」でしたが）、以降、他の方もそうだったように、またキータイピングの手抜きも兼ねて(^^;)そのようにして来た次第です。 ま、【多遊】さんがいつのまにか「たゆー」さんになったように、この板に居着くと、そんな風になってしまうのかも？つー訳で、とくに問題なければ今後とも「おんのじー」さんで通しますし、そうでなければ「ド・モ・ONnoji」で辞書登録することもやぶさかではありません。ご希望は？ >かつて、某地方の某観光地で某市の観光協会が経営する売店で、 >お土産を購入したときのことですが、 >すべて切り上げで、一円玉が釣銭で返ってこなかった記憶があります。 >某観光地には短時間の滞在でしたが、今でも不思議に思っています。 もしかしたらご承知の上での発言かもしれませんが、消費税の丸めにおいて切り捨て・四捨五入・切り上げのどの方式を採用するかは、業者の自由であるとされていたはずです。だから、挙げられた観光地の売店とかもそうだったのでしょうし、私の散見したところでは当地の理美容協会系（？）なんかは当初は100円単位の切り上げだったような記憶もぼんやりとあります。 その後、世の中はますます世知辛くなって、「１円でも安く！」の風潮ですから、消費税の丸めもおのずと 切り捨て＞四捨五入＞切り上げ に流れて来たものと認識しています。競争原理が働きにくい希有な状態では、切り上げもあり得るでしょうが、かなりマイナーだろうし、少なくとも当店ではあり得ないかな、と。それが「切り上げと云うのは殆ど無さそうだから無視」の趣旨でした。 |
|
|
|
||||||||||||
|
>ありますが（切り上げと云うのは殆ど無さそうだから無視） 悲しげさん、こんばんは。 私のハンドルネームは ド・モ・ONnoji です。 かつて、某地方の某観光地で某市の観光協会が経営する売店で、 お土産を購入したときのことですが、 すべて切り上げで、一円玉が釣銭で返ってこなかった記憶があります。 某観光地には短時間の滞在でしたが、今でも不思議に思っています。 |
|
|
|
||||||||||||
|
すいません、#4875を訂正させて下さい。<(_ _)> a)の場合は、仮称[単価内税]なる項目を増設して #cond(#文字位置([備考],"非課税")>0,0 ,&丸め=1,#int([単価]*5/105)*[数量] ,1,#四捨五入([単価]*5/105,0)*[数量]) [数量]を乗ずるのを忘れてました。(^^;) #4881 たゆーさん >しかし販売業の方もですが、メーカも大変な目にあってます >・・・・ >今現在は、社内では、おおかた統一されてしまいましたが、 ついでにお訊きしゃいますと、(^^;) そちらのメーカもやはり税込単価（単価でもって内税）なんでしょうか？ それと内税額の丸めは？ |
|
|
|
||||||||||||
|
先ほど井戸端ＢＢＳを拝見してましたら >「shift」+「alt」+「end」・・・ が、紹介されてましたがおもしろいですね。 こんな機能もあったのですね |
|
|
|
||||||||||||
|
悲しげさんこんばんは >末端消費者にとっては全く無縁のことでしょうけど、 そうですね。実際に支払いをする金額は同じですから。 しかし販売業の方もですが、メーカも大変な目にあってます 特に商品が小さいものでも、総額表示をしなくてはならないし・・・ 今現在は、社内では、おおかた統一されてしまいましたが、昨年秋頃は 大変でしたよ スタートしてからもまだなにかありそうで。 |
|
|
|
||||||||||||
|
末端消費者にとっては全く無縁のことでしょうけど、単価内税にするか総額内税に するかは、特に単価が安いものを主に扱う業種では、預かり消費税の納税時にけっ こう大きな影響が出てくるような気がします。 極端な例では、丸めが切り捨てならば単価20円（四捨五入ならば単価10円）以下の ものは内税額はゼロになるので、幾ら大量に売っても納税不要？ これほど極端ではない例だと結構あるかもしれません。例えば50円ショップがあっ たとして、単品内税なら２円。20個買ったら2円×20=40円とするか、1000円で47円 とするかで、1000円当たり既に7〜8円の差が発生しますから、１年分になると物凄 い差が発生することになります。 ま、そうは問屋が卸さないで、何らかのシバリは科せられるとは思いますが、(^^;) 当店の場合は、レジ上での表記とはまた別に、会計処理上では売上日計額当たりの 内税で対処することになるとは思いますが。我が『弥生会計』では、今までも売上 は（分類毎ながらも）日計総額でもって入力して来たし、そう云えば仕入額なんて （仕入先毎）月計総額で入力してたんだった。(^^;) |
|
|
|
||||||||||||
|
ご承知のとおり、４月から消費税込みの総額表記がデフォルトとなります。 で、消費税額についてはおそらく参考程度に「（内税額○○円）」のよう に附記するようになると思われます。 ま、表記しないならしないでも構わないとなれば、その方が簡単ですけど、 それでも一応は表示させたいとなると、消費税額総計の出し方において、 ちょっと悩ましい問題が発生します（外税の当初にも問題になったことで はありますが）。具体的には、内税額はどの時点で発生させるのかと云う ことです。それ如何では総額が異なってきます。 ※実はもうひとつ、税額の丸め方として、切り捨てか四捨五入かの問題は ありますが（切り上げと云うのは殆ど無さそうだから無視）、まずは、 切り捨てを中心に考察してみます。 品名 単価（税込？） 数量 金額（税込？） −−−−−−−＋−−−−−−＋−−−−＋−−−−−−− 商品Ａ １００ ２ ２００ 商品Ｂ ２００ ３ ６００ −−−−−−−−−−−−−−−−−−−＋−−−−−−− 合計 ８００ a)内税が単価時点で発生しているとすると 商品Ａでは #int(100*5/105)*2=4*2=8 商品Ｂでは #int(200*5/105)*3=9*3=27 合計では ３５円 b)単品（つまり１行ごと）＝金額時点で発生しているとすると 商品Ａの行では #int(200*5/105)=9 商品Ｂの行では #int(600*5/105)=28 合計では ３７円 c)伝票毎（つまり合計時点）で発生しているとすると #int(800*5/105)=38 この場合の合計は３８円 d)例示はしませんが、この他に、複数の伝票の月計総額から 内税月額を算出するやり方などもありそうです。 あと前述したとおり、内税額の丸めが四捨五入だった場合にも類似の問題 は発生します。結果だけを挙げると、a)=40円、b)=39円、c)=38円。 さてさて、当店ではどれを採用したらよいものやら。 外税の場合は、方式c)がメジャーだったと思います。が、内税の場合は、 どうも方式a)がメジャーになりそうな予感があります（レジが）。 皆さん、どうお考えですか？ ＊ ついでに、現時点での私の想定を書いておきます。 丸め方式の中途変更があり得るので、「&丸め」なる変数で統一対応可能な ようにしておくことにする。 &丸めが1なら切り捨て、2なら四捨五入（3の切り上げは無視）。これらを 変数読み込み・書き出しで扱う。 それと、当店の場合は、まれに非課税品目の混在もあり得るので、それも 考慮に入れる必要がある。 a)の場合は、仮称[単価内税]なる項目を増設して #cond(#文字位置([備考],"非課税")>0,0 ,&丸め=1,#int([単価]*5/105) ,1,#四捨五入([単価]*5/105,0)) b)の場合は、仮称[金額内税]なる項目を増設して #cond(#文字位置([備考],"非課税")>0,0 ,&丸め=1,#int([金額]*5/105) ,1,#四捨五入([金額]*5/105,0)) c)の場合は、仮称[税額]なる項目を増設して #cond(#文字位置([備考],"非課税")>0,0 ,1,[金額]*5/105) あるいは小数点以下は任意の桁でカットした方がいいかも？ #cond(#文字位置([備考],"非課税")>0,0 ,1,#四捨五入([金額]*5/105,3)) 消費税の総額はa)とb)はそれぞれの増設項目の単なる合計であるが、c)だけ は合計時に丸める。 #cond(&丸め=1,#int(#合計([税額])),1,#四捨五入(#合計([税額]),0)) 非課税品目の混在があれば、#合計([金額]*5/105) が使えないので。 |
|
|
|
||||||||||||
|
bonitoさん、こんにちは。遅くなりました。 明細行の色を変えるのって、けっこうニーズあると思います。 いいですね。 |
|
|
|
||||||||||||
|
尾形さん、こんにちは。遅くなってすいません。 > ソース値更新イベント内で更新前値を取得できたら楽なのに 更新前の値は入力前イベントの&編集文字列にあらかじめ代入されていますから、 ここで早めに取得しておけば楽だと思うんですが、いかがですか。 |
|
|
|
||||||||||||
|
アックン君((C)kanasy？)や悲しげさんその他の方々に教わる事大なり そこで私も何か一発と考えましたが手持ちのネタがありません (T_T) っでもってこれは私としてはへえ！的ではあるがすでに周知の事かもと 思いつつ...そして最後にはやっぱ質問へとなだれこむ作戦(？)を敢行 する事にしました (^^; グループ化したフォームでの事、永らく私は(多分これは一覧表レポート との関連で)、グループ項目はヘッダあるいはフッダに置かなければなら ない！のと同様、グループによる集計 (#合計([金額])とかってやつ) も 明細行には置けないものとばかり思っていましたがつい最近フォームでは グループ集計のテキストオブジェクトはどんな場所(セクション)にも置け る事を発見しました(ってそんな大それた事でもないんですけどネ) キッカケは明細行のテキストの編集属性式に、 #条件選択(#平均([金額])>[金額],"背景色'薄紅色'") とか何も考えずに(ついうっかり)書いたら通ってしまったからでした。 レポートと違って伝票形式でも一覧形式でもＯＫでっす。 ところでこれってＤＯＳ時代から...だったのだろうか？ |
|
|
|
||||||||||||
|
アックンさん、bonitoさんこんにちは 自分もソース値更新ばっかり使ってますね ソース値更新より融通が利く感じですね ソース値更新イベント内で更新前値を取得できたら楽なのに |
|
|
|
||||||||||||
|
bonitoさん、悲しげさん＞ 表示系で苦労されているのが、よくわかりました。 bonitoさん、桐井戸端BBSで話した「入力後」イベントの使い方をひとつ。 帳簿を入力するときに、[摘要]を入力したら左右の科目名を自動的に記入することにします。（そういう表をあらかじめ用意しておきます。） これを「ソース値更新」で行うと、[摘要]に値を表示した後で[借方科目][貸方科目]に値を表示、という２段階の表示動作になります。 これを「入力後」に書くと、３項目に同時に値を表示しますから、タイミングがピタッと決まります。 「入力後」イベントには、値をチェックするだけにとどまらず、こういう用途もありますです。 proc t摘要::入力後(参照 文字列 &編集文字列，長整数 &モード，参照 長整数 &入力継続) if( &モード=1 ) 編集表 "科目摘要" 検索 ↓ , [摘要] { =&編集文字列 } , 終了状態=&end if( &end=1 .and&編集文字列 ) var 文字列{ &str[2] } &str[1] = [借方] , \ &str[2] = [貸方] 編集表 "仕訳日記帳" 項目値代入 [借方科目] = &str[1] 項目値代入 [貸方科目] = &str[2] end end それこそボタンを使って表引き(<4871>)してもよさそうな・・・・。 |
|
|
|
||||||||||||
|
どもっ、アックン君、bonitoさん おかげで参考になります。<(_ _)> >普通は[再描画]メソッドとか[変数変更]メソッドとか使う >のかも知れないが、 [描画更新]メソッドってのもあります。って、多分ご承知の 上かとは思いますが。 でもコマンドボタンの実行ってのも速そうですね。 あと「困ったときのコマンドボタン頼み」として、最近よく使う方法。 値をいったん確定して続けて訂正モードにしたいときー、 更新モード設定メソッドを (0) と (2) の２回連記ってのも何だか 「悲しいときー」だし、あるいは単に、メソッドで更新モード設定(0) にしても状況により値が確定しないことがある（制御が未だ入力エデ ィタ上にあった場合など）ので、念のためにボタンの「表示」（パラ は確定する）機能を使うことがあったりするので、いっそのこと次のよ うにしてしまった。 ボタン名「b表示と訂正」(^^;) 機能 パラ 表示 確定する 訂正 こうすれば、 method @b表示と確定.実行() の１行で済みます。 最近多くのwfmのワークスペースにこれを置いて汎用してます。(^^;) |
|
|
|
||||||||||||
|
アックン >#set("前残高",#tlu(&科目名,=,"精算表.tbl",[勘定科目],[前残高])) いただきやす φ(.. )メモメモ ところで幅田さんとこではリプライ出来ずに済みませんでした おっしゃるところは通じております m(_ _)m >他にもちょっと変わった使い方している人、誰かいます？ 全然変わってないけど、kev内で変数値を変更した場合、 フォームにその変数をソースとするオブジェクトがあっても フォームはシカトして何もしませんね (htmlhelpのどこかに書いてあった筈だが見つけられない) 普通は[再描画]メソッドとか[変数変更]メソッドとか使う のかも知れないが、その辺私にはよく判らないので、結局 ウィンドウ更新 &hwindow って逃げてしまうのだが...それもどうかと思う時もあって コマンドボタンで、なし・・#代入(&あ,"うん") だけして、kevで メソッド呼び出し @ボタン.実行() だけして...って事もあります う〜むこれもどうなのかなぁ？？ |
|
|
|
||||||||||||
|
うにんさんが<4868>に書かれたとおりで、<4867>は比較式そのものそのまんまでっす。ちょっと主題からはずれますけど、コマンドボタン「機能パラメータ」の変わった使い方を紹介。フォームを使っていて、編集対象表以外の表の項目値を変数に取得したいとき、通常はこんなふうにすると思うんですが。 編集表 ・・（編集表を切り替えて） 検索 ・・ （検索して値が見つかったら） 代入 ・・ （変数に代入して） 編集表 ・・（編集対象表に戻る） ところがこれだと動作が若干遅いんですね。そこで、表引きすれば速いはずなんですが、イベント処理に表引き関数を直に書けない。そこで困ったときのコマンドボタン登場。 表引き関数を使って変数に値を代入する式を「機能パラメータ」に書いておきます。 #set( STR , #tlu( &科目名 , = , "精算表.tbl" , [勘定科目] , [勘定] ) ) とか、 #set( "前残高" , #tlu( &科目名 , = , "精算表.tbl" , [勘定科目] , [前残高] ) ) とだけ「機能パラメータ」に書きます。「機能名」は なし です。 あとは各ボタンをイベントからメソッド実行してやればオーケーです。 method 戻り値 = &n ，@b_非表示1 . 実行() method 戻り値 = &n ，@b_非表示2 . 実行() それにしても、まわりくどい処理だな。(^^; 他にもちょっと変わった使い方している人、誰かいます？ |
|
|
|
||||||||||||
|
4869にコピペミスあり！ > 機能 同パラ >実行条件 &code<>"" >なし #代入(&STR,"[code]=&code") (a) >検索＿値 &STR >なし #代入(&STR,""),#代入(&code,"") ここは 検索＿値 ＿&STR ですよね。アンダーバーが抜けていた。 既に無用っぽくなった記述ではありますが、一応訂正しておきます。(^^;) |
|
|
|
||||||||||||
|
どもっ、アックン ややややや、 何だ、そうだったんですね。超簡単やんけ。(^^;) つまり、最も単純な記述でよかったと云うことですね。 どうも先入観が邪魔をしていたようで、わざわざ難しく難しく考えていました。 思うに、全ての躓きの始まりは { } を含めようとしたことかもしれません。 多分、V7の頃からでしょうから、いやぁ、判るのに随分な歳月を要しました。(^^;) 云わせてもらえば、コマンドボタンのヘルプに記載例がありさえすれば、こんな 回り道はしなくてよかっただろうことを痛感しました。 もしかしたら「あまりに単純なことなので、説明の必要すらない」と考えていた のかもしれませんが、ところがどっこい、どっこいしょなのです、やっぱし！ つー訳で、よろしく ＞ Ｋ３様 補足。 No.4837を見た直後、ちょっと誤読しまして、次のように試してみました。 機能 同パラ 実行条件 &code<>"" なし #代入(&STR,"[code]=&code") (a) 検索＿値 &STR なし #代入(&STR,""),#代入(&code,"") こうすれば、&codeに演算子文字列を含んでいても確かにエラーにはならないし、 この時、(a)のところで なし #代入(&STR,"[code]=*&code*") (a) のように * を加えると、部分一致検索もうまく動きました。 わーい、やったぁ！ ただ(a)の過程で１行消費してしまうのが、ちと辛いかな・・・・・。 ・・・・と、改めてNo.4837を読み直してみると、う〜ん、なんか違うな？ しばしの後、ようやく意味が判ったと云う次第であります。(^^;) と云う訳で、記述は次のように書き換えました。 機能 同パラ 実行条件 &code<>"" 検索＿値 [code]=&code (b) なし #代入(&code,"") もちろん、変数に演算子文字列が含まれていてもノープロブレムですし、(b)の ところで &code* とか *&code* としても期待どおりの挙動を示しました。(^^)v 以上の理解の上で、ようやくうにんさんの4866,4868の意味が（概ね？）判った ような気がします。(^^;) ps. この件でアックン君にお助けいただいたのは二度目です。<(_ _)> |
|
|
|
||||||||||||
|
つまり <検索比較式>|<項目名>|_<文字列式> の最初のパターンですね。 悲しげ先生は３つめのパターンを使おうとして苦労していたわけですね。 昔は_の後は変数だけだったはずですが。 _を使う必要があるのは、比較演算子（や比較項目）を動的に変えたい場合ですよねえ。 |
|
|
|
||||||||||||
|
そういうニーズのときは、＿（アンダーバー）使わない方が簡単ですよ。 機能名：検索_値 または 検索_比較式 機能パラメータリスト： [借方科目]=&STR [借方科目]=&STR* [借方科目]=*&STR* これなら「演算子文字列全般やスペースがあっても」(No.4865)大丈夫のはずだし、 普段書いているスタイルと変わらないだろうし、つまりややこしいダブルクォーテーションを書かなくてもいいっていうのが、なんともウレピ〜ではありませぬか。過去ログ検索せずにすぐに書けるし。 アンダーバー(アンダースコア)を使うときっていうのは、手続き内または手前の機能パラメータ内であらかじめ比較式をそっくり変数に代入しておいてから、機能パラメータに＿&STR とだけ記述するのが簡単ですよ。 で、どちらの書き方も、動作チェックやメンテナンスが容易で、記述ミスが少なくてすみます。 |
|
|
|
||||||||||||
|
つまり、「検索 [code]{&code}」の{}の中を計算式で書けばいいわけですね。 ところが{}の中しか書けないので項目名と比較演算子の指定を省略できなくなり、 ややこしくなる、という。 機能の入れ替えは、ぜひ欲しいですね:-D |
|
|
|
||||||||||||
|
どもっ、おんのじー様 >この簡略形は &code の値にハイフン記号(−)を含んでいる場合にはエラーになりませんか？ なります、なります。四則演算のみならず演算子文字列全般やスペースがあってもそうなったと記憶します。(^^;) >_"[code]="""+&code 既に殆ど簡略形とは云いがたく・・・・(^^;) |
|
|
|
||||||||||||
|
悲しげさん、こんにちは。 >同簡略形 _"[code]="+&code 文字列型項目を検索するときに、 この簡略形は &code の値にハイフン記号(−)を含んでいる場合にはエラーになりませんか？ これは四則演算のマイナス演算子（−）と見なされるためだと思いますが… _"[code]="""+&code これなら大丈夫だと思いますけれど。 |
|
|
|
||||||||||||
|
実は、コマンドボタンの機能「検索＿値」または「検索＿比較式」の書き方については、（以前にも何度か教えを請うたことがありましたが）何回訊いてもよく判りませんでした。(^^;) cf.例えば幅田さんの過去ログ http://www.fuku3.com/~habata/kbbs/kakov8/11852.htm さて、私は 検索 [code]{&code} 検索 [code]{*&code*} のような書き方を好んで使っています。で、これをkevを起こすまでもないような場合に、フォームの開始時実行ボタンでやりたいと思ったのです。 昨夜ようやくそれに挑戦して、数時間ハマってしまいました。 つまり 機能 同パラ 検索＿値 ＿"[code]{"""+&code+"""}" のような書き方を、ダブルクォーティション数の変更を含めて、色々試行してみたのですが、ことごとくペケだったのです。ほとほと疲れて、次のように書いてみたら 検索＿値 ＿"[code]="+&code なんてことはない、スルリと通ったのでした。(^^;) Win版のヘルプには明記してはいないけれども（多分）、アンダーバー検索では { } は使っちゃいけなかったんですね。ハタと膝を打った私は（膝をさすりながら？）桐V5のリファレンスを取り出して調べたら、何とそのことがちゃんと明記されていました。(^^;) 今回の教訓は「V5のリファレンスは貴重」です。 じゃなくて(^^;)、ようやくコマンドボタンの機能「検索＿値」・「検索＿比較式」のパラメタリストの書き方が判りました。 よって、ここでメモを挙げておきます。もし知らなかった方がいらっしゃったら参考になるかも知れないことと、私自身、このところメッキリ記憶力が落ちているので忘れてしまった場合にここの過去ログで検索させていただくためです。 機能「検索_値」等のパラメタリストの書き方 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 完全一致 _"[code]="""+&code+""" 同簡略形 _"[code]="+&code 先頭一致 _"[code]="""+&code+"""*" 中間一致 _"[code]=*"""+&code+"""*" ps. それにしても、コマンドボタンのヘルプには記載例を色々つけて欲しいですよね！！ コマンドボタンに関して、ついでに云えば、そろそろ記述の行削除・挿入・↑・↓を実現して欲しいですね。それと機能「ボタンの実行」（こうすれば無限的なチェーンが可能となるのでり実態的に４行の制限がなくなりそう）の新設も。 |
|
|
|
||||||||||||
|
悲しげさん＞ ずいぶん大変だったようですね。ちょい心配しましたが、無事のようでなによりです。 おいらんちはパック入りの飯を買っておいて、普段ご飯が少しだけ足りないってとき、わざわざ炊かないでそれを食べて、少なくなった分をすぐに補充してます。パックご飯は量販店でよく安売りしてます。 非常用の調理の熱源として、携帯カセットボンベのコンロを用意してます。これは夏にキャンプでいつも使ってます。近頃のやつはけっこう火力が強いです。これも量販店で安売りのときに購入しました。水は・・・・なんて書いてるとキリがないから、このへんでやめとこ。 |
|
|
|
||||||||||||
|
本日夕方になって、ようやく幹線的道路は開通したようです。 しかし裏通りは殆ど未開通で、そちらの住人は、腰以上もあるような雪の中をまるで「泳ぐように」歩くような状態です。私んちは、田舎なりにもオモテ通りに面しているので、何とか食糧をゲットできるようになりました。 でも、今日はぶっとおしの除雪作業で、もうヘロヘロです。さすがに腰が痛い。(;_;) 当地の年寄りに聞いたところでも、このようなことは初体験とのことです。ひどい吹雪が、１日くらいなら時々あったけれども、３日も続いたと云うのは。 ＊付録 あ「おまいさん、米びつにもう米粒がねぇだよ」 い「う〜ん、給料日までまだ間があるしなぁ」 う「そうゆう問題じゃねぇだろ」 この小咄を家族にしたら、一人目の反応は失笑、二人目は蔑んだ眼差し（さげすんだまなざし）、そして三人目はなんと無視、でした。(^^;) |
|
|
|
||||||||||||
|
>ただ、取得できた場合が0だと論理値では偽になってしまうのでわかりにくいですね。 うにんさん、こんにちは。 これはあくまでも私( ONnoji )の個人的な感想ですが… 桐のコマンドの［終了状態］パラメータや メソッドの［戻り値］パラメータ、 そして関数の戻り値には、 ゼロ(0)とイチ(1)のニ値論理を返すものが多数ありますが、 絶妙に一貫性がないように思います。 正論理かと思っていたら実は負論理だったりして、 その都度ヘルプで確認するので結構ヘロヘロになります。 |
|
|
|
||||||||||||
|
>関数が返すところは、先頭の変数ですね。妙に配列にこだわってました これはちょっと変な表現です。「先頭の変数」に値が入るのはあくまでも 「=」つまり代入コマンドの作用です。関数が返しているのではなく。 条件判断に1回使うだけなら変数に入れる必要はないわけで if ( #ウィンドウサイズ( -1, size )) という書き方もできます。 ただ、取得できた場合が0だと論理値では偽になってしまうのでわかりにくいですね。 |
|
|
|
||||||||||||
|
どもっ、たゆーさん >ぜひ、『カロリーメイト』などとりながら、生き延びてくださいね はい、何とか生き延びたいと思います。(^^;) 風雪が凄いこともさりながら、ともかく道路が（歩道を含めて）通れるようになっていないのです。昨日の午前中に食い物を確保しておくべきだったと後悔しています。(;_;) |
|
|
|
||||||||||||
|
たゆーさん、こんにちは。 >テキスト表示の件 >さっそく、確認してみます いえいえ、「そういえば…どうしたかな〜」と少し気になっただけです。 継続調査中ということならば、それでいいのであります、ということで。 余計なことを書いてスイマセンでした。 |
|
|
|
||||||||||||
|
悲しげさん、大変ですね。こちらでは、ニュースで見てるだけですが、現地の人たちは さぞ大変でしょう。お見舞い申し上げます >予想では、おそらく明日の昼頃まで、この状態が続きそうです。 ぜひ、『カロリーメイト』などとりながら、生き延びてくださいね |
|
|
|
||||||||||||
|
>&error = #ウィンドウサイズ( -1, size ) そうですね。関数でしたね。 関数が返すところは、先頭の変数ですね。妙に配列にこだわってました テキスト表示の件 >ところで、年末の話題：テキストボックスの文字が再描画されない件はどうなりましたか？？？ 質問の「同じフォーム(イベント)を、動かしてどうして表示されるのとそうでない場合があるのか」という 答えでないので、連絡しそびれてますが、それではONnojiさんへも遅れるだけですね さっそく、確認してみます |
|
|
|
||||||||||||
|
いやぁ、昨日の午後からひどい吹雪で、家の中に閉じ込められておます。 北海道にて数十年暮らしている内で、記憶にある限りでは最大のような気がします。 予想では、おそらく明日の昼頃まで、この状態が続きそうです。 糧食の蓄えが持つだろうか？ 水は？ 電気は？ 食い物は当店販売商品である『カロリーメイト』とかの在庫もあったりしまして、水は雪を溶かせば何とかなるでしょう。しかし、電気が止まるのが一番辛いです。この時季は、何よりも暖房がとれなくなるからです。石油ストーブは電気で制御されているためです。まだ本格的な停電には至っていませんけど。 |
|
|
|
||||||||||||
|
たゆーさん、こんにちは。 >ウィンドウハンドル n が有効の場合は 0 を返し、無効の場合は 1 を返す。 >変数宣言 数値{&damy,&size[2],&フォーム[2],&画面[2]} > &damy=#ウィンドウサイズ( -1, size ) 試していないので恐縮ですが（^^ゞ &damy という変数名を &error とすると… &error = #ウィンドウサイズ( -1, size ) if ( .not &error ) * 成功 else * 不成功 end こんな風に使うような気がしますけれど… 追伸 ところで、年末の話題：テキストボックスの文字が再描画されない件はどうなりましたか？？？ |
|
|
|
||||||||||||
|
>有効かどうかは関数の値が示すということですね。 >サイズは縦と横で値が２つあるので、要素数2以上の配列を指定するわけです 下記<4848>でいえば >変数宣言 数値{&damy,&size[2],&フォーム[2],&画面[2]} > &damy=#ウィンドウサイズ( -1, size ) &sizeで、配列変数を利用してますが、 >ウィンドウハンドル n が有効の場合は 0 を返し、無効の場合は 1 を返す。 この説明のうち、「無効の場合は 1」を、たぶん「&size[1]」へ返すのでしょう しかし有効の場合は、そのサイズ自体(1024)とかを返すのだと理解しています したがって、有効の場合、どこへ(どの変数？)に「有効の場合は 0 を返し」 が、行われるかが疑問だったのです。 これが、有効の場合は、「画面サイズが返ります」でしたら意味が わかるのですが。 |
|
|
|
||||||||||||
|
たゆーさん、こんばんは。 >最大化や最小化の状態でも通常の状態のサイズを返す。 >対象となるウィンドウが最大化または最小化されている場合は、 >最大化または最小化されたウィンドウのサイズを返します。 私が調べたところ、桐ver.8 sp5 以降から ＃ウィンドウサイズ( )関数は最大化と最小化に対応しています。 つまり、内部ヘルプの方は桐ver.8 sp4までの内容を示し、 外部ヘルプの方は桐ver.8 sp5 以降の内容を示していると思います。 相変わらず内部ヘルプと外部ヘルプで説明が食い違っているようですね。 困ったことですね。(~_~;) |
|
|
Copyright (C) 2000 CGI Arkadia All rights reserved. Script written by Shintaro Wakayama. BBS-TypeN Ver.2 Preview4 remodel advice by hidetake |