弘樹さん，はじめまして。
私も初心者です。弘樹さんがおっしゃっている壁を私も経験しましたので，初心者なりの意見を話します。しっかりしたお話しは，古籏さんやベンさんからレスが付くと思います。
弘樹さんの質問は，PICTやTEXTの格納場所にメモリがいるのはわかるが，固定数値を書けば済むところになぜ変数を使用するのかと捉えました。
WINDOW 文に直接数値を書く方法で良いのではということですが，これは結論として好みの問題が大きいのではと考えます。
別関数でRectを求めて，変数でWINDOW文を記述するのはそれ相応の理由があります。あなたがPICT画像を読み込んで，ちょうど良い大きさのウインドウを展開しようとすると，毎回WINDOW文のRect部分が変化しますよね。こういう場合は変数を使用する確たる理由があります。
また，ウインドウのサイズを定数で用意しておけば，将来ウインドウサイズを変更したいと考えたときに，定数の変更で事足ります。ソースの複数箇所でウインドウサイズの指定をしていると，サイズ変更のメンテナンスが大変になります。
しかし，小さなプログラムではウインドウも一つで良いし，サイズの変更も苦にならないので，関数を減らしてソースを短くしたいと考えたとしましょう。これはこれで正しく動作するプログラムができるでしょうから，弘樹さんが納得するのなら構わないわけです。
反面，プログラムというのは拡張されてゆくものですよね。弘樹さんも自作のソースが増えてくると，以前作ったソースをベースとして新しいプログラムを作られることでしょう。その時にソースの中に固定の数値が書かれていると，応用が利きにくくなりますし，変更を忘れるとバグの元となったりします。小さいプログラムのうちは無駄に思えることも，将来の拡張を考えるとあながち無駄でもないわけです。やはり，拡張性を考えると固定数値の書き込みはやめて，変数や定数の利用が良いのではと思います。
私も始めは，このような説明を受けてもやはり無駄な作業に思えました。
しかし，いろいろと作っていくと考えが変わりました。この問題は方法論の話しですから，固定値を使わない理由も個人の好みを打ち消すほどの強い力はありません。ですが，先人が試行錯誤の上で編み出した方法なのですから，この方法に慣れておくとサンプルソースが理解しやすくなりますし，弘樹さんのソースも他の人が読みやすくなると思います。どういう場合にメモリを使えばいいのかという話しですが，かちかちの規則を自分で作るより，変数にできると気付いた部分のみ変数にするといいのではないでしょうか。ソースコードの芸術性を追及するのは，もっと慣れてからで良いと思います。せっかく始めたプログラミングなのですから，作った・動いた・嬉しいをたくさん楽しむほうがいいですね。
余計なおせっかいだったかも知れません。長文失礼しました。
この度、fb-mlに参加させていただきました、重松修と申します。
よろしくお願いいたします。
現在、FBでCGIを作成しており、FBでインターネット関連のアプリケーション、WWWサーバ・メールサーバ（=BBSホスト）、Netscapeプラグイン（=BBS専用クライアント）を作るのが将来の目標です。何時になるかは不明ですけど。(^_^;;
現在AppleScriptで作った掲示板でFB CGI会議室をやっていますので、CGIに興味がある方は是非いらしてください。http://www.ravi.ne.jp/FBII/です。
買ったのは半年前で、使い始めてまだ一月くらいしか経っていませんので、とんちんかんな質問をするかもしれませんが、よろしくお願いいたします。
プログラム講座 初級編10を拝見しました。
そこでかねてよりの疑問があります。
err% = FN HLOCK(myHandle&)
err% = FN HUNLOCK(myHandle&)
err% = FN DISPOSHANDLE(myHandle&)
のerr%です。一体何のためにあるのでしょうか？
マニュアルを読むと失敗することがありますから、チェックを行ってくださいとあります。DISPOSHANDLEでこけたら、一体どうしろというのでしょうか？
モードに問い合わせたのですが、歯切れが悪く（早い話しめったにないから）深く考えなくてもよい、ということでした。
今の所は、gProgramEnds%を_trueにしています。
IF err% THEN gProgramEnds%=_true
古籏一浩です。
At 1:10 97.6.26 +0900, Osamu Shigematsu wrote:
>err% = FN HLOCK(myHandle&)
>err% = FN HUNLOCK(myHandle&)
>err% = FN DISPOSHANDLE(myHandle&)
>のerr%です。一体何のためにあるのでしょうか？
HLOCK,HUNLOCKはなぜかこの形式で、ちょっと謎です。
CALL HLOCK(myHandle&)
CALL HUNLOCK(myHandle&)
といった感じでよさそうなものですが・・・
作者に聞かないとわからないですf(^^;
>マニュアルを読むと失敗することがありますから、チェックを行ってくださいとあります。DISPOSHANDLEでこけたら、一体どうしろというのでしょうか？
こける場合は、どんな時でしょう？
DISPOSHANDLEでエラーになる時は「ハンドルが確保されていないのに破棄しようとした」という場合でしょう。
IF err% <> 0 then PRINT "ハンドルが正常に確保できていないかもしれません"
といった警告メッセージでも用意しておけばデバッグが楽になると思います。
確実にハンドルの確保、破棄を行っているのであればはっきりいって不要です。
重松です。さっそくありがとうございます。
> HLOCK,HUNLOCKはなぜかこの形式で、ちょっと謎です。
> CALL HLOCK(myHandle&)
> CALL HUNLOCK(myHandle&)
> といった感じでよさそうなものですが・・・
> 作者に聞かないとわからないですf(^^;
こちらは半分呪文のような感じで理解しておきます。(^_^)
> こける場合は、どんな時でしょう？ > DISPOSHANDLEでエラーになる時は「ハンドルが確保されていないのに破棄しようとした」という場合でしょう。
> IF err% <> 0 then PRINT "ハンドルが正常に確保できていないかもしれません"
> といった警告メッセージでも用意しておけばデバッグが楽になると思います。
> 確実にハンドルの確保、破棄を行っているのであればはっきりいって不要です。
そうなのですか。安心しました。マニュアルの例文がなんせ、
LONG IF hndl&
osErr%=FN DISPOSHANDLE(hndl&)
IF osErr%<>_noErr THEN PRINT "Something wrong!"
END IF
だったのでhndl&がnilでない＝きちんと確保できている、と認識してましたから、「something」っていう良くわからない表現はやめてくれ！とか思いました。
お陰様ですっきりしました。
川野＠佐賀大学です．
At 9:57 PM +0900 97.6.25, KaZuhiro FuRuhata wrote:
> これは、プログラムをみないとわかりません。
> 変数の名前の間違い、型の違いも可能性があります。
>
> 「もう〜わからん」という場合は怪しい部分のリストをMLに流してみると誰かが答えてくれると思いますよ。
昨日から目さらのようにしてプログラムをチェックしました．そこで，古旗さんの教えてくれたプログラムでLONG FNとなっている部分をLOCAL FNに変えたところうまく行きました．どうやら，LONG FNでは変数の受け渡しがうまく行かなかったようです．まったく，初歩的な失敗をしてしまいお恥ずかしいかぎりです．
今後ともよろしくお願いいたします．
古籏一浩です。
At 12:42 97.6.26 +0900, Yoshinobu KAWANO wrote:
> 昨日から目さらのようにしてプログラムをチェックしました．そこで，古旗さんの教えてくれたプログラムでLONG FNとなっている部分をLOCAL FNに変えたところうまく行きました．どうやら，LONG FNでは変数の受け渡しがうまく行かなかったようです．まったく，初歩的な失敗をしてしまいお恥ずかしいかぎりです．
無事に出来て良かったですね(^^)
そういえば、関数の戻り値について全然説明してませんでしたf(-.-b
LOCAL FN test!
END FN = a
でaには浮動小数が返ります。
LOCAL FN test
END FN = a
でaには整数値が返ります。
LOCAL FN test#
END FN = a
で倍精度の値が返ります。
EXCELなら倍精度で返すようにした方がいいかなと思います。
＃回線工事のため、しばらく音信不通になる可能性大です。
＃という事で、よろしく〜(^0^)/
古籏一浩です。
At 3:03 97.6.26 +0900, Osamu Shigematsu wrote:
>そうなのですか。安心しました。マニュアルの例文がなんせ、
>LONG IF hndl&
>osErr%=FN DISPOSHANDLE(hndl&)
>IF osErr%<>_noErr THEN PRINT "Something wrong!"
>END IF
>だったのでhndl&がnilでない＝きちんと確保できている、と認識してましたから、「something」っていう良くわからない表現はやめてくれ！とか思いました。
マニュアルは、ちょっと駄目ですね、わかりにくい。
せっかくの日本語版なんだから、もうちょっと良いマニュアルをと思うのですが・・・
時間があったらオンラインで、まっとうなリファレンスを作りたいなと思っています。ＦＢ ver 1.02の時は一応あったんですけどね〜
古籏一浩です。
At 22:59 97.6.25 +0900, Osamu Shigematsu wrote:
>この度、fb-mlに参加させていただきました、重松修と申します。
>よろしくお願いいたします。
いらっしゃいませm(_ _)m
一応、ここの管理人の古籏一浩です。
>現在AppleScriptで作った掲示板でFB CGI会議室をやっていますので、CGIに興味がある方は是非いらしてください。http://www.ravi.ne.jp/FBII/です。
AppleScriptでやっているんですか、偉いですね(^^)
私は通信関係には弱いので気が引けてしまいます・・・
掲示板とかも作った事ないし・・・
古籏一浩です(^^)/
初級編１２を追加しました。
今回は簡単なMac->UNIXへの改行コード変換です。
メモリ内容を読み出し、書き込み後一気にファイルに書き出すという一連の処理を覚えてもらえばいいかなと思います。
こういうパターンで処理を行えばFuture BASICでも高速でできます。
> 初級編１２を追加しました。
> 今回は簡単なMac->UNIXへの改行コード変換です。
> メモリ内容を読み出し、書き込み後一気にファイルに書き出すという 一連の処理を覚えてもらえばいいかなと思います。
>
> こういうパターンで処理を行えばFuture BASICでも高速でできます。
重松です。
えーっと、私のホームページに拙い漢字コード識別ルーチンを載せてあります。漢字コード変換ルーチンも近日中に公開しますので、興味がある方はご覧ください。URL=http://www.ravi.ne.jp/FBII/です。以上、閑古鳥状態のホームページの宣伝でした。
初級編、ということで割愛されたのでしょうが、例えば、CRのみやLFのみをCR+LF（要するにWindows用）に変換するとファイルサイズが確保してあるハンドルを越えますよね？また、これは単にCRとLFを検索して、それぞれCR+LFに置換するルーチンでもあると思います。
そして、一応2バイト文字の分割に配慮して置換ルーチンも作ったのですが、これも検索文字列に対して置換文字列のほうが長いと当然、関数に渡されたときよりも、処理後の戻り値のほうが文字列が長くなってしまいます。短くなる分には一行に構わないのですが、長くなるときはどう処理すればよいのでしょうか？
# 現在は作業用領域を32Kとってlength&に文字列の長さを格納し、処理しています。ただ、メモリの効率が非常に悪く、こまってます。
あと、IM:Textをダウンロードしたのですが、FutureBasicハンドブックの279ページのFN MUNGERを使えば置換が出来そうなのですが、印刷に時間がかかって書籍を買おうかと思っています。バイスはボッタクリなので、どなたか良心的な値段でIMを扱っているお店を知りませんでしょうか？
始めまして。私はＦＢでプログラマの様なものをしているものですがＦＢ&ＰＧについてちょっとお聞きしたいとメールしました。
１）ＦＢでコンパイルに失敗する
まったくおこらない時もあるのですが、ひどい時には10回に1回しかコンパイルに成功しない時がある。
２）ＰＧがプログラムを消してしまう
ＰＧで画面を変更して保存すると、プログラムの一部（大抵は.MAINファイル）が消えてしまう。
３）ＰＧで定数が消されてしまう
２番と同じようにＰＧで保存すると、メニュー定数などの一部（大抵がポップアップメニュー）が消されてしまう。
などが頻繁におきているのですが、どこにも（販売元のモードのホームページや、ほかの方のホームページでも）それらしい記事をみないので、私のところだけなのかと困っている次第です。
もし、これらの解決法&回避法などを知ってる方がおりましたら教えていただけないでしょうか？
よろしくお願いします。
みなさん，こんばんわ。
実は最近また悩んでいることがあります。
とりあえず，お絵描きソフトはできつつあるのですが，Undo処理の構築で悩んでいます。サンプルなどでは描画前のPICTをHANDTOHANDでまるごと保存してますよね。でも巨大な画像の場合にはメモリ不足がおきるのではと心配しています。さらに複数回の取消をサポートしようと思うとなおさらメモリが心配です。巨大な画像をコピーすると，反応速度が遅くて書き出しの部分の描画が間に合わないなどの弊害がでています。
市販のソフトでは，かなりの大きさの画像でも，いつUndo用にデータを保存しているのかと思うくらいの速度がでていますよね。ここまでは求めませんが，せめてストレスを感じない程度に高速化したいのです。
画像のUndoをするためには，元画像をそのまま保存するしか手がないのでしょうか。なにか良い案があれば教えてもらえないでしょうか。
それと，次の構文が意味がわからず悩んでいます。
END FN = ( Aborted = _False )
これは，Aborted が偽の場合に，関数の値を偽にするということなのでしょうか。ちょっと読みずらくて困ります。
At 2:53 PM 97.6.26, KaZuhiro FuRuhata wrote:
>>>>>
LOCAL FN test!
END FN = a
でaには浮動小数が返ります。
LOCAL FN test
END FN = a
でaには整数値が返ります。
LOCAL FN test#
END FN = a
で倍精度の値が返ります。
EXCELなら倍精度で返すようにした方がいいかなと思います。
<<<<<
あれ？ これでいいの？
いや、関数名に型を付けるのはいいんですが、返す値が整数になっている (a のことね) んですが、これって関数の型にあわせて自動的に返り値まで変換されるものだったんですか？
てっきり
LOCAL FN test#
'some codes
END FN = result#
というように、返す値に型をきっちり付けないと (result#) だめなんじゃないのかな？ 実験してないから不明だけど、僕はいつも、関数の型と返り値の型は一致するようにしてきましたので。
ベン / 矢野勉 です。
At 7:28 PM 97.6.26, Tomoya Aoyagi wrote:
> １）ＦＢでコンパイルに失敗する
> まったくおこらない時もあるのですが、ひどい時には10回に1回しかコンパイルに成功しない時がある。
コンパイルに失敗するってのは、なにかエラーでもでるんですか？ それなら、エラーの内容がわからないと、返事のしようもありませんし。それともいきなりフリーズするとか。
とりあえず、STAZ folder 内の STAZExtras が壊れているのかもしれません。このファイルだけ新品と交換してみてください。ついでに、プログラムにプロジェクトファイル (paiマークがついたやつ) があれば、これも一度破棄してください。
> ２）ＰＧがプログラムを消してしまう
> ＰＧで画面を変更して保存すると、プログラムの一部（大抵は.MAINファイル）が消えてしまう。
具体的にどこがきえますか？ .MAINの上部にある、{PG3} というマーク (なんかコメントとして「ここは PG が使うからけすなっ」と書いてあるところ) の間ならば、消えるのが仕様です。PG は保存のたびに、マーカーの部分を新しい情報で書き換えます。たとえば、使用する FLTR を増やしたり減らしたりすると、INCLUDE 文を増やすなり減らすなりします。その段階で、その部分に書かれていた情報はすべて消去されます。
もしここのことなら、単純に、マーカーよりもあとに記述すれば、問題なく動きます。
> ３）ＰＧで定数が消されてしまう
> ２番と同じようにＰＧで保存すると、メニュー定数などの一部（大抵がポップアップメニュー）が消されてしまう。
これは PG の作るファイルのうちの、Project.GLBL ファイルのなかでのことですね。おそらく、ファイルの一番下に、PG がメニュー定数を書き込むところに、自分の定義した定数を書き込んでいるのでしょう。これも上記と同じで、マーカー内部ですから、PG は保存の度に、新しいメニュー情報に基づいて、この部分を削除して書き換えます。PG の作り出すファイルには、基本的に「ここに書け」と書かれている部分以外のところに自分のコードを書いてはいけません。GLBL ファイルのばあいは、ファイル上部に英語で「ここにあんたの定数なりグローバルなりを定義しないさい」という部分があります。(一番うえのはずです) そこに書くかぎりは、基本的には消されません。
あと、これは PG というより FB の問題ですが、コンパイルに失敗したときだと思うけど、とつぜんファイルの内容がからっぽになることがあります。僕はいままでに３度経験してまして、２度目からは作業前にかならずバックアップを取るようになっていたので、被害は一日分ですみました。
ここで教訓
「プロジェクト用にディスクを用意して、作業前に必ずバックアップを取ってからプログラムを始めよう」
いや、まじで、いまからでもしておいたほうがいいですよ。とくに、単独ファイルではなく、プロジェクト・ファイルを使っているひとはね。
ベン/矢野勉 です。
PICT のアンドゥについては、新しく絵を描いた部分だけ、どっかに取っておく、という手段しかないんじゃないでしょうかね？ つまり、たとえば、四角の選択領域をカットしたら、クリップボードにその四角の部分の画像を記録しますよね。それと似たような感じで、画像を描いたら、その部分の元画像を、自分でメモリを確保してクリップボードのように記録しておくのです。
ポイントは、「画像だけを記録しておくのでなく、画像の位置も一緒に記録しておく」ことです。これがわからないと復元できないからです。
DIM RECORD UndoBufRec
DIM UBzTop% '"top
DIM UBzLeft% '"left
DIM UBzBottom% '"bottom
DIM UBzRight% '"right
DIM UBzDataH& '"実際の画像へのハンドル
DIM END RECORD .UndoBuffRec
とうようなレコードを用意します。UBzTop% から UBzRight% までは、Rect 形式での、画像の位置を表わしています。UBzDataH& は実際の PICT データが入ります。これで四角領域のデータの保存が可能になります。
Macintoshの QuickDraw では、rect はあらゆる図形の基本的な姿です。円を描くときも、４点の位置を与えてやると、その内側に円が描かれるわけです。ですので、たとえば、ユーザーは円ツールで円を描いた場合でも、始点と終点を結ぶ四角形が得られるわけです。
この四角形の位置と画像をメモリに保存し、それからやっと、指定された円を描きます。いまあなたの手元には、円が描かれた画像、メモリ内に位置情報とともに保存された四角形画像、の２つがあります。ユーザーが Undo を選んだら、話は簡単です。PICTURE ステートメントなり、Toolbox の DrawPicture なりで、保存しておいた画像をもう一度描いてやればいいわけです。このときに、前と同じく再描画する部分の画像を保存しておけば、Redo が実現できます。(そうです、メニュー名が違うだけで、やっていることは同じなんです。)
ポイントは、「とにかく四角の画像として保存しておくこと」です。自由曲線だろうが、三角形だろうが、それらを囲む最小の四角さえ得られれば、すべて同じ形式で保存できます。四角なら位置を記録しておくのも簡単です。画像も OpenPicture とCopyBits の組み合わせでいけます。 OpenPicture については、handbook の p306の recording a picture をみてください。
#このあたり、古旗さんのページにありましたよね。例の草稿のなかにあったのは確実だけど...>古旗さん
おそらく多くの画像ソフトが同等の仕組みを応用しているとおもいますよ。(まあ、しぼればもっとしぼれるけど...丸なら丸として保存しておくとか。でもあまりに手間がかかります)
> それと，次の構文が意味がわからず悩んでいます。
>
> END FN = ( Aborted = _False )
>
> これは，Aborted が偽の場合に，関数の値を偽にするということなのでしょうか。ちょっと読みずらくて困ります。
これは逆です。Aborted が偽のときに、返り値を真にします。カッコ内部が IF のときと同じ条件式でして、「Aborted が _false かどうか」とテストして、その結果を返しているわけです。
At 7:54 AM 97.6.26, 仙台7200/90 wrote:
>しっかりしたお話しは，古籏さんやベンさんからレスが付くと思います。
よばれて飛び出ました。ベン/矢野勉 です。
> 弘樹さんの質問は，PICTやTEXTの格納場所にメモリがいるのはわかるが，固定数値を書けば済むところになぜ変数を使用するのかと捉えました。
>
> WINDOW 文に直接数値を書く方法で良いのではということですが，これは結論として好みの問題が大きいのではと考えます。
はい。僕も同意します。
> 別関数でRectを求めて，変数でWINDOW文を記述するのはそれ相応の理由があります。あなたがPICT画像を読み込んで，ちょうど良い大きさのウインドウを展開しようとすると，毎回WINDOW文のRect部分が変化しますよね。こういう場合は変数を使用する確たる理由があります。
まったくそのとおりです。PICTから Rect情報を引き出して、それをもとに WINDOWステートメントで適切なサイズのウインドウを作成することになります。もちろん (left,top)-(right,bottom) という形でもいけますが、@rect 一発でいけるのは楽ですね。PICT からは Rect レコード形式で取り出すことになりますから。
> また，ウインドウのサイズを定数で用意しておけば，将来ウインドウサイズを変更したいと考えたときに，定数の変更で事足ります。ソースの複数箇所でウインドウサイズの指定をしていると，サイズ変更のメンテナンスが大変になります。
はい、結局はこれなんです。良いプログラム関係書では、「文字列や数値を直接使うのは、できるだけさけろ。定数か変数を使え」とかならず書いています。これには「見やすさ」と「変更のしやすさ」が理由です。
見やすさでは、Mac のプログラムで使われるものとしては、スクロールバーの幅があります。これは16と決まっているのですが、プログラム中にいきなり 16 という数字が出て来るのと、_ScrollBarSize という定数が出て来るのとでは、どちらが見やすいでしょうか。
変更のしやすさという面では、たとえば、フィールドの高さを最初は 20 としたものの、いろいろ考えて 40 にしようとおもった場合、もしフィールドは２０個あったらどうしましょう。もし定数なり変数なりを使っていれば、一箇所を変更するだけで用が足りてしまします。楽ですね。
このように、変数や定数を使うのはらくで、しかも見やすいのです。しかも拡張するときにも楽です。たとえば件のウインドウの例でいえば、将来、ウインドウを作成した後に、もとのサイズより 10 ピクセルだけ大きい rect が必要になったらどうしましょう？ 直接書き込んだ数字に暗算で 10 ずつ足したり引いたりして、また直接書き込みますか？ それとも、CALL INSETRECT(winRect, -10, -10) で済ませますか？ 一つの関数内でこれを５回繰り返す必要が出たら？ ありえないといえるでしょうか？
とまあ、プログラムは常に変更を加えながら書くもんですから、なるべく変数として確保しておいたほうが、あとあとやりやすいんです。
あと、定数/変数を使う場合、直接書き込む場合を区別するのがたいへん、というのもあります。「ここは直接入力でいけるだろ」とか思っていたところが、実はそうじゃなかった、てなこともあります。で、こういうミスをさける一番の方法は「ひとつのやり方に徹底的に従う」ことなんですね。一つ一つは手間でも、最終的にはこういうマメなひとが先に完成させてしまうのが、プログラムの世界ですね(^^) コメントを書く/書かないなどを考えると分かりやすい(^^;)
ファイル一つ程度の、しかもたった一枚のウインドウくらい、別に直接入力にしたってかまいません。はい。ぼくだってそうするでしょう。しかし、変数や定数を使うのに慣れておくのは、たいへん良いことでもあります。PG級のプログラムになると、このありがたみがよ〜くわかります。はい。
さて、第２の本題。
「メモリの確保」ですが、ぼくは DIM による変数宣言を「メモリの確保」だと思ったことはないなあ。だって、DIM つかわずにいきなり変数をしようしても、結局、そこで DIM が使われたかのように自動的にメモリ確保が行われるんですよ。「メモリ」などというからわかりにくいんで、「変数」と「メモリブロック」は区別すべきでしょう。
「変数」とは、自由に値を変更できる、プログラム上での「記号」。定数は、値を変更できない「記号」。
「メモリブロック」とは、プログラマの指示によって始めてつくられる、情報の保管場所。必要な時に必要なだけ要求できる。保管場所の位置は変数に記録しておく。
そう、変数はプログラムにおいては記号だと考えるべきです。つまり、DIM をメモリ確保のステートメントだと考えるのではなく、変数の使用宣言だと思えばいいのです。COMPILE オプションに _dimmedVarsOnly を指定すると、前もって宣言された変数 (つまり DIM された変数) 以外は使用禁止になるので、よくわかります。いちどやってみましょう。
もちろん変数も２バイトなり４バイトなりのメモリ空間を (１秒にもみたない時間でしょうが) 一時的にはとるでしょう。しかしそんなことは気にする必要はとくにないでしょう。どうせかってに消えるんですから。
一方、プログラム中にずっと存在して欲しい情報 (たとえば、現在編集中のテキストだとか、画像だとか) は、メモリ内に保管場所を用意して入れておきます。いちいちディスクからちまちま読み込んでられないので、一気にメモリ内に読み込んで、メモリ上にあるテキストなり画像に変更を加えるのです。(でないと、なんかするたびにディスクにアクセスするでしょ) で、保存が選ばれたら一気にディスクに書き込むわけです。
メモリブロックが必要になるのは、だいたいは「最後までのこっていてもらわんと困る場合」「変数のサイズではぜんぜん大きさが追い付かない場合」に使いますね。30K のテキストを編集するのに、いったいどの変数に 32K もためておけますかね？
こう考えてはどうでしょう。メモリという倉庫があって、「こんだけ商品があるから、場所おくれ」と要求したら、そんだけあけてくれる。で、商品を引き上げにくるまでずーとあずかってくれるわけです。で、「君の倉庫は 123 番ね」とかいってくるので、この位置を記録しておかないと、荷物がどこにあるかわからない、と。
どのくらいのサイズを確保する必要があるか、ですが、これは「いるぶんだけ」としかいいようがない。普通はメモリブロックの確保前に、必要なサイズは分かっているもんなんです。ファイルから読み込むなら、ファイルサイズ分のメモリブロックを用意するとかね。必要なサイズが分かってない、ってのは、プログラム上のミスが考えられます(^^;)
みなさん、ご無沙汰しております伊藤です。
以前古籏さんの講座でAIFFの非同期再生をやってまして、それを元に自分でアプリを作成しました。
同一階層のAIFFを全て読み込み、ボタンで前後に進めるというモノです。
が、前後いずれかに進むと、割り当てバッファによっては次の音が出ず、現在の音が止まらなかったり……という症状が出てしまいました。どうやら一旦現在の音を止めてから次の音を出さなければならないようで、古籏さんからも資料を頂いたりしたのですが、実力が伴わず保留状態でした。
長々書き込んでしまいましたが、先日某FBサイトでサウンド関連のリストを入手しまして、中身を探ると……ありました。半信半疑でしたがダメモトで自分のリストに加えると……ちゃんと音が止まりました。
以下のルーチンがそれです。まだ半信半疑なので本当に良いのかはわかりません。音は止まるようになったけど裏で不都合が生じているとか、そんな事ないですか？
CLEAR LOCAL MODE
DIM MySndCmd;_sndCSize
DIM sndErr
LOCAL FN sndStop(sndChanPtr&)
MySndCmd.cmd = _quietCmd
MySndCmd.param1 = 0
&@MySndCmd.param2,0&
sndErr=FN SNDDOIMMEDIATE(sndChanPtr&,MySndCmd)
MySndCmd.cmd=_flushCmd
sndErr=FN SNDDOIMMEDIATE(sndChanPtr&,MySndCmd)
END FN=sndErr
早速のお返事ありがとうございました。私の説明不足でうまく内容を伝えられなかったのでもう一度詳しく質問させてください m(__)m
>> ２）ＰＧがプログラムを消してしまう
> 具体的にどこがきえますか？ .MAINの上部にある、{PG3} というマーク (なんかコメントとして「ここは PG が使うからけすなっ」と書いてあるところ) の間ならば、消えるのが仕様です。PG は保存のたびに、マーカーの部分を新しい情報で書き換
>（中略）
> もしここのことなら、単純に、マーカーよりもあとに記述すれば、問題なく動きます。
どうも、{PG4}以下のプログラムが消されてしまうようです。
以下の例でいうと、、、
INCLUDE "STR#.INCL"
INCLUDE "ICON.FLTR"
'{PG4}
>'=========================================
>"@Filters" :SEGMENT
>'=========================================
>LOCAL FN KeyFilter
> DIM tKeyPress$
>の行以下が消えてしまうのです。
最近では偶然にもSEGMENT文でプログラムを区切ったら消されることがなくなったと（友人から）報告をうけていますが、これも単なる偶然が重なっているだけかもしれないので何ともいえません。
>> ３）ＰＧで定数が消されてしまう
>ね。おそらく、ファイルの一番下に、PG がメニュー定数を書き込むところに、自分の定義した定数を書き込んでいるのでしょう。これも上記と同じで、マーカー内部で
それが、違うのです。自分が記述した定数ではなくて、ＰＧが吐き出すべき定数が消えてしまっています。ＰＧの「Menu Constants」を見ると定数名のみで肝心な数値がないのです。
また、実際にプログラムを吐き出してみると、その定数すらなくなっているのです。
例）
_User21W31 = 36 'Obj:User Item 21
_User21W32 = 37 'Obj:User Item 21
_User21W33 = 38 'Obj:User Item 21
Item 21
Item 21
Item 21
Item 21
Item 21
_User21W40 = 45 'Obj:User Item 21
「.GLBL」ファイルの中で上のようにいきなり定数もなければ数値もなくなっています。
> あと、これは PG というより FB の問題ですが、コンパイルに失敗したときだと思うけど、とつぜんファイルの内容がからっぽになることがあります。僕はいままでに３度経験してまして、２度目からは作業前にかならずバックアップを取るようになっていたので、被害は一日分ですみました。
私もやられました。それ以来実行する時には必ず保存するようになりましたけどね（笑）
> いや、まじで、いまからでもしておいたほうがいいですよ。とくに、単独ファイルではなく、プロジェクト・ファイルを使っているひとはね。
ありがとうございます。これからはこまめにバックアップとります。消えてしまってなくよりはマシですからね(^^;;;
ご無沙汰しております。yukiです。
また質問があるのですが、実は今デジタルカメラのExif（JPEG互換形式）の読み込み、書き込みのできるプログラムを計画しております。しかしJPEGの資料を本屋に探しにいきましたが、実際にプログラムできるような内容のものを入手することができませんでした。そこでお願い／質問なのですが、どなたか公開可能なJPEG読み込みのルーチンをお持ちの方はいらっしゃいませんでしょうか？またはJPEG形式についてプログラムできるくらい詳細に説明されているHPをご存じの方はいらっしゃいませんでしょうか。
宜しくお願いいたします。
重松さん，ベンさん，ありがとうございます。
END FN = ( Aborted = _False ) のAbortedが偽の場合に関数の戻り値を真にするというのがわかって幸せです。これは，FB2のプロジェクトマネージャーが生成するサンプルの全ファイルクローズの関数で利用されていたのです。
しかし，もうすこしわかりやすい書き方をしてくれてもいいのにと思います。
メモリのことですが，
DIM t,l,b,r
t;8 = myRect
という書き方を見たのですが，こんなんありなんですね。
でも「;8」の理屈がわかっていないので，いまいち不安です。
PICT Undo の件ですが，最小限のデータを位置情報と共に保存するということですか。
なるほど，これなら極端にメモリが消費されることもありませんね。
しかし，ちょっと考えたのですが，エアブラシ処理の時などは，複数の画像を連続して書き込みますが，最小限のRectを求める前に描画が実行されますので，前記の方法ではうまくいかないなぁと気付きました。ブラシの画像を一枚描画するたびに，該当する領域を順番にリスト構造で保存するという案を考えました。しかし，始めの一枚と次の画像は，半分以上重なっています。これでは，保存したデータのほとんどの部分が重複していることになります。これを解決するために，先にウインドウにのみ描画し，一連の描画が終わった段階で領域を求めてオフスクリーン側の描画をしようかとも考えています。でも，これってすごくややこしいし，次のブラシ動作が続けて始まると間に合わないのではと心配です。何かこういう場合の逃げ方はないものでしょうか。
ベン / 矢野勉です。
At 6:12 AM 97.6.28, 原 幸久 wrote:
> また質問があるのですが、実は今デジタルカメラのExif（JPEG互換形式）の読み込み、書き込みのできるプログラムを計画しております。しかしJPEGの資料を本屋に探しにいきましたが、実際にプログラムできるような内容のものを入手することができませんでした。そこでお願い／質問なのですが、どなたか公開可能なJPEG読み込みのルーチンをお持ちの方はいらっしゃいませんでしょうか？またはJPEG形式についてプログラムできるくらい詳細に説明されているHPをご存じの方はいらっしゃいませんでしょうか。
画像系は弱いんで、詳しくは古旗さんが復活するのを待つとして、JPEGの変換なら、QuickTime のルーチンでできるはず。(まあ、QuickTime がインストールされているかどうかをチェックしなくちゃいけなくなりますけど) 実はやり方はしりませんで、とりあえずそういう事実がある、ということだけ NIFTY の FMACPRO でしばしば目にしています。
というわけで、New Inside Macintosh: QUICK TIME が参考資料として挙げられますね(^^;)
こんにちはMONO/伊藤智則です。
At 11:32 PM 97.6.27, Tsutomu YANO wrote:
> ベン / 矢野勉です。
>
> At 6:12 AM 97.6.28, 原 幸久 wrote:
> > また質問があるのですが、実は今デジタルカメラのExif（JPEG互換形式）の読み込み、書き込みのできるプログラムを計画しております。しかしJPEGの資料を本屋に探しにいきましたが、実際にプログラムできるような内容のものを入手することができませんでした。そこでお願い／質問なのですが、どなたか公開可能なJPEG読み込みのルーチンをお持ちの方はいらっしゃいませんでしょうか？またはJPEG形式についてプログラムできるくらい詳細に説明されているHPをご存じの方はいらっしゃいませんでしょうか。
>
> 画像系は弱いんで、詳しくは古旗さんが復活するのを待つとして、JPEGの変換なら、QuickTime のルーチンでできるはず。(まあ、QuickTime がインストールされているかどうかをチェックしなくちゃいけなくなりますけど) 実はやり方はしりませんで、とりあえずそういう事実がある、ということだけ NIFTY の FMACPRO でしばしば目にしています。
>
> というわけで、New Inside Macintosh: QUICK TIME が参考資料として挙げられますね(^^;)
僕も画像のviewerを作るつもりなのですが、やはりPICTだけじゃなくてJPEGにも対応させたいと思いました。しかし資料は全然見つかりませんでした。そういう困っている時期に丁度MODEからTOOLZの知らせが……飛びついてしまいました。
ご存じかもしれませんがざっと……
Apple Eventフィルタ
Apple Talkフィルタ
BCD->SANE Converter
DragNDropフィルタ
FuturePAINTII(^_^;)
ImageFILES$フィルタ JPEG、TIFF、etc.
NetChkSNフィルタ
RdWrUtilitiesフィルタ
At 8:25 AM 97.6.28, 仙台7200/90 wrote:
> しかし，ちょっと考えたのですが，エアブラシ処理の時などは，複数の画像を連続して書き込みますが，最小限のRectを求める前に描画が実行されますので，前記の方法ではうまくいかないなぁと気付きました。ブラシの画像を一枚描画するたびに，該当する領域を順番にリスト構造で保存するという案を考えました。しかし，始めの一枚と次の画像は，半分以上重なっています。これでは，保存したデータのほとんどの部分が重複していることになります。これを解決するために，先にウインドウにのみ描画し，一連の描画が終わった段階で領域を求めてオフスクリーン側の描画をしようかとも考えています。でも，これってすごくややこしいし，次のブラシ動作が続けて始まると間に合わないのではと心配です。何かこういう場合の逃げ方はないものでしょうか。
はじめまして、葛原といいます。
エアブラシのUndoは市販のアプリケーションをみていると、だいぶ苦労しているみたいですから、FutureBasicではもっと大変かもしれません。
コーディングはしていませんが、考え方だけ、言いますと、一つのUndoは、マウスがダウンしたところから、アップしたところまでのマウスの動きによって、エリアが確定できると思います。とすると、実際に、作業中の描画は直接、画面ウィンドウにかかせ、書かせる前の画面をオフセットスクリーンにでも、退避しておきます。
エアブラシの動作が終わったときに、エリアが確定できるでしょうから、Undo用のPicture分、メモリを確保し、オフセットスクリーンからコピーしておけば、いいのかなと思います。
＃マシンにとっても私にとっても、酷な季節がやってきました。(/_;)
＃今年は、マジでエアコンを買わないとダメかなぁ。(^_^;)
葛原さん，ありがとうございます。
なかなか難しそうな処理ですね。しかし，考え方はわかりましたのでフローチャートを書き書きして，じっくりと作っていきたいと思います。
# 私もエアコンが欲しいです。でもお金がない(T_T) 今後とも，宜しくお願いします。
またまた，根来です。
連続で質問してもうしわけないのですが，C言語のヘッダファイルをFB2用に書き換えているのですが，変数型の変換がうまくできなくて困っているのです。ちょっと助けてもらえないでしょうか。
C言語で次のようなヘッダがあります。
struct body {
unsigned short body_1;
unsigned char body_2;
short body_3[3];
};
struct MyRecord {
char head_1;
char head_2;
short head_3;
long head_4;
Ptr head_5;
long head_6;
BodyRecord body[2];
};
この外部構造体を何とかFB2で読み込みたいと考えています。
ポインタは正しく取得できているのですが，FB2で上記フォーマットの構造体を収めるレコードのDIM RECORDに失敗しているようなのです。
上記の各変数の型はFB2でどうすればいいのでしょうか。
私はとりあえず下の宣言をしたのですが，うまくいかないようです。
DIM RECORD MyRecord
DIM head_1%
DIM head_2%
DIM head_3%
DIM head_4&
DIM head_5&
DIM head_6&
DIM body_1_1%
DIM body_1_2%
DIM body_1_3_1%
DIM body_1_3_2%
DIM body_1_3_3%
DIM body_2_1%
DIM body_2_2%
DIM body_2_3_1%
DIM body_2_3_2%
DIM body_2_3_3%
DIM END RECORD _MyRecord
初っ端のhead_1%から値がおかしいような気がするのですが，赤っ恥じを覚悟で書きました。どなたか教えてください。
ベン/矢野 勉 です。
> メモリのことですが，
> DIM t,l,b,r
> t;8 = myRect
> という書き方を見たのですが，こんなんありなんですね。
> でも「;8」の理屈がわかっていないので，いまいち不安です。
これがわかると、メモリ空間というのがどういうものなのか、多少わかってきます。しかも、これって、Ｃ言語も顔負けの「アセンブラな」処理だったりもします(^^;)
まず、DIM t,l,b,r の各要素は整数ですので、２バイトです。 で、t,l,b,r と連続して DIM すると、連続した空間が確保されます。この場合は 2 x 4 = 8 で８バイトのメモリ空間が確保されて、便宜上２バイトずつに分割されるわけです。
で、ミソは、Toolbox の定義レコードである Rectレコードは
DIM RECORD Rect
DIM top%
DIM left%
DIM bottom%
DIM right%
DIM END RECORD .Rect
というふうになっています。これは DIM t,l,b,r と同じように、８バイトのメモリ空間を、頭から２バイトずつ分割します。つまり DIM t,l,b,r というは、Rectレコードを宣言したのと同じことになります。
次に、t;8 = @myRect (たぶん上記のは書きまちがいじゃないですか？ @ が無いし) というのは、BLOCKMOVE というステートメントの省略形です。左側に変数を、右側にアドレスを置き、左側の変数に「;バイト数」とつけることで、右側のアドレスから t へ (正確には t のアドレスへ) バイト数分だけ内容がコピーされます。
つまり「BLOCKMOVE @myRect, @t, 8」と同義です。代入文に似ているので、わりと使い易いです。
で、先ほど書いたように、t,l,b,r は連続した８バイトの領域を取っています。つまり、t のアドレスから８バイト書き込むと、t,l,b,r ８バイト分がすべて埋められることになります。これは Rectレコードの内容が埋められたのとまったく同じことを意味します。(レコードとかをわすれて、２バイトずつ top, left, bottom, rightと分割された８バイトのメモリ空間という意味では一緒なわけです)
よって、
CALL SETRECT(t, 0,1,2,3)
とすると、t=0, l=1, b=2, r=3 となりまして、
CALL SETRECT(theRect, 0,1,2,3)
とした時にくらべると、theRect.top% とかする必要がなくなります。まあ、BLOCKMOVE の省略形を知っているといろいろ便利です。このやり方で、事実上あらゆるレコードを DIM だけで実現できます。結構おもしろいですよね。
> しかし，ちょっと考えたのですが，エアブラシ処理の時などは，複数の画像を連続して書き込みますが，最小限のRectを求める前に描画が実行されますので，前記の方法ではうまくいかないなぁと気付きました
はい。たしかに、エアブラシなりエンピツツールなりの場合、「マウスダウン点とマウスアップ点を頂点とする四角形」を求めるしか、最小の四角形は得られませんね。これはぼくは、いったん全画像をオフスクリーンにコピーして、描画はウインドウにし、描画終了段階で、最小の四角形の画像をオフスクリーンに退避しておいた画像からコピーして保存しておく、という手段しか思いつきません。
強いていえば、マウスが動いたときに、新しい位置で四角形を得て、そのサイズで保存、という手もありますが、スピードから考えて現実的じゃない気がしますね。
#しかしまあ、Photoshop ですら「画像サイズの３倍のメモリが必要」らしいですし、２倍ですむんならいいような(^^;)
ううーむ、古旗さん、なんかありますかね？
ベンさん，いつもありがとうございます。
>DIM t,l,b,r の各要素は整数ですので、２バイトです。で、t,l,b,r と連続して DIM すると、連続した空間が確保されます。
わかりました。連続して確保されるという保証がないから危ないのではと考えていたのです。誤った考えでした。
>t;8 = @myRect (たぶん上記のは書きまちがいじゃないですか？ @ が無いし) というのは、BLOCKMOVE というステートメントの省略形です。
はい，書き間違えです。恥ずかしい。
この省略形の説明をさきほどマニュアルで見つけました。なるほど，80バイト程度までならBLOCKMOVEより早いのですね。勉強になります。
>このやり方で、事実上あらゆるレコードを DIM だけで実現できます。
理屈ではそうなのですが，私の今の技量ではCからの移植はかなりしんどいです。
Cで無茶な型変換をしている場合に，対処に困ってしまったりしています。
私がメモリ回りの操作に弱いのがばればれですね。
エアブラシの場合、「マウスダウン点とマウスアップ点を頂点とする四角形」ではまずいと考えます。例えば，円を描いた場合など，ダウン点とアップ点は近似値をとる場合があります。結局，マウス座標を取得するたびに最大領域の判定をしなくてはならないのでしょうか。なんか泥沼化してきたなぁ。ベンさんにいちゃもんを付けるつもりではありません。他の初心者の方が混乱するのではと思い，発言したのです。他意はありません。
わたしも，ううーむ、古旗さん、なんかありますかね？
ベンさん，いつもありがとうございます。
>DIM t,l,b,r の各要素は整数ですので、２バイトです。 で、t,l,b,r と連続して DIM すると、連続した空間が確保されます。
わかりました。連続して確保されるという保証がないから危ないのではと考えていたのです。誤った考えでした。
>t;8 = @myRect (たぶん上記のは書きまちがいじゃないですか？ @ が無いし) というのは、BLOCKMOVE というステートメントの省略形です。
はい，書き間違えです。恥ずかしい。
この省略形の説明をさきほどマニュアルで見つけました。なるほど，80バイト程度までならBLOCKMOVEより早いのですね。勉強になります。
>このやり方で、事実上あらゆるレコードを DIM だけで実現できます。
理屈ではそうなのですが，私の今の技量ではCからの移植はかなりしんどいです。
Cで無茶な型変換をしている場合に，対処に困ってしまったりしています。
私がメモリ回りの操作に弱いのがばればれですね。
エアブラシの場合、「マウスダウン点とマウスアップ点を頂点とする四角形」ではまずいと考えます。例えば，円を描いた場合など，ダウン点とアップ点は近似値をとる場合があります。結局，マウス座標を取得するたびに最大領域の判定をしなくてはならないのでしょうか。なんか泥沼化してきたなぁ。ベンさんにいちゃもんを付けるつもりではありません。他の初心者の方が混乱するのではと思い，発言したのです。他意はありません。
わたしも，ううーむ、古旗さん、なんかありますかね？
重松@Raviです。
アプリケーションとは別のリソースの読み書きについて教えてください。
STR、STR#、TEXTを操作したいと思っています。
読み込みについては、STR、STR#はハンドブックP205〜に詳しく説明がありますので、わかりましたし、とりあえず、TEXTは以下のプログラムで読み込めているようです。
LOCAL FN GETTEXT(txtH&,id%)
resH& = FN GETRESOURCE (_"TEXT",id%)
LONG IF resH&
size&=FN SIZERESOURCE(resH&)
LONG IF size&<=32768
BLOCKMOVE [resH&],[txtH&],size&
XELSE
size&=0
END IF
CALL RELEASERESOURCE (resH&)
END IF
END FN=size&
ところが、書き込み方が全くわかりません。
また、volRefNum%の計算の仕方が不明なため任意の場所にある（例えば、「Macintosh HD:Data:myFile"」と言った具合）ファイルを読み書きすることが出来ません。
大抵は、FILES$を使う様になっているので、もとから引き数として渡されるためパスからvolRefNum%を求めるサンプルを見つけられませんでした。
HTTPdの仕様上、リソースフォークに格納したデータが外部から見えなくなるのでデータをリソースフォークに格納したいと思っています。
よろしくお願いいたします。
★すいません、また教えて下さい。
★ネットスケープや茄子やComniftyなどで使われている、ウィンドウ上部のボタンやポップアップメニューなどの作り方について教えて下さい。
ＰＧで適当に配置してやればもちろん入るのですが、その下にテキストやグラフィックのウィンドウを置くと、右のスクロールバーを固定にしないとうまくいきません。できればウィンドウの拡大縮小にリンクして、ちゃんと上部のボタン等を固定したまま作りたいのです。
ネットスケープでは上部からちょっと下がった位置に所からスクロールバーが始まっていてるのですが、ああいったウィンドウの作り方がＰＧやＦＢＩＩのマニュアルに載っていないような気が・・（載っていたらすいません）。
あと、ウィンドウ下部にも作りたいです。
すいません、教えて下さいm(__)m。
★古籏さんのＨＰ、勉強させてもらってます。
とくに、仮想グラフィックポートの所は、マニュアルを読んでもイマイチぴんと来なかったのですが、よくわかりました。 おかげで、「アナログ時計」が針がチカチカしないでちゃんと表示できるようになりました。ありがとうございます。
上の質問と重複しますが、いろいろなウィンドウの作り方、オプションについての講座も期待します(^_^)。
では、よろしくお願いしま〜〜す。
yukiです。
ベンさん、伊藤さん御礼が遅くなりましたが、大変有難うございました。
モードからJPEGコンバータ等が発売されているのは承知していたのですが、値段が3万円近くてとても手が出せそうにないためにJPEGの読み込み法を探していました。でもなんでツールキットが本体価格に近いというへんなことになるのでしょうかねぇ？
米国ではツールが単体で販売されているようですが、これはモードの策略なのでしょうか？？
また、QuickTimeでJPEGがコンバートできるとは知りませんでした。さっそくIMもダウンロードして少し勉強したいと思います。
ただ、デジタルカメラのメーカー（富士写真フィルム）がコードリソースの形でExif(JPEG)Reader/Writerを公開しているのを発見しましたのでこれを使って見たいと思っています。（使用範囲は限@定されるようですけれど...）
ただただ、ここでもまた問題が山積していました。
##### "Code Resorce"ってどういうふうに使うのでしょうか？ #####
RESOURCE .....
でやるのかなとも思ったりしていますが、見当も付かない状況です。どなたか使ったことがある、またはここにサンプルがあるという情報を御存じの方がいらっしゃいましたらお知らせください。
よろしくお願いいたします。
根来さん、ベンさん、有り難うございました。ウィンドウのサイズというのは、画像を開いたりするときも、画像の大きさが一定でないときがあるので、その時にウィンドウサイズが変数ならば、画像の大きさに合わせて開くことが出来るんですね。勉強になりました。FutureBASIC IIのプログラミングマニュアルの練習問題は参考になりましたが、プログラミングマニュアルを終えた人が対象の練習問題がもう少し欲しかったです。問題じゃなくてもいいですね。古籏さんのサンプルプログラムを見ながら少しづつ覚えていきたいと思います。
yukiです。
先ほど送信いたしました内容の補足をいたします。Code Resourceの使用について、付属のテキストでは"Code Warrior 9"を推奨と書いてあります。
はたしてFBIIで使えるものでしょうか？
yukiさん，こんにちは。
>"Code Resorce"ってどういうふうに使うのでしょうか？
ここで直接せつめいするだけの力は，私にはないので申し訳無いのですが，www.aladdin.co.jp/HASP.html からFB2でCode Resorceを利用しているサンプルのソースコードが入手できます。Callの仕方など参考になると思います。
古籏一浩です。
とりあえず回線は復旧しましたが、何か変f(^^;
初級編１３と中級編１１を追加しました。
ハイペースで追加しているつもりですが、なんか全然需要においついてませんf(-.-b
古籏一浩です。
At 19:28 97.6.26 +0900, Tomoya Aoyagi wrote:
>１）ＦＢでコンパイルに失敗する
>まったくおこらない時もあるのですが、ひどい時には10回に1回しかコンパイルに成功しない時がある。
FB IのプログラムをFB II-Jでコンパイルしようとすると、うちでは１回目は成功し２回目はシステムエラーという、とんでもない（？）事態になってしまいます。
FB Iでもときどきコンパイルに失敗する事がありますが、大抵はリソースがらみで失敗してしまうようです。
古籏一浩です。
At 0:49 97.6.27 +0900, Tsutomu YANO wrote:
> EXCELなら倍精度で返すようにした方がいいかなと思います。
>
> あれ？ これでいいの？
>
> いや、関数名に型を付けるのはいいんですが、返す値が整数になっている (a のことね) んですが、これって関数の型にあわせて自動的に返り値まで変換されるものだったんですか？
aが整数になるかどうかはプレファレンスによって違うと思いましたよ。
私のは整数ではなく浮動小数の設定になっていますので・・・
FB 1.0.2ではちゃんと動作しましたが・・・
FB 2では違うの？
> というように、返す値に型をきっちり付けないと (result#) だめなんじゃないのかな？ 実験してないから不明だけど、僕はいつも、関数の型と返り値の型は一致するようにしてきましたので。
その方がいいでしょう。
更新頻度が激しいので(^^;、後のフォローはおまかせです〜
＃ところでＰＧのホームページは、まだですか?
古籏一浩です。
At 19:51 97.6.29 +0900, 堀 浩一郎 wrote:
>★古籏さんのＨＰ、勉強させてもらってます。
> とくに、仮想グラフィックポートの所は、マニュアルを読んでもイマイチぴんと来なかったのですが、よくわかりました。
> おかげで、「アナログ時計」が針がチカチカしないでちゃんと表示できるようになりました。ありがとうございます。
それは、よかったですね(^^)/
とりあえず、再来月の予定としてはシンプルなお絵かきソフトでも作ろうと考えています。
ＰＧだと楽だろうけどf(-.-b
> 上の質問と重複しますが、いろいろなウィンドウの作り方、オプションについての講座も期待します(^_^)。
FB IIでしかできない（作成できない）ウィンドウもあります。
私は普段使っているのがFB 1.0.2なのでf(^^;
ウィンドウまわりはベンさんのホームページ等に期待した方がいいかな(^^;
古籏一浩です。
At 13:08 97.6.29 +0000, 仙台7200/90 wrote:
>エアブラシの場合、「マウスダウン点とマウスアップ点を頂点とする四角形」ではまずいと考えます。例えば，円を描いた場合など，ダウン点とアップ点は近似値をとる場合があります。結局，マウス座標を取得するたびに最大領域の判定をしなくてはならないのでしょうか。なんか泥沼化してきたなぁ。
エアブラシだとマウスクリックの点を基準にして円形等で描画すると思いますが、その半径はあらかじめわかっているはずですから、同様に矩形座標を求めればOKです。
>わたしも，ううーむ、古旗さん、なんかありますかね？
いちいち矩形を求めるのが面倒というのであればスキャンライン毎（水平ライン毎）にメモリに追加していく方法もあります。
すでに取り込んである場合はパスして取り込んでいない場合のみメモリにコピーするといった具合です。
多くのソフトではベンさんが解説したような方法を使用しています。私が書いた方法だと一応メモリかディスク容量があれば、いくらでもアンドゥが可能です。
また、変わり種の方法としては描画座標とペンの種類のみを記録しておくというのもあります。ビットマップではありませんがイラストレーターやフリーハンドが、この方法です。
古籏一浩です。
Future BASIC Mailing Listの発言をまとめました。
http://www.shiojiri.ne.jp/~openspc/FB/
から入れます。
全発言は約500KBありますので、ご注意のほどを。
とりあえず５０発言ごとまとめてみました。
Subjectからもハイパーリンクできるようにと思いましたが挫折しました（笑）
こんなんで、許して〜
古籏一浩です。
At 5:35 97.6.27 +0900, 伊藤とものり wrote:
>以下のルーチンがそれです。まだ半信半疑なので本当に良いのかはわかりません。音は止まるようになったけど裏で不都合が生じているとか、そんな事ないですか？
>
>CLEAR LOCAL MODE
>DIM MySndCmd;_sndCSize
>DIM sndErr
>LOCAL FN sndStop(sndChanPtr&)
>
> MySndCmd.cmd = _quietCmd
> MySndCmd.param1 = 0
> &@MySndCmd.param2,0&
>
> sndErr=FN SNDDOIMMEDIATE(sndChanPtr&,MySndCmd)
> MySndCmd.cmd=_flushCmd
> sndErr=FN SNDDOIMMEDIATE(sndChanPtr&,MySndCmd)
>END FN=sndErr
長い曲ならば大丈夫ですね(^^)
サウンドマネージャーのバージョンによっては笑えないバグもありますがゲームでなければ、これで大丈夫だと思います。
こんばんは、田島です。
yukiサン wrote:
>モードからJPEGコンバータ等が発売されているのは承知していたのですが、値段が3万円近くてとても手が出せそうにないためにJPEGの読み込み法を探していました。でもなんでツールキットが本体価格に近いというへんなことになるのでしょうかねぇ？米国ではツールが単体で販売されているようですが、これはモードの策略なのでしょうか？？
昨日、個人的にした同じ質問のモードからの回答です。全文そのまま載せます。
>日本でのTOOLSの売り方として、なるべく本国に値段を近づけるようにするために商品の種類を１つ（全部のセット）にしております。そのためCD-ROM１枚に全てのモジュールを入れ込んでおりまして、日本語マニュアルも付けて本国でのセット価格の$249.50を1$=\120換算した値段で販売しております。
>
>この様な理由により単品売りはしない考えですので、どうぞ宜しくお願いします。
だそうです。（イマイチ納得できないが)
このこなれた文章と、迅速な対応から察すると、この手の問い合わせ多いみたいですね。
ちなみに、"The Jpeg Playground II"というサイトがありました。
http://www.phlab.missouri.edu/~c675830/jpeg_tests/testgrnd.htm
参考まで。
古籏さん，ありがとうございます。
> エアブラシだとマウスクリックの点を基準にして円形等で描画すると思いますが、その半径はあらかじめわかっているはずですから、同様に矩形座標を求めればOKです。
すいません，私の書き方が悪かったようです。私が言いたかったことはエアブラシ処理は，円を連続して描画することでブラシ効果を出しますがユーザーがマウスダウンしてからマウスアップするまでの一連の円描画をひとつの取消単位とします。この取消単位のUndo領域はユーザーがマウスを動かした範囲+エアブラシの円の直径を含むrect領域だと考えます。 このrectを求める方法に苦心しています。
> いちいち矩形を求めるのが面倒というのであればスキャンライン毎（水平ライン毎）にメモリに追加していく方法もあります。
> すでに取り込んである場合はパスして取り込んでいない場合のみメモリにコピーするといった具合です。
この方法は高度すぎて私はイメージが理解できません。(T_T)
水平ライン自体がどのようなものなのかわかっていないようです。
きっと高速な処理が実現できるのだろうと思いますが，ついていけないのが悲しいです。
ホームページの追過分を読ませて頂きました。
いつもながらわかりやすくて助かります。過去ログもこれから読みたいと思っています。ありがとうございます。
根来です。先日同じ内容のメールを出したのですが，クラリスメールの調子が悪くちゃんと送れていないのではないかと思い，再送することにしました。
ただ単にレスが付かないだけなのかもしれないので，その際はご容赦下さい。(でも，それはそれで悲しいなぁ^^;)
C言語のヘッダファイルをFB2用に書き換えているのですが，変数型の変換がうまくできなくて困っています。助けてもらえないでしょうか。
C言語で次のようなヘッダがあります。
struct body {
unsigned short body_1;
unsigned char body_2;
short body_3[3];
};
struct MyRecord {
char head_1;
short head_2;
long head_3;
Ptr head_4;
BodyRecord body[2];
};
この外部構造体を何とかFB2で読み込みたいと考えています。
外部構造体へのポインタは正しく取得できているのですが，FB2で上記フォーマットの構造体を収めるレコードのDIM RECORDに失敗しているようなのです。
上記の各変数の型はFB2でどうすればいいのでしょうか。
私はとりあえず下の宣言をしたのですが，うまくいかないようです。
DIM RECORD MyRecord
DIM head_1%
DIM head_2%
DIM head_3&
DIM head_4&
DIM body_1_1%
DIM body_1_2%
DIM body_1_3_1%
DIM body_1_3_2%
DIM body_1_3_3%
DIM body_2_1%
DIM body_2_2%
DIM body_2_3_1%
DIM body_2_3_2%
DIM body_2_3_3%
DIM END RECORD _MyRecord
初っ端のhead_1%から値がおかしいような気がするのですが，FB2では1バイトの大きさの変数を用意することはできないのでしょうか。
BLOCKMOVEでこのレコードに一気に値を読み込もうとしたのですが，結果は当然おかしくなりました。構造体へのポインタに各項目の位置を加算して，項目一つづつ取得するしかないのでしょうか。Cのヘッダがかなり複雑で長いため，全ての項目を一つづつアドレス指定で取得するとソースコードが膨大になってしまいなんとか他の方法はないものかと考えています。特にCでの型がFB2でどう扱えば良いのかがよくわからず困ります。longは&で良いのでしょうが，charやunsignedの付く項目など試行錯誤で使っていますが，正しい変換はどういうものなのかご存じありませんか。
古籏一浩です。
At 13:14 97.7.1 +0000, 仙台7200/90 wrote:
>ただ単にレスが付かないだけなのかもしれないので，その際はご容赦下さい。(でも，それはそれで悲しいなぁ^^;)
ちゃんと送られてきてます。
単にレスがつかないだけですね(^^;
>C言語のヘッダファイルをFB2用に書き換えているのですが，変数型の変換がうまくできなくて困っています。助けてもらえないでしょうか。
>初っ端のhead_1%から値がおかしいような気がするのですが，FB2では1バイトの大きさの変数を用意することはできないのでしょうか。
私は構造体、レコードを多用しないタイプなんで詳しくありませんが
１バイトは
DIM head%_1;1
で確保できませんでしたっけ？
>BLOCKMOVEでこのレコードに一気に値を読み込もうとしたのですが，結果は当然おかしくなりました。構造体へのポインタに各項目の位置を加算して，項目一つづつ取得するしかないのでしょうか。Cのヘッダがかなり複雑で長いため，全ての項目を一つづつアドレス指定で取得するとソースコードが膨大になってしまいなんとか他の方法はないものかと考えています。特にCでの型がFB2でどう扱えば良いのかがよくわからず困ります。longは&で良いのでしょうが，charやunsignedの付く項目など試行錯誤で使っていますが，正しい変換はどういうものなのかご存じありませんか。
多分以下の方法で変換すればOKです。
ただ、レコード内に配列は含むことができないんでしたっけ？
char a; DIM a%;1 unsigned char a; DIM a%;1（ちょっとプログラムで工夫必要） int a; DIM a%またはa& unsigned int a; DIM a%またはa&（ちょっとプログラムで工夫必要） long a; DIM a& unsigned long a; DIM a&（ちょっとプログラムで工夫必要） long long a; DIM a&,b&（プログラムで連結必要） Handle a; DIM a& Ptr a; DIM a& float a; DIM a& （ってこりゃ駄目ですねぇ） double a; DIM a&;8（ってこりゃ駄目ですねぇ） Str255 a; DIM 255 a$
私はFBのレコードはつかわなくて、構造体（レコード）分だけメモリを確保しておいて
_head_1 = 0 ' char
_head_2 = 1 ' short
_head_3 = 3 ' long
_head_4 = 7 ' Ptr
_body = 11 ' body[2]
でポインタを出して置いてオフセットでやってしまう事があります。
a% = PEEK (pointer& + _head_1)
で１バイト読み出せますし
a% = PEEK WORD(pointer& + head_2)
で２バイト読み出せます。
が、こういう面倒な事を避けるためにレコードなり構造体があるんですけど
なんでＦＢのは配列駄目なんでしょう？
古籏一浩です。
At 13:14 97.7.1 +0000, 仙台7200/90 wrote:
> ひとつの取消単位とします。この取消単位のUndo領域はユーザーがマウスを動かした範囲+エアブラシの円の直径を含むrect領域だと考えます。このrectを求める方法に苦心しています。
確かに求める式はその通りです。
一番楽なのはオフスクリーンを、もう１つ用意してコピーしておいてアンドゥ用に使うという方法で、これはすでにベンさんなどからコメントがついています。
簡単（？）に矩形を求めるのであれば（とりあえず左側）
rectLeft = mouseX - r
マウス移動
if (mouseX - r) < rectLeft then rectLeft = mouseX - r
if rectLeft < 1 then rectLeft = 0
［mouseXはマウスのX座標、rはエアブラシの半径］
といった具合でよいのではないでしょうか？
> この方法は高度すぎて私はイメージが理解できません。(T_T)
> 水平ライン自体がどのようなものなのかわかっていないようです。
> きっと高速な処理が実現できるのだろうと思いますが，ついていけないのが悲しいです。
やはり論より証拠、サンプルを作らないといけませんねf(^^;
頑張って今週中に、まずアイドリング処理を作成し、その後アンドゥの方法も３回ほどにわけて解説しましょう。
>ホームページの追過分を読ませて頂きました。
>いつもながらわかりやすくて助かります。過去ログもこれから読みたいと思っています。ありがとうございます。
過去ログはかなり膨大です。
今度から５０たまったら追加していきたいと思います。
思いのほか、大変でしたのでf(^^;
やはり日頃の積み重ねが重要ですね。
＃ドラッグドロップ処理も残ってたなあ・・・
yukiです。
仙台7200/90さん、Tajima Haruさん、レスありがとうございました。まずCodeResの件ですが、一つのコードリソースで一つのファンクション、さらにFutureBasicIIで書いたものであれば使用することはできるのですが、Cで書かれていてさらに一つのコードリソース内に複数のファンクションが入っているようなので非常に困っています。メーカーからもアドバイスはもらえそうにありません。やはりTOOL KITは購入しないと駄目なのでしょうか？
またJPEGですが、図書館に”わかりやすいJPEG/MPEG2の実現法”という資料がありました。これにはデコードの方法が若干書いてありましたので勉強してみたいと思います。Cのサンプルプログラムは何名かの方に紹介していただいたのですが、ソースファイル数が20以上あることと、Cを余りよく分からないために挫折しかけていました。
とにかくJPEGの複雑さは痛いほど良く分かりました。しばらくこの問題の解決には時間がかかりそうです。
いつもROMだけですませてしまっているbakabon奥迫です。
今、256*256/8bit/pixの生データをPICTファイルにしたいのですが、その方法がわかりません。Handbookの「画像を記録」の章のOpenCPicture関数を使ったサンプルプログラムが近いような気がするのですが、どう応用していいのかがわからないのです。
また手持ちの「Macintoshアプリケーションプログラミング」に、OpenCPicture関数はpictureのレコーディングを開始する。と説明されているのですが、レコーディングってなんや？っていう人間なので困っています。
どなたかOpenCPicture関数についての説明をサンプルプログラム等でしていただけないでしょうか？
古籏一浩です。
At 23:55 97.7.1 +0900, bakabon@msic.med.osaka-cu.ac.jp wrote:
>今、256*256/8bit/pixの生データをPICTファイルにしたいのですが、その方法がわかりません。
これ私のページの中級編に解説付きで載せてありますf(^^;
でも普通記録する時に自分自身のグラフポートにCOPYBITSとは考えないですよねぇ・・・
古籏一浩です。
At 21:22 97.7.1 +0000, akiyuki wrote:
>TOOL KITは購入しないと駄目なのでしょうか？
中 略
>またJPEGですが、図書館に”わかりやすいJPEG/MPEG2の実現法”という資料がありました。これにはデコードの方法が若干書いてありましたので勉強してみたいと思います。Cのサンプルプログラムは何名かの方に紹介していただいたのですが、ソースファイル数が20以上あることと、Cを余りよく分からないために挫折しかけていました。
簡単かつ確実で手抜きな方法があります。
よってTOOL KITは購入する必要はありませんし、高価な書籍を購入する必要もありません。
まずMacintosh Easy Openが「入」になっている必要があります。
あと確認していませんがQuickTimeが必要です（多分）。
これで何も考えずにCALL DRAWPICTUREでJPEGの表示が可能です。
FB IIだけでなくFB 1.0.2でも可能です。
powerMac8500+FB1.0.2で確認してあります。
といった具合でどうでしょうか？
＃あっけない回答で、すみませんですf(-.-b
古籏一浩です。
中級編１２を追加しました。
今回はお絵かきソフトを作るという事で数回に分けて解説します。
今回はマウス座標の取得とカーソル形状の変化です。
次の次でアンドゥの処理、その次にアイドリング描画を予定してます。
ハイペースなつもりだけど、まだ需要においついてないですねf(-.-b
おはようございます。葛原です。
また、机上の空論ですが...(^-^;
At 10:14 PM 97.7.1, 仙台7200/90 wrote:
> エアブラシ処理は，円を連続して描画することでブラシ効果を出しますがユーザーがマウスダウンしてからマウスアップするまでの一連の円描画をひとつの取消単位とします。この取消単位のUndo領域はユーザーがマウスを動かした範囲+エアブラシの円の直径を含むrect領域だと考えます。このrectを求める方法に苦心しています。
rectを求めるというのは、以外と簡単で、マウスダウンしたときに、ブラシの分だけ、まずセットしておきます。
そのあと、マウスアップまでのループの中で、移動した分、rectを広げていけばいいと思います。
ループ時のチェックですが、x,yをマウス位置、rを円の半径、マウスは円の中心と考えています。
if left > x-r then left = x-r
if top > y-r then top = y-r
if right < x+r then right = x+r
if bottom < y+r then bottom = y+r
これで、マウスアップしたときのleft,top,right,bottomをrectとすれば、いいと思いますが、如何でしょうか？
古籏一浩です。
中級編１３を追加しました。
お絵かきソフトを作ろう、その２です。今回はQuickDrawを使って描画を行っています。
中級編１４ではカラーの選択とアンドゥについて説明する予定です。
＃う〜ん、ハイペース（笑）
葛原さん，返事が遅れましてすいません。
>if left > x-r then left = x-r
>if top > y-r then top = y-r
>if right < x+r then right = x+r
>if bottom < y+r then bottom = y+r
ありがとうございます。同様のことを考えてはいたのですが，難しく考えすぎていたようで，このようなすっきりしたソースを見せていただくと，スパゲッティになってしまっている自分のソースを整理しようと思いました。このソースはありがたく利用させてもらいます。
今後ともお気づきの点がありましたらご指導下さい。
古籏さん，返事が遅れてしまいすいません。
>ちゃんと送られてきてます。
>単にレスがつかないだけですね(^^;
あぁ，失礼しました。(恥;)
> １バイトは DIM head%_1;1 ...
詳しい説明をしていただいてありがとうございます。
FB2での変数へのメモリの割り当て方がわかりました。
説明をしていただいたあとで，FB2のマニュアルを読むと今まで意味不明だった部分が一気に理解できました。とっても幸せです。
>_head_1 = 0 ' char
>_head_2 = 1 ' short
>_head_3 = 3 ' long ...
すごくすっきりした記述の方法ですね。
これならオフセットもそれほど苦になりません。ぜひ使わせてもらいます。
私はこのようなアイデアが奇麗に形になっているソースを見るとわくわくしてしまいます。とっても気に入りました。
すいませんが，昨日からunsignedの付く項目をどのように読み出すのか考えているのですが，実験はことごとく失敗しております。すいませんが，教えてもらえないでしょうか。現在読み込もうとしているCの構造体は，unsigned char unsigned int unsigned long の項目があるのです。（ちょっとプログラムで工夫必要）とはどのような工夫なのでしょうか。
ホームページを見ました。
お絵描きソフトの連載をしてもらって，とっても嬉しいです。早速自分のソースと比較しているのですが，ぜんぜん違います。ちょっとショックでした。
客観的に自分のソースを見つめることができて良かったと思います。
古籏さんのソースを参考に，一から書き直そうと決意しました。
ところで，古籏さんのソースですが，リソース部分のダウンロードはできないのでしょうか。
古籏一浩です。
At 17:22 97.7.3 +0000, 仙台7200/90 wrote:
>>_head_1 = 0 ' char
>>_head_2 = 1 ' short
>>_head_3 = 3 ' long ...
> すごくすっきりした記述の方法ですね。
> これならオフセットもそれほど苦になりません。ぜひ使わせてもらいます。
> 私はこのようなアイデアが奇麗に形になっているソースを見るとわくわくしてしまいます。とっても気に入りました。
本当はこういうオフセットで指定するのを避けるためのレコードなんですf(^^b
レコードに詳しい人に解説して・・・と思ったら以前のにありましたね・・・
>らえないでしょうか。現在読み込もうとしているCの構造体は，unsigned char unsigned int unsigned long の項目があるのです。（ちょっとプログラムで工夫必要）とはどのような工夫なのでしょうか。今試しにやった所ではunsigned charは何もしなくてもOKでした。unsigned intが２バイト（１ワード）の場合、32768以上の数値を負数とみなしてしまいます。
a& = PEEK WORD(adrs& + _head1)
if a& < 0 then a& = 2^16 + a&
で符号無し数値が求められます。同様にunsigned longは
a = PEEK LONG(adrs& + head1)
if a < 0 then a& = 2^32 + a&
となります。if文を使わずに論理式でも可能です。
お好きな方をどうぞ(^^)
>お絵描きソフトの連載をしてもらって，とっても嬉しいです。早速自分のソースと比較しているのですが，ぜんぜん違います。ちょっとショックでした。
>客観的に自分のソースを見つめることができて良かったと思います。
>古籏さんのソースを参考に，一から書き直そうと決意しました。
私のはほとんど独学ですから、あんまり参考にならない可能性もありますよ(^^;
私の書き方では中規模のプログラムまでが限度です。
>ところで，古籏さんのソースですが，リソース部分のダウンロードはできないのでしょうか。
７月７日にダウンロードページを公開予定です。
７日には多分ＦＢ関係のはダウンロードできないと思います。
７月２０日頃には講座ごとにアプリとソースを合わせてダウンロードできるようにしたいと考えてます。
yukiです。
古旗さんレス有難うございます。やはりQuickTimeですか。ベンさんからも同じ御指摘をいただきました。ただExifという画像形式の一部にはTiffヘッダーも含まれていて、そちらにサムネイル画像が記録されていたりします。ですから多分ExifファイルからQuickTimeではサムネイルを読み取ることはできないのではないかと感じたりしております。だんだんTOOLSに近づいていってしまっているようなきがする....
またコードリソースの件ですが、富士写真フィルムより返答がありまして、”パスカルの場合だと Pascal Converter(記憶が怪しい??)というものを使うことによってBasicに変換できるが、多分Cのコードリソースは使えないのではないか”というものでした..........
ここで素朴な疑問なのですが、コードリソースって言語によって影響を受けるものなのですか？コードになっているのですからどの言語からでも呼び出せると思っていましたが....
真相はいかがなものでしょうか？どなたかお教えください。
ベン/矢野勉 です。
At 10:14 PM 97.7.1, 仙台7200/90 wrote:
> C言語で次のようなヘッダがあります。
> struct body {
> unsigned short body_1;
> unsigned char body_2;
> short body_3[3];
> };
>
> struct MyRecord {
> char head_1;
> short head_2;
> long head_3;
> Ptr head_4;
>
> BodyRecord body[2];
> };
DIM RECORD body
DIM body_1%
DIM body_2%
DIM body_3_1%
DIM body_3_2%
DIM body_3_3%
DIM END RECORD .body
DIM RECORD MyRecord
DIM MRzHead_1.1
'DIM dammy.1
DIM MRzHead_2%
DIM MRzHead_3&
DIM MRzHead_4&
DIM MRzBody_1.body
DIM MRzBody_2.body
DIM END RECORD .MyRecord
と、論理上はなります。(未実験) １バイト (char型のサイズ) を確保するのに ;1 ではなく .1 を使ってますが、;1 の場合はコンパイラは変数の型を変更しません。つまり、MRzHead_1;1 という宣言をすると、コンパイラは MRzHead_1 は (Preference の設定によりますが) ２バイトの整数型と認識しますが、;1 によって、実際には１バイトの領域しか確保しません。しかしコンパイラは相変わらず２バイトの整数だと思ってます。
.1 とすると、コンパイラは MRzHead_1 を「一バイトの変数」と認識するようです。しかしまあ、レコードから１バイトを取り出すには、いまは PEEK(アドレス) という方法しかありませんので、結局意味がありません。なぜか知りませんが、MyRecord.MRzHead_1 という方法を使うと２バイト取ってきます。(たぶん、MRzHead_1 に %やら & やらがついてないので、Preference に従って２バイトとみなしているんでしょう)
しかし、通常の DIM のときには意味があることなので、; と . の違いは覚えておいたほうが良いでしょう。
あと、先に宣言されたレコードであれば、レコード宣言内部で、レコード自体を使うこともできます。この場合は、body というレコードが先に宣言されているので、MyRecord の宣言内部で、.body という形でこのレコードを使用しています。
次に、MRzHead_2% の前に、dammy.1 というのをコメントアウトしていますが、ここが問題なんですよ。マックは (68K の仕組みに則って) 奇数アドレスへのアクセスを制限しています。INTEGER も LONG INTEGER も、２バイトと４バイトと、どちらも偶数なので、通常は奇数アドレスなんか使うことはないのです。しかし .1 をしてしまいますと、その次のアドレスが奇数アドレスから始まることになるんです。だからToolBox のレコード定義なんかをみても、よく dammy という１バイトの変数を意味もなく宣言することで、偶数になるようにしています。要するに、.1 で１バイト宣言した変数が、奇数個ではなく偶数個になる必要があるのです。
いま移植中のＣコードって、Macintoshのソースコードですか？ 純正Ｃのものではないですか？ 奇数アドレスの問題は FB のではなく、Macintoshの問題ですので、いかんともし難い。レコードではなく定数で宣言しても、奇数アドレスへアクセスする以上同じことです。PowerPC にはこの制限はないそうですが、FB は 68K コンパイラですし、もし PPC コンパイラだとしても、Fatバイナリなどで 68K を今も使用しているのを考えると、やはり奇数アドレスへのアクセスはすべきでない。
そもそも、Odd Address エラーがでませんか？ このエラーがでたら、dammy.1 を非コメント化してみてください。
あと、DIM END RECORD のとこで、_MyRecord とすると、MyRecord という名の変数が実際に作られてしまいます。単にレコードを宣言したいだけなら、.MyRecord と、ピリオドを使います。他の言語の仕様にあわせるなら、ピリオドのほうになります。
おまけ。MRz というのを頭に付けてますが、これは、レコードを宣言すると、各フィールド名を持った定数が作られる (というか、レコードを宣言するってことは、定数を宣言するってことなんです、FB では) ので、定数の名前の重複を避けるための技です。レコードのフィールド名は、FB では、他のレコードのフィールド名とも重複できません。MR ってのは MyRecord の頭文字です。Pascal Converter がこの手法を使ってます。
実験してないんで確証はないんですが、論理上はこれでいけるはずです。もしエラーが出るようなら、どういうエラーが出るかも教えてください。