古籏一浩です。

At 23:07 97.10.7 +0900, Yasuo Kuzuhara wrote:
>なおかつ、以前のEudraの環境が壊れてしまったため、仮にMSのIEについてきたメーラーを使ってます。もし変なメールになっていたら、教えて下さい。m(v_v)m
　Content-transfer-encoding: 7bit
　になってますが、なぜかちゃんと読めます(^^;

yukiです。

乙坂さん wrote:
> COMPILE 0,_IncludeWDef
> をつけると、うまく動きます。
さっそく試させていただき、うまくBuildすることができました。有難うございました。

> それにしても、不親切なマニュアルですねー。一応、リファレンスとハンドブックは全体にさらっと目を通したつもりなんですが。この手のwindowを使うためには、Compile文のフラグの細かいところを読んでおかないといけないというのは、ちょっといただけません。
ほかの部分ではかなりいいソフトだとおもうんですがねぇ。FB3に期待しましょう。

原　幸久(akiyuki@alles.or.jp)

ベンさん、こんにちわ。磯村＠埼玉です。

　丁寧な解答、ありがとうございました。

>>　一番いい方法は、PICTリソースを取ってきたあとすぐに ToolBox の CALL DETACHRESOURCE(resHandle) で、PICT ハンドルをリソースマネージャの管轄からはずしてしまうことです。
とのアドバイスの通りにやってみたらあっさり行けてしまいました。ううむ。「下手な考え休むに似たり」ってホントだなぁ（笑）。
　これで一歩野望に近づきました。
　つまり「リソースフォークにあるデータは、リソースマネージャの要求したときのみファイルからメモリに読み込まれ、普段はメモリには存在しない」という風な理解の仕方で良いんでしょうか？

　今度は、並んでいるPICTの順番を入れ替える、っていう作業にかかろうと思いますので、しばらくまたハンドブック（とリファレンス）を読み漁ろうと思います。
　でもきっとまた泣きつきに来ると思いますが（笑）。

I should be happy to be of any service to you!!

こんにちわ。重松です。

今日は文字列変数についてです。
よくサンプルソースなどを見ていると、

A$=""
B$="テスト"
BLOCAKMOVE @B$,@A$,LEN(B$)+1

というようなプログラムを見かけるのですが、これは、A$という文字列の変数が宣言されたら、256バイトの格納領域が確保されるということを意味するようにとれます。実際のところはどうなのでしょうか？

私は心配なので、
A$=SPACE$(LEN(B$))
を実行してから、BLOCKMOVEしているのですが。

よろしくお願いします。

P.S.

いつの間にか、1000件を超えていましたね。

yukiです。

根来さん wrote:
> アクティブなウインドウにカーソルが入っていればクロスカーソルとし，範囲外なら矢印カーソルにしています。
私には原因を解明する力はありませんが、以下のような方法でしたら以前に試したことがありますので、参考までにお知らせいたします。

原　幸久(akiyuki@alles.or.jp)
（以下ソースコード）
'===============
DIM gProgEnd
END GLOBALS
'----
CLEAR LOCAL
LOCAL FN initProg
CLEAR
gProgEnd =0
WINDOW 1,"W1"
WINDOW 2,"W2"
END FN
'-----
CLEAR LOCAL
DIM myPoint;4
LOCAL FN doDialog
evnt = DIALOG(0)
id = DIALOG(evnt)
'----
PRINT "EVNT,ID ";evnt,id
SELECT evnt
CASE _cursOver
id = DIALOG(_cursEvent)
PRINT "_cursOver";evnt,id
LONG IF id=WINDOW(_activeWnd)
CURSOR _crosscursor 'front window
XELSE
CURSOR _arrowCursor 'back window
END IF
CASE _cursEvent
CURSOR _arrowCursor
END SELECT
END FN
'---- main
FN initProg
ON DIALOG FN doDialog
DO
HANDLEEVENTS
UNTIL gProgEnd

yukiさん，こんばんわ。

頂いたサンプルを試してみましたが，カーソルはちゃんと更新されますが，イベントが表示されるのが背面のウインドウになりますよね。これが困っている部分なのです。アイドリング処理で毎回WINDOW関数やGetPortするにしても正常な値が得られず自爆しております。(^^;
いやはや，困りました。

カーソルの変更部分を参考にさせていただきます。
ありがとうございます。
　　　　　　　　　　　　　　　　　　　　　　　　　　　根来

古籏一浩です。

At 15:15 97.10.9 +0900, Osamu Shigematsu wrote:
>今、手っ取り早くPICTをGIF、またはJPEGに変換する方法を探しています。
>QuickTimeをつかえば、JPEGは簡単にできそうな気がするのですが。。。
　一番速いのはFuture BASIC Toolsを使うことでしょう。
　GIF,JPEG,TIFFなどを指定して保存できます。

>変換する画像は、いわゆるWebpage用のカウンター画像なので、GIFの方が向いているとは思うのですが、GIFって保存ができるアプリケーションを作るとUNISYSかどこかが著作権を持っていて、ライセンスを払わないといけないというのをNIFTYで聞いたことがあります。実際はどうなんだろ。。。
　大手はちゃんとライセンスを取得しているようですが・・・
　日本円で100万円くらいでしたっけ？

重松です。

>　一番速いのはFuture BASIC Toolsを使うことでしょう。
>　GIF,JPEG,TIFFなどを指定して保存できます。
私もそれはそうだと思うのですが、あれだと、ダイアログが開いてファイルを指定してディスクに保存しますよね？（JPEGだとさらに圧縮率まで入れないといけない。）普通のアプリならいいのですが、CGIなので、ダイアログで指定する、ということができないし、カウンタのファイルをディスクに書いていたらディスクスペースがどんどんなくなってしうし、速度も遅くなるし、またほとんど同時に複数作業することがあるので、共通のファイル名でワークファイルを作ってRedirectすることもできません。

>>変換する画像は、いわゆるWebpage用のカウンター画像なので、GIFの方が向いているとは思うのですが、GIFって保存ができるアプリケーションを作るとUNISYSかどこかが著作権を持っていて、ライセンスを払わないといけないというのをNIFTYで聞いたことがあります。実際はどうなんだろ。。。
>　大手はちゃんとライセンスを取得しているようですが・・・
>　日本円で100万円くらいでしたっけ？
100万円とは！またまた豪勢ですね。PixelCatがGIFを読めて書けないのは上記の理由からでしょうかね？STAZのToolsをつかってお絵書きソフトを作っても上記ライセンスがチャージされるとしたら、恐ろしいことになりますね。

重松です。

>文字型変数は標準でいきなり256確保されます。
>ですから，a$ = "" でも256バイト消費されます。
>もったいないですね。
さっそくありがとうございます。そういう仕組みだったのですね。
しかしまた、256バイトも確保するとなると、プログラム中でやたら文字列を扱う場合には、注意が必要ですね。

まだFBの仕組みが良く分かってないんですが、普通はたとえ1バイトであってもメモリが足りないとプログラムは動かないと思いますが、たとえば、A$という変数が宣言されたとして、メモリに空きがないとどうなるんでしょうか？

メモリ不足エラーになると考えるのが順当だと思うんですが、それだと、プログラムが終了してしまいませんか？そうなると、サーバなどのプログラムでは致命的ですよね？私は、CGIを書いているのですが、CGIは同時に複数が使うので、メモリ不足の場合は最後の処理だけ、メモリ不足だよ！と返事をして、他の処理に影響がでないようにする必要があるんですが、CGIの引き数を

DIM RECORD sdoc
DIM sdocpath$ '"path_arg
DIM sdockfor$ '"searcg_arg
DIM sdocuser$ '"user
DIM sdocpass$ '"pass
DIM sdocKcip$ '"client-ip address
DIM posthndl& '"post_arg
DIM postsize& '"post_arg
DIM END RECORD .sdoc

というふうに処理しているんですが、これだとここで1Kくらい使う勘定になりますよね。まあ、たいした量でないといえばたいした量でないのですが、同時に50とか処理を行うとDIM www.sdocを実行したときにメモリ不足がでる可能性も高い気がするんです。

万一そのような状態になりモーダルのウインドウを出してしまうと、他の処理をしなくなるので、サーバが停止してしまうのですが、あとどれくらいそのアプリケーションがメモリを利用できるかでかい配列を利用する前には、確認するしかないのでしょうか？

AppleScriptの場合なんですが、

on myFN(arg)
try
ここにメインの処理を書く
on error
エラー処理
end try
end myFN

というふうに関数ごとにエラートラップというのでしょうか、例外処理をできるので、非常に重宝しているのですが、FBでもON ERRORで似たことができそうな気がするのですが、どこに飛ぶかの指定がいまいち良く分かりません。

いつもは、AppleScriptの場合には、

on mainFN
try
set myResult to myFN(arg)
return http_header & myResult
on error
return http_header & "An error occured!"
end try
end mainFN

というふうに入れ子にして処理しています。

皆さんは、こういう例外処理はどう処理されているのでしょうか？

At 5:39 PM 97.10.9, sendai_5300LTB wrote:
> 今とっても困っております。知恵を貸して下さい。
> 次のような複数ウインドウのアプリがあります。
> アクティブなウインドウにカーソルが入っていればクロスカーソルとし，範囲外なら矢印カーソルにしています。

　（中略）

> このアプリ単体では問題なく動作しているのですが，一度ファインダーなど他のアプリを前面に出し，このアプリに戻る場合に不具合があります。
> 現象としては，アクティブでないウインドウのタイトルバーをクリックしてこのアプリを前面にすると，タイトルバーがアクティブでないウインドウをアクティブなウインドウとしてクロスカーソルになります。
> これはなんでなんでしょう。
> 実際のソースは非常に複雑ですが，このサンプルのアイドリング処理の部分
> でオフスクリーンからCOPYBITSしているのですが，アクティブなウインドウと描画先のポートが異なるのでえらいことになっています。
　下線部がポイントです。根来さんのいう「アイドリング」部分って、マックのイベント分岐をしている HANDLEEVENTS と平行して書かれているのが問題なんです。

　DO
HANDLEEVENTS
マウスの処理
UNTIL 〜

　となっているでしょ。これはダメです。必ずＯＳのイベントに対して反応する形で記述してください。この例でいえば、アプリケーションのウインドウがあるうちはいいんですが、他のアプリから復帰したときなどに、いきなり「マウス処理」部分が実行されてしまいます。これがレシュームとかウインドウ・アクティベートのイベントより早く実行されてしまう危険があります。つまり、アクティベート・イベントがおきてないからクリックされたウインドウが一時的にアクティブなウインドウと認識されるとか。（内部の処理がどうなっているかまでは僕も知りませんよ。あくまで例です）

　マックおよび FB でいう「アリドリング状態」というのは、Macintoshの「null」イベント状態ことを指します。メインループで勝手に繰り返し処理をしてはいけません。単なる計算ならともかく、ユーザーの処理にかかわる部分を記述するのはバグの温床となります。
　Macintoshの null event もハンドブックの p63 に記述があるように ON EVENT FNでとらえられます。あるいはてっとり早く、ON TIMER(-1) FN とすれば、６０分の１の割合（基本的には null event と同じ割合です）で指定した関数が呼び出されます。イベントを捕えて処理を行っている限り、今回根来さんが体験しているような状態はありえないはずです。かならずイベントを介して処理を行うのがマッキントッシュの「イベントドリブン」なプログラムの鉄則です。

　まあ、実際には今回の処理の場合、原さんがすでに書いているように、ON DIALOGでイベントを引っかけて、_cursEvent を利用するのがいいですね。_cursEvent は、カーソルがウインドウ内部に入った時に発生して、そのウインドウの ID を返しますので、その ID とアクティブウインドウの ID とを比べて一致すればクロス・カーソルに、一致しないとき及び _cursEvent が０を返しているときは矢印カーソルにセットすればいいでしょう。こっちの方が楽でしょう。

＃なんか原さんは _cursOver イベントも使ってますが、これってボタンやらフィールドにカーソルが入ったときに発生するんだよね？

At 6:04 AM 97.10.10, sendai_5300LTB wrote:
> yukiさん，こんばんわ。
>
> 頂いたサンプルを試してみましたが，カーソルはちゃんと更新されますが，イベントが表示されるのが背面のウインドウになりますよね。これが困っている部分なのです。アイドリング処理で毎回WINDOW関数やGetPortするにしても正常な値が得られず自爆しております。(^^;いやはや，困りました。
　あやや、こっちが書いているあいだに解決しちゃったのね。
　イベントが表示されるウインドウが固定なのなら、OUTPUT WINDOW で指定できませんか？　COPYBITS するなら、あらかじめグローバル変数にウインドウの GrafPortをとっておくとか。

　そもそも描画って、ウィンドウへのアップデートイベントで処理しないと駄目ですよ。FB なら _wndRefresh だったかな。アップデートイベントまで描画を遅らせるのも、Macintoshプログラミングの重要な技術の一つですね。

InternetCongifですが、FB用のAPIを見つけましたので報告いたします。
mel@intergate.bc.caさんのものです。
http://www.geocities.com/SiliconValley/Lakes/8064/icAPI.sit からダウンロードできます。

参考になれば幸いです。

yukiです。

また基本的な質問があるのですが、いま以下の関数(Pascal Interface)への引き数で悩んでいます。

LOCAL FN GetMaxCompressionSize(src&,@srcRect&,colorDepth%,quality&,
　　　　　　　　　　　　　　　 1^^^^^^^^^
cType&,codec&,@size&)
　 2^^^^^^
@マークがついているということは、1、2ともポインタを要求されていると思うのです。で、

DIM srcRect;8
DIM size&

と定義し、

FN GetMaxCompressionSize(src&,@srcRect,......@size&)

で呼ぶと双方ともエラーが発生してしまいます。どこに問題があるのでしょうか。よろしくお願いいたします。

原　幸久(akiyuki@alles.or.jp)

At 2:56 AM 97.10.11, 原　幸久 wrote: > > ＃なんか原さんは _cursOver イベントも使ってますが、これってボタンやらフィールドにカーソルが入ったときに発生するんだよね？
> すみません。実は私も教えて頂きたいのですが、なぜかWindowからカーソルがでるときは、_cursEvent= 20、入るときは_cursOver= 21でイベントが発生するようなのです。で、こうしているわけなのですがもっとうまい方法はあるのでしょうか。
　ううむ、僕も確認しました。どうもウインドウ内にカーソルが入ったときは、_cursOver イベントしか発生しませんねえ(^^;)

　いろいろ試して見たところ、次の用になってますね。

・ウインドウ内にカーソルが入る
_cursOverが発生
　　　DIALOG(_cursOver) は、ボタンやフィールドではなく、ウインドウ内部に侵入したことを表わす０になる
　　　しかしここでDIALOG(_cursEvent) で、侵入したウインドウのウインドウＩＤを得ることができる。

・ウインドウ外部にカーソルが出る
　　_cursEventが発生
　　　DIALOG(_cursEvent) では、マニュアルどおり０が得られる。

　結局、原さんのやっているように、_cursOver と _cursEvent を併用するしかないでしょう。推測するには、ウインドウにカーソルが侵入した場合、_cursOver (ID=0)と _cursEvent (ID=window id) が同時に発生してしまうため、イベントしては _cursOver のほうが優先的に発生するのでしょう。しかし _cursEvent がまったく発生していないわけではないので、_cursOver をキャッチした段階で DIALOG(_cursEvent)してやることで、侵入したウインドウのＩＤを得られる、ということではないかと。

　まあ、同時に同じイベントが発生するなら、どっちかを優先するしかないですね。
いやあ、いい勉強をしました。感謝感謝。

はじめまして、ハイノと申します
FBはじめて、まだ1日めの初心者です

質問させていただきます
まず第一
　　FBとVBは、根本的な違いはあるのですか？
　　あと、それぞれの特徴はなんですか（具体的ではなく）
次に第二
　　マニュアルを持ってないのですが、それに取って代わることができ初心者に優しい、参考書はありますか、あったら教えてください

これから頑張って、最終的にＲＰＧを作りたいと思っています（4年後計画）
もし、このMLにＲＰＧを作ったことがある人や、ゲーム会社に勤めている人がいたらプログラムの志などを教えていただければ、これからの励みになるので、是非送ってください
これから、よろしくお願いします

ハイノ

ハイノさん，はじめまして。

FBとVBの差ですが，詳しいことは大先輩からレスが付くとしてプログラムスタイルのイメージ的な事では，FBがC風の組方でVBがC++風となります。どちらも両方できれば良いのですが，初心者のうちは平行して勉強すると頭がこんがらがります(^^; 今までのハイノさんのプログラム経験と今後の希望を考えて両方のチュートリアルを終えた時点で馴染みやすい方を重点的に勉強してはどうでしょう。FBもVBも全く別のものというわけではなく，密接に関連がありますので，片方に慣れてくると他方もなんとなくわかってきます。(本当か？>わし)
とりあえず，付属のチュートリアルを終えてみてはどうでしょう。
具体的な疑問が出れば，気楽に聞いてください。
私の答えられる範囲で大うそを教えてしんぜましょう(笑)
これからもよろしく。
　　　　　　　　　　　　　　　　　　　　　　　　　　根来

追伸

マニュアルがないということは，正規購入ではなく友人から購入されたわけですね。それなら購入した友人からマニュアルをもらってください。ユーザー登録の変更もお忘れなきよう。そうしないとあなたか友人の方のいずれかが不正コピーをした事になりますから気を付けてください。

ベンさん，返事が遅くなりました。

私のアイドル処理に問題があったのですね。(T_T
良い勉強をさせてもらいました。ON MOUSE FN 〜を使う事でマウスイベント発生前にマウス処理に突入するという不具合は直りました。ありがとうございます。
実は今日一日，新たにリソース周りのエラーが出ていて苦労していたのですが，先ほど解決した次第です。ですから，カーソルに絡むアプリ前面時の問題は明日調べるつもりです。
なんか言いだしっペの私が遅れているので焦ります。(^^;

その他，イベント周りで調査中なのが，二つのウインドウが開いている場合のアクティブとリフレッシュイベントの組合わせです。ウインドウ同士が重なっている場合は，アクティブ->リフレッシュとなりますが，重なっていない場合はアクティブのみです。ここで，ウインドウの再描画をどちらのイベントでもすると重なっている場合に更新が二回も起ってしまいます。せっかくオフスクリーンを使っていてもちらつくような遅いようなでなんとか一度限りに抑えたいのです。フラグを作るか何か方法を考えようと思っています。

丁寧なレスをありがとうございました。
　　　　　　　　　　　　　　　　　　　　　　　　　根来

古籏一浩です。

At 0:43 97.10.11 +0900, Satoshi N wrote:
>まず第一
>　　FBとVBは、根本的な違いはあるのですか？
>　　あと、それぞれの特徴はなんですか（具体的ではなく）
　FBはMac用BASIC, VBはWin用BASICといった所でしょう。
　ＦＢ、ＶＢともに持っていますが、同じBASICでも文法も違いますが一番異なるのはプログラムの組み立て方が違う所でしょうか。ＦＢは付属のPascal Converterで最新のToolboxを使用できますが、ＶＢだとVC++が必要だったり肝心なポイントが大抵こけてます（笑）。ＶＢでシューティングゲームを作るのはあかんというのも定説です。ＶＢ５ではＶＢ４と比べて多少マシになったみたいですが。

>次に第二
>　　マニュアルを持ってないのですが、それに取って代わることができ初心者に優しい、参考書はありますか、あったら教えてください
　参考書はありません（笑）
　が、私のページやＦＢ−ＭＬの方々のページを参考にすれば十分参考書に匹敵すると思います。おまけに電話代だけですし(^^;

>これから頑張って、最終的にＲＰＧを作りたいと思っています（4年後計画）
>もし、このMLにＲＰＧを作ったことがある人や、ゲーム会社に勤めている人がいたらプログラムの志などを教えていただければ、これからの励みになるので、是非送ってください
　ゲームは私は毎週１本ペースで作成していますがf(^^;
　プログラムの志（？）は簡単で「作りたい」という情熱だけです。
　技術よりも情熱の方が大事という事です。
　私は過去にＲＰＧ作って面倒くさくて辞めてシューティングゲームやキャラクターゲームなどリアルタイムアクションがほとんどです。
　ＦＢでもスペースハリアーくらいは作成できます。
　ＲＰＧは速度を問わないので、そうい点では楽ですね。

　ベン/矢野勉　です。

At 11:26 AM 97.10.11, sendai_5300LTB wrote:
> その他，イベント周りで調査中なのが，二つのウインドウが開いている場合のアクティブとリフレッシュイベントの組合わせです。ウインドウ同士が重なっている場合は，アクティブ->リフレッシュとなりますが，重なっていない場合はアクティブのみです。ここで，ウインドウの再描画をどちらのイベントでもすると重なっている場合に更新が二回も起ってしまいます。せっかくオフスクリーンを使っていてもちらつくような遅いようなでなんとか一度限りに抑えたいのです。 > フラグを作るか何か方法を考えようと思っています。
　え？　他のウインドウと重なっていない場合は、そもそも再描画の必要がないんじゃないですか？　重なってないってことは、もともと描かれていたものは消えてないわけですから。
　どちらにせよ、描画は意地でもリフレッシュ時に行います。なんらかの事情で描画を強要したくなったら、自分で描画するのではなく、描画したい領域を CALL INVALRECT(rect) で「無効化」します。そうすればシステムが自動的にリフレッシュイベントを起こし、無効になっている部分を描画しようとします。リフレッシュに反応するようになっていれば、あとはほっといても描画されますね。オフスクリーンを使っているなら、かなりスムーズな描画が期待できます。

　描画はリフレッシュでのみ行い、必要なときは、描画を直接行うのではなく、リフレッシュを強要する、というのがMacintosh流の描画法です。（なんか「マニアーナの法則」とかいうたいそうな名前がついているらしい）

　ハンドブックの p72 にも「ウインドウの内容は _wndRefresh イベントを受け取った時のみ描画されるべきです」というようなことが書いてありますね。

yukiです。

ベンさんwrote:
> 　ううむ、僕も確認しました。どうもウインドウ内にカーソルが入ったときは、_cursOver イベントしか発生しませんねえ(^^;)
中略
> 　結局、原さんのやっているように、_cursOver と _cursEvent を併用するしかないでしょう。推測するには、ウインドウにカーソルが侵入した場合、_cursOver (ID=0)と _cursEvent (ID=window id) が同時に発生してしまうため、イベントしては _cursOver のほうが優先的に発生するのでしょう。しかし _cursEvent がまったく発生していないわけではないので、_cursOver をキャッチした段階で DIALOG(_cursEvent)してやることで、侵入したウインドウのＩＤを得られる、ということではないかと。
なるほど、そういうことでしたか。以前悩んだときに窮地の策として使ったものです。
調べていただいてどうも有難うございました。

原　幸久(yuki@alles.or.jp)

yukiです。

ベンさんwrote:
> 　いや、関数定義の引数に @ がついているところも、アドレスではなく実体を要求します。実体を渡すと、コンパイラが自動的に変数の先頭アドレスをとって、srcRect& にいれてくれます。これはどういうことかというと、「参照渡し」「値渡し」の違いを理解する必要があります。解説は後半に。
>
中略
> 　@ は同じマークでも、変数の頭につけた場合と、関数の定義で使用した場合とでは意味がちがうってことです。
詳しい解説を有難うございました。5回ぐらい読み返してやっと理解できました。
雲が晴れたような感じです。本当に有難うございました。

原　幸久(yuki@alles.or.jp)

ベンさん，こんばんわ。

>他のウインドウと重なっていない場合は、そもそも再描画の必要がないんじゃないですか？　重なってないってことは、もともと描かれていたものは消えてないわけですから。
　いやあ，ごもっともです。説明をしていなかった私の落度ですが，実は例のスクロールバーの件の続きでして，独自のコントロールが付いているのです。ウインドウが背面に廻った時に，スクロールバーと同様に独自のコントロールもディアクティブにしたいのが，リフレッシュ以外のイベントで再描画している理由です。しかし，実際の描画が分散するのはまずいと思いまして，教えて頂いたCALL INVALRECT(rect)を使用することで実にすっきりとしたコードになりました。動作も正常です。ただ，CALL INVALRECT(rect)を多用するとアップデートイベントがたくさん発生するので，もう少し絞り込みたいと思います。例外として，Tile Switcher でのアプリ切り替えでは，アップルイベントでの呼び出しのせいかアクティブになったウインドウの独自コントロールをアクティブなものに差し替えることができていません。これは今後の課題として勉強したいと思います。

　先日来お騒がせしていたカッチョイイウインドウの件ですが，今回CALL INVALRECT(rect)を教えて頂いたおかげで，完全な動作をするものが完成しました。
　ありがとうございました。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　根来

皆様こんにちわ。磯村＠埼玉です。

　またまた、教えを乞いに来ました。今度は、「PICTURE FIELDの属性はどうやったら得られるのか？」です。

　PICTURE FIELDを作ってそこにPICTを貼り込むには、
　　　PICTURE FIELD ID%,&pictHandle&,(x1%,y1%)-(x2%,y2%),_framedNoCR,_scaledPict
　とやれば良いことは分かっています。表示されているPICTを反転させるには、
　　　PICTURE FIELD ID%,,,_statFramedInv
とやれば、出来ることも何とか分かりました。

　しかし、ここから詰まってしまいました。
　やりたい事を手順にすると、
１）クリックされたフィールドのPICTを反転する。
２）クリックされたフィールド以外の属性を調べ、
３）反転されていたら元に戻す。
４）反転されていなければそのまま。
となります。このときに３）を実行する方法が分かりません。TEHANDLEを使うのかとも思いましたが、どうやらそうでもないみたいですし。

　どうすりゃいいでしょう。むぅぅん。

I should be happy to be of any service to you!!

古籏一浩です。

At 11:20 97.10.13 +0900, Yuji Isomura wrote:
>　やりたい事を手順にすると、
>１）クリックされたフィールドのPICTを反転する。
>２）クリックされたフィールド以外の属性を調べ、
>３）反転されていたら元に戻す。
>４）反転されていなければそのまま。
>となります。このときに３）を実行する方法が分かりません。TEHANDLEを使うのかとも思いましたが、どうやらそうでもないみたいですし。
>
>　どうすりゃいいでしょう。むぅぅん。
　人にもよりますが、私のやり方では、あらかじめPICT FILEDの状態を保存しておく配列または変数を用意します。
　反転を切り替えるには（変数がaとした場合）

a = a XOR 1

　で反転できますので手軽にできるのではないかと思います。
　あとはa = 0なら普通の表示、1だったら反転表示にすればよいのではないでしょうか。

古籏一浩です。

At 21:49 97.10.12 +0000, sendai_5300LTB wrote:
>は，SetPortを使っています。どちらでもうまく動いているようですが，実際のところSetPortとSetGWorldは違うものというか使い分けが必要なものなのでしょうか。インサイドマックを読んではみましたが，個別の機能はわかるのですが，使い分けというか利用の上での差がわかりません。お手数ですが，教えてはいただけないでしょうか。
　単にグラフィックデバイスを指定するかしないか、といった当たりだと思います。ここらへんは、あまり私は詳しくないのですがFB1.0.2の時にSetPortでどうしても動かなかったので、仕方なくSetGWorldで指定したら無事に動作したという経緯があって、それからSetGWorldを使ってます。
　ここらへんは他の人の方が詳しそうですf(^^;