古籏一浩です。
At 23:03 97.3.27 +0900, Tsutomu YANO wrote:
(*1)最近古旗さんと確認したところですと、英語版と日本語版のマニュアルは、なんとページが完全に一致しているようです。こーいうあんまり意味のないことはせんでもいいから...
え〜補足すると昔のMac関係の日本語のマニュアルは英語版と同じページになってました。利点は日本語訳が違っていたときに、すぐに英語マニュアルでチェックできる所です。
しかし例題が "hello, world" である点にひっかけた文章ですので、うかつに日本語への意訳はできませんね。ちょっとくるしい。
Prograph CPXでも似たような苦しい翻訳がありましたが、そういう部分は翻訳しないのが一番読みやすいんじゃないかなあ。
> 「さぁ、これからちょっと新しい土地を耕しましょう」 > どこを耕すの?(笑)
わはははっ これは何ページですか?
マニュアルの最初の方かな。
69ページには「コードを丸裸」と書いてある(笑)
インサイドマックは眠くなるけど、PGのマニュアルは腹が痛くなります(笑)
> 「項目を選んだ際にも表示されるという二足の草鞋を吐いています」 > どういう日本語なんでしょうf(^^b
草鞋を吐いた日にゃあもう(笑)
69ページ
「カメラの前の情にもろい政治家が「その子が、彼女の家族のことについて話すのを聞いて感動しました。彼女の母親は年老いた女性で、大きな靴に逃げ込まざるを得ず...」 この翻訳全然わからないのですが、英語版ではどうなってんでしょ〜
70ページ
「我々はダンプティのサガにさらされてきました。」
これも日本人にはわからん〜
> 「以下のテキストを見る蹴るまでしたにスクロールしてください」 > うぉ〜見て蹴ってやる(笑)
むう、どうしようもないでわ(笑) たぶん一度も校正してないんだろーなー。
一度は校正したでしょう多分。
ここらへんは石橋さんの方が知っているのではないでしょうか?
翻訳した本人に聞いたんだから。
ただ、PGリファレンスにになると日本語が、また正常に一旦戻ります(^^b
> 「ページ?を参照」
> どこを参照すればいいんでしょうf(-.-b
あー、これはですねー、英語版でもそうなんですよ。これはさすがにこまりました。結局「こうなったら全部読んでやるっ」という対処をしたので、おかげで PG には詳しくなりました(笑)
元が悪いわけですね。
それなら、直してくれてもいいのに〜
> 誤字脱字ミスはともかくレイアウトか構成が悪いのか、読んでいてわかりません。
英語版の PG Manual のレイアウトもそんなに見やすい方ではないですが、これとも違っているんだろうか? ページ数が一致しているのを考えると、同じかもしれませんね。僕は英語で全部よんだぞ。
同じかもしれないですね。
同じにするために、もしかして詰め込んだのでしょうか。
噂によると、なんか題と本文のフォントがあんまり違ってなくて見にくい、と聞いたんですが、真実でしょうか? それだとかなりひどい。
見出しフォントは中ゴシック体(GothicBBB-Medium)で本文は細明朝体(RyuminLight)です。中ゴシック体でなく新ゴMediumくらいであれば見やすかったと思います。
でも、そんなに気になりません。
題の翻訳がなんだか、わけわからんというのなら、わかりますが(^^b
あの、それで思いだしたんですが、INPUT$ 文とかを、あとで日本語対応にして配布するとか言っていたのはどうなったんですか? PRINT が日本語対応したら買ってもいいかなあ、とか思ってたんですが。
どうなんでしょう?
ちょっとしたPRINT文の日本語版なら私が作ってもいいですよ、ただの関数だけど(^^b
はじめまして、葛原康雄といいます。
NIFTY-serveの某HomePartyのお知らせで知りました。
最近は、全然使えてなかったのですが、HP-200LXの4M版をかってから、必要性が高まりました。(^^;)
でも、最近、余計に忙しくなってきたので、時間がとれません。
HomePageも何にも意味のない状態が3年続いています。(@-*)\baki
通信関連のツールを作りたいとは思うのですが...
ただ単純なポートアクセスだと簡単に作れると思うのですが...
デバイスマネージャーまで扱おうと思っているので、ちょっと、罵倒してます。(;_;
森川 俊彦です。
At 11:02 PM 97.3.27 +0900, Tsutomu YANO wrote:
ベン/矢野 勉 です。
> ところでプログラム中にHandleeventsをたくさん列記したらどういう動作になるんだろう(^^?
途中省略...
というわけでやめましょーね。
FBのハンドブックにも
「プログラムは、そのサイズに関わらず、イベント・ループを1つだけしか持てません。」
という記述があります。
で疑問なんですが、ベンさんが言っているのは関数に制御が移った後、もう一度Handleeventsを呼び出した場合ですよね。メインでいくつかのループがあってその中でそのつどHandleeventsを呼び出した場合はどうなのでしょうか?とりあえず、動いているようですが...これもなにか問題が起きるのでしょうか?
僕が作っているのは「イベントドリブン」型ではなくて、一度起動されると最後まで一気に突っ走るようなソフト(^_^)をなんですが、メインの中に3箇所ほど大きなループがあります。この3箇所のループの中でそれぞれHandleeventsを呼び出したところ、どのループ中でも正常に動いているように見えます。
ON EVENT FN〜などはメイン全体にその効力を及ぼすと考えられるのでメイン内でHandleeventsを何回呼び出しても(完全に独立していれば)大丈夫なような気がしますが...
まあ、僕のソフトとの作り方じたいマックのプログラミング作法とかけ離れているのでこういうことができるのではないかと思っているのですが...(^_^)
At 11:02 PM 97.3.27 +0900, Tsutomu YANO wrote:
ベン/矢野 勉 です。
ひとりじめしない程度のことであれば、HANDLEEVENTS で十分ですね。Cなんかでは WaitNextEvent() でイベント情報を得て、何の情報なのか分析して、場所に応じて処理を振り分けて、ウインドウ外部が押されたら Deactivete して、もし押したところが非アクティブのウインドウだったら、Activate 処理をして... などと大変なんですが、FB だと HANDLEEVENTS がたいていを処理してくれます。
ON MOUSE FN DoMouse
ON DIALOG FN DoDialog
ON MENU FN DoMenu
どうもありがとうございます。さっそくやってみました。結果はバッチリでした。うまく動きました。途中終了もできるようになりました(^_^)。
以外にあっけなく終わってしまったのでちょっと拍子抜けしてしまいました。所要時間5分ほどでした。
1つ疑問点を書いておきました(1つ前のメッセージに)。
要するにですね、FOR ... NEXT とか WHILE ... WEND とかのループ文を使うと、その間他のアプリに処理が渡らないんです。(もちろんファインダにも) で、普通は長い処理には NULL Event のときに処理すれば、アプリがなにもしていないときには NULL Event が繰り返し発生するので、繰り返し処理が行えるのです。しかし FB には TIMER イベントというのがあるので、
ON TIMER(-1) FN DoLongProcess
てな感じで、60分の1秒ごとに FN DoLongProcess が呼び出されるわけです。
こういうように、OS が送ってくるイベントを待って処理を行う仕組みを「イベント・ドリブン」といいます。まあ「イベント指向」といってしまえると思います。
とりあえず一度 FB の HANDBOOK を最初からじっくり読んで下さいな。
これもなかなか使えそうです。今のソフトを1から作り直そうと考えているのでその時の参考にさせてもらいます(^_^)。
森川 俊彦です。
At 1:54 AM 97.3.28 +0900, KaZuhiro FuRuhata wrote:
>おうかと思ってんですが、このメモリ要求だと、半分ちかく仮想メモリに頼ることになってしまふ。どなたか 68K で NetScape 3.0 使っているひといませんかね?
私は主に68KでNS3を使用しています。
特に8MBなくても動きます。
ただしShockwaveムービーがある場合、メモリ不足で動かないでしょう。
7MBでも別にスワップしません。
僕もLC475でNetscape3.0使っています。ただ、メモリーを36MB積んでいるのでNSには25MB割り当てています。2.0でもぜんぜん問題なかったのですが前回のWindowの大きさを忘れてしまうのが難でした。起動するたびにwindowを大きくするのがいやで(^_^)3.0にしています(ポートレートモニターを使っているのでとくに面倒です)。
でもJava&JavaSpriptは切ったままになっています。使わないのだから起動時に initializeしなくもいいのに...もっと早く起動してほしい...というのが今の不満点です。
石橋です。
一度は校正したでしょう多分。
ここらへんは石橋さんの方が知っているのではないでしょうか?
翻訳した本人に聞いたんだから。
なんせ、元のFBのコードって文字列が直接CODEリソースの中に入っていたりしたんで、その変更交渉だけでかなり時間を食ってしまったということでしたよ。
Stazも日本側からの指摘を受けて、次の版には全面書き直しをするらしい。
とにかくどういうかたちでも日本語化されたことを評価しましょ。
#きっとアンディちゃんはアセンブラで組んでいるんだ(^^)。
古籏一浩です。
At 4:07 97.3.28 +0900, zzz@mail.yamato.or.jp wrote:
ちょっとご無沙汰している間に(仕事でlingo(^_^;)でスクリーンセーバーを作っていたので……)大勢になりましたねぇ。あらためまして伊藤です。皆さんよろしくお願いします。
MMDでスクリーンセーバーですか。
画面をひげそりでそっていく、スクリーンシェーバーとかはどうです?(笑)
古籏一浩です。
とりあえず解説を付けて、手抜き版の(笑)BMP Saverを用意しました。
次はドラッグ&ドロップ、そして、その次はTIFF Saverの予定です。
古籏一浩です。
At 7:45 97.3.28 +0900, Yasuo Kuzuhara wrote:
はじめまして、葛原康雄といいます。
いらっしゃいませ。
通信関連のツールを作りたいとは思うのですが...
ただ単純なポートアクセスだと簡単に作れると思うのですが...
デバイスマネージャーまで扱おうと思っているので、ちょっと、罵倒してます。(;_;
シリアルポートであればOPEN "C",〜とINPUT,PRINTだけでできます。
MZ <-> Macでやりましたが、割と簡単でした。
ちょっと指定ではまってしまった所がありましたが。
古籏一浩です。
At 11:42 97.3.28 +0900, Toshihiko MORIKAWA wrote:
でもJava&JavaSpriptは切ったままになっています。使わないのだから起動時に initializeしなくもいいのに...もっと早く起動してほしい...というのが今の不満点です。
Javaは切っても表示に影響はありませんがJavaScriptを切るとFONTタグ等の働きが変わってしまいます。なんでかは知りませんが。
Netscape 4.0b2も出ましたが、こちらはPPCでしか動作しません。
おまけにかなり不安定です。
ON EVENT FN〜などはメイン全体にその効力を及ぼすと考えられるのでメイン内でHandleeventsを何回呼び出しても(完全に独立していれば)大丈夫なような気がしますが...
あれ? むむっ? なんかこちらも混乱してきました(^^;) たしかにHANDLEEVENTSのたびに ON ???? FN ???? にジャンプするのを考えると、MAINファイル内部なら何回呼んでもいいような気がしますね。むむ、これは気になるので、英語版 FB-ML にポストして確認することにしましょう。返事がありしだい、ここに報告しますので、しばしお待ちを。
At 6:53 PM 97.3.28, KaZuhiro FuRuhata wrote:
古籏一浩です。
...
シリアルポートであればOPEN "C",〜とINPUT,PRINTだけでできます。
MZ <-> Macでやりましたが、割と簡単でした。
ちょっと指定ではまってしまった所がありましたが。
いやぁ、その程度でしたら、良いのですけど、無手順ソフトウェアパケット通信もどきを行おうとしてたりするの(^^;)と、時間がとれなくて、思うように進まない。<('_')>baki\(^_^ )
で、duoとかのことも最初に考えてしまって、先に進まないのが難関なのですが...あまり考えずに、わかるところだけ、先にやってしまえば、良いのかもしれないのですが、どうも私の性格上、考えこんでしまうのと、わき道にそれてしまうのです。
デバイスマネージャーで、デバイスのポート名を取得し、それをポップアップメニューにして、ポートを選んでもらう。というのが、出来てないところです。
これによっては、通常のread,write文が使えないですよね。
まぁ、かんがえずに、通常の printerport , modemportに出力する形で、さっさとつくってしまえばいいのですけどね。
わかっちゃいるけど、ついつい、別の遊びをしてしまう。<('_')>baki\(^_^ )
伊藤とものりです。
次はドラッグ&ドロップ......
期待しています。
僕はゲームよりもファイル処理とかユーティリティでFBを使っています。フォルダーとかディスクのドラドロの認識のさせ方がわからないので、どのプログラムも半人前です。(T.T) ではでは。
- 追伸
- 風邪で寝込んでいます。(ToT)
こんにちは,中野@Kyoto-inet です。
古旗さん(openspc@po.cnet.or.jp) 》69ページには「コードを丸裸」と書いてある(笑)
》インサイドマックは眠くなるけど、PGのマニュアルは腹が痛くなります(笑)
66ページの
「蝋燭の炎でアッチョウチョウという危険が待ちかまえているのです。」
も傑作ですね。原文は
he chances being french fried by a candle flame.
となっているので,訳者の苦労が見えます。
》69ページ 》「カメラの前の情にもろい政治家が「その子が、彼女の家族のことについて話すのを聞いて感動しました。彼女の母親は年老いた女性で、大きな靴に逃げ込まざるを得ず...」
》 この翻訳全然わからないのですが、英語版ではどうなってんでしょ〜
英語版69ページでは,
Caring politician in front of cameras: "I was deeply touched by a story that a child once told to me about her family. Her mother was an aging woman who was forced to take refuge in a large shoe..."
という文が斜体で印刷されています。
翻訳そのものはうまく出来ているのですが,わたしも意味がさっぱり分かりません。斜体になっているので何かの引用かも知れません。
》70ページ
》「我々はダンプティのサガにさらされてきました。」
英語版70ページでは,
We've all been exposed to the Dumpty saga.
You know: Humpty Dumpty sat on a wall. Humpty Dumpty had a great fall....
となっていますから
「我々はダンプティのお話をいつも聞かされてきました。」
と訳すべきですね。その次の文章(マザーグース?)は韻を踏んでいるので訳出が難しい (^_^;
FB,PG の日本語マニュアルは,比較的こなれた訳出をしているのだけれど,誤字や単純ミスが多いので損してますね。
どうも。NIFTYのホームパーティーで知って参加しました。弘樹です。一度、自動的に入会しようと思ったんだけどうまく出来なくて、古籏さんに手動でやってもらいました(^_^;)
メーリングリストって初めて参加したのですが、なんか沢山来ますね。全部目を通して、勉強したいと思ってます。これからも宜しくお願いします。
古籏一浩です。
At 23:44 97.3.28 +0900, Tsutomu YANO wrote:
あれ? むむっ? なんかこちらも混乱してきました(^^;) たしかに HANDLEEVENTS のたびに ON ???? FN ???? にジャンプするのを考えると、MAINファイル内部なら何回呼んでもいいような気がしますね。むむ、これは気になるので、
ON MENU FN〜とかの飛び先でどこが実行されているかをチェックするようにすれば、よさそうだけど。
古籏一浩です。
At 2:16 97.3.29 +0900, zzz@mail.yamato.or.jp wrote:
> 次はドラッグ&ドロップ......
期待しています。
僕はゲームよりもファイル処理とかユーティリティでFBを使っています。フォルダーとかディスクのドラドロの認識のさせ方がわからないので、どのプログラムも半人前です。(T.T)
あんまり期待しては駄目ですf(^^b
ドラッグ&ドロップマネージャーとかは、わからないので標準のドラッグ&ドロップかな。DISKもやってみるつもりです。
追伸 風邪で寝込んでいます。(ToT)
お大事に・・・
(実は花粉症だったとか?)
古籏一浩です。
At 0:19 97.3.29 +0900, Yasuo Kuzuhara wrote:
で、duoとかのことも最初に考えてしまって、先に進まないのが難関なのですが...あまり考えずに、わかるところだけ、先にやってしまえば、良いのかもしれないのですが、どうも私の性格上、考えこんでしまうのと、わき道にそれてしまうのです。
とりあえず作ってからここで質問するってのが良いかもしれないですよ。
市販のアプリケーションならば、最初にいろいろ考えて決めておかないといけないんだけど、自分専用のだったら、とりあえず作って考えるのが楽かなあ。
古籏一浩です。
At 3:10 97.3.29 +0900, NAKANO Takayuki wrote: 「蝋燭の炎でアッチョウチョウという危険が待ちかまえているのです。」も傑作ですね。原文は he chances being french fried by a candle flame.
となっているので,訳者の苦労が見えます。
これも笑えます(笑)
65ページ最後から66ページはゲームのストーリー?なんだけど半分意味不明ですねぇ〜
》 この翻訳全然わからないのですが、英語版ではどうなってんでしょ〜
英語版69ページでは,
Caring politician in front of cameras: "I was deeply touched by a story that a child once told to me about her family. Her mother was an aging woman who was forced to take refuge in a large shoe..."
という文が斜体で印刷されています。
翻訳そのものはうまく出来ているのですが,わたしも意味がさっぱり分かりません。斜体になっているので何かの引用かも知れません。
前後を見るとマザーグースの歌の引用みたいですねぇ。となると日本人にはマザーグースの歌を知らない場合がほとんどですから意味不明になってしまいますf(-.-b
もともと、マザーグースの歌自体が意味不明なんで余計にそうなってしまうのでしょう。PGのマニュアルにはマザーグースがよく似合う(笑)
FB,PG の日本語マニュアルは,比較的こなれた訳出をしているのだけれど,誤字や単純ミスが多いので損してますね。
誤字は山のようになります。
「こうなってます。it.」
とか削除ミスも結構あります・・・
FB購入者が増えれば儲かってマニュアルも刷新してくれるかなあと思うのですが・・・
古籏一浩です。
At 12:57 97.3.29 +0900, Hiroki Kaneko wrote:
メーリングリストって初めて参加したのですが、なんか沢山来ますね。全部目を通して、勉強したいと思ってます。これからも宜しくお願いします。
メーリングリストによってメールの流量は異なります。
メーリングリストのメールは1日3〜4通くらいの方が手頃でいいかもしれません。もっとも、いろいろなメーリングリストに 入っていると、1日に30通とか40通の所とか2ヶ月に1〜2通とかいろいろです(^^)
Future BASIC II-Jのメーリングリストは他に国内にないと思うので適当に宣伝するといいかな〜
あんまり期待しては駄目ですf(^^b ドラッグ&ドロップマネージャーとかは、わからないので標準のドラッグ&ドロップかな。DISKもやってみるつもりです。
Macintosh Drag&Drop なら STAZ Software から FB Tools を買って、PG つかってプログラムを組めば、テキストと画像関連は5分で D&D 対応ですね。
うう、すばらしい。PICT, JPEG, GIF, TIFF がポンポンとウインドウに置けるという..
みなさん、こんにちは。
府中の山下渉です。
FB IIでプログラミングをしていて、必ず必要となるのがリソース編集ソフトですが、ResEdit2.1.3の場合、例えば
DLOGエディタからDITLエディタを起動させようとしてDLOGエディタに表示されている、編集すべきウィンドウをダブルクリック。 ↓ DITLエディタのウィンドウは開けども、中身が表示されずそのまま操作不能。 ↓ 「Command」+「Option」+「esc」でResEditを強制終了。
や
PICTリソースの一覧から個々のPICT絵を大きく表示させるためにダブルクリック。 ↓ ウィンドウは開けども、絵が表示されずそのまま操作不能。 ↓ 「Command」+「Option」+「esc」でResEditを強制終了。
といったことが多々あります。
その後、もう一度ResEdit2.1.3を起ち上げなおしても同じ現象でMacintoshを再起動すると直ったりします。
ResEdit2.1.3を再インストールしてもやはり同じ現象は発生します。
みなさんの環境では、そういった不具合は発生してないでしょうか?
もし、解決策をご存じの方はお教え願えないでしょうか?
私の環境は、です。
- LC575+20MBメモリー
- OS:漢字TALK7.5.1
- ResEdit2.1.3 割り当てメモリ 最小サイズ:520K/使用サイズ:1000K
宜しくお願い致します。
古籏一浩です。
At 1:28 97.3.30 +0900, 矢野 勉 wrote:
> ドラッグ&ドロップマネージャーとかは、わからないので標準のドラッグ&ドロップかな。DISKもやってみるつもりです。
Macintosh Drag&Drop なら STAZ Software から FB Tools を買って、PG つかってプログラムを組めば、テキストと画像関連は5分で D&D 対応ですね。うう、すばらしい。PICT, JPEG, GIF, TIFF がポンポンとウインドウに置けるという..
というのをベンさんのホームページに載せてくださいよ。
そうすれば、PGを使う人も増えるでしょ。
私の所は、結構オールドスタイルですから(^^b
古籏一浩です。
At 17:30 97.3.28 +0000, YOSHIAKI ISHIBASHI wrote:
なんせ、元のFBのコードって文字列が直接CODEリソースの中に入っていたりしたんで、その変更交渉だけでかなり時間を食ってしまったということでしたよ。
オンラインヘルプは、そうなんだけど紙のマニュアルはなんともいただけないですf(-.-b
古籏一浩です。
At 13:15 97.3.30 +0900, WataruYamashita wrote:
その後、もう一度ResEdit2.1.3を起ち上げなおしても同じ現象でMacintoshを再起動すると直ったりします。
ResEdit2.1.3を再インストールしてもやはり同じ現象は発生します。
みなさんの環境では、そういった不具合は発生してないでしょうか?
もし、解決策をご存じの方はお教え願えないでしょうか?
うちでも、全く同様の現象が発生します。
解決方法も全く同じです。
8500/132でKT7.5.3でResEdit2.1ですが・・・
どうも一度FBを起動してリソースを読み込んだり、同時にやろうとするとその後全然駄目になってしまうみたいです・・・
他の方はどうなんでしょう?
こんにちは、府中の山下です。
At 2:01 PM 97.3.30, KaZuhiro FuRuhata wrote:
古籏一浩です。
> … 中略 …
>みなさんの環境では、そういった不具合は発生してないでしょうか?
>もし、解決策をご存じの方はお教え願えないでしょうか?
うちでも、全く同様の現象が発生します。
解決方法も全く同じです。
8500/132でKT7.5.3でResEdit2.1ですが・・・
どうも一度FBを起動してリソースを読み込んだり、同時にやろうとするとその後全然駄目になってしまうみたいです・・・
この現象って、FB IIからリソースを読み込んだりした後に起る特有のものなのでしょうか?
Think CやCodeWarriorでコーディングをしたときには起らない?
(↑Cではコーディングをしたことがなくて、私にはわかりません。)だとすると、ResEdit側の不具合ということではないということに?
作業の途中でResEditが使えなくなるのは、非常に痛い...。
古籏一浩です。
At 18:03 97.3.30 +0900, WataruYamashita wrote:
この現象って、FB IIからリソースを読み込んだりした後に起る特有のものなのでしょうか?
FB1.0.2でも同様の現象が発生します。
FB2特有ではないと思います。
Think CやCodeWarriorでコーディングをしたときには起らない?(↑Cではコーディングをしたことがなくて、私にはわかりません。)だとすると、ResEdit側の不具合ということではないということに?
そんなに不具合があるとは思えないのですが。
他のアプリだとかちあわない限りなんともないし・・・
作業の途中でResEditが使えなくなるのは、非常に痛い...。
うまくいく時もありますから、どうなんでしょうf(-.-b
Future BASIC II-Jのメーリングリストは他に国内にないと思うので適当に宣伝するといいかな〜
モモデラさんにおねがいして、リンクだけじゃなくて、リストへの参加の仕方もホームページにのっけてもらうと一番よいですよね。モモデラさんもなんかページの書き換えをするネタがないのか、忙しいのか、なんか更新が少ないので、こういうネタがあると喜ぶんじゃないかなー、と希望的観測をしてますが。
#ところで、もう総ポスト数 70 を突破したんですね。はやいなあ。
ベン/矢野 勉 です。
DLOGエディタからDITLエディタを起動させようとしてDLOGエディタに表示されている、編集すべきウィンドウをダブルクリック。 ↓ DITLエディタのウィンドウは開けども、中身が表示されずそのまま操作不能。 ↓ 「Command」+「Option」+「esc」でResEditを強制終了。
これ、僕も何度か同じ目にあってます。理由はいまだに不明。メモリ割り当て量の問題とは思えないんだけどなあ。
僕の環境は:です。
- Machine: ColorClassic I
- OS: 漢字Talk 7.1
- Memory: 10MB + 仮想メモリ = 15MB
- ResEdit2.1.3 への割り当てメモリ: 最小300K, 使用サイズ1500K
#うーん、マシンも OS も古い。とある人から「ColorClassic ですか。いいですねえ」とかいわれたが、だったら君の PowerMac と交換してくれっ(笑)
伊藤です。
僕はユードラでMLを見てるンですけど、自分の出したMLだけ通信相手がアドレスで表示されています。(他のMLは名前だけ表示されています)これって他の方は差出人のところには名前しか入力していないからなのですか?それとも自分のMLはそーゆー表示になってしまうのですか?
At 2:01 PM 97.3.30, KaZuhiro FuRuhata wrote:
古籏一浩です。
At 13:15 97.3.30 +0900, WataruYamashita wrote: >その後、もう一度ResEdit2.1.3を起ち上げなおしても同じ現象でMacintoshを再起動すると直ったりします。 >ResEdit2.1.3を再インストールしてもやはり同じ現象は発生します。
他の方はどうなんでしょう?
風邪で終末丸潰れの伊藤です。僕はforkerを仕込んでいた頃そーゆー現象がありましたが、今はありませんねぇ……何なんでしょうね。
古籏一浩です。
At 21:06 97.3.30 +0900, Tsutomu YANO wrote:
モモデラさんにおねがいして、リンクだけじゃなくて、リストへの参加の仕方もホームページにのっけてもらうと一番よいですよね。モモデラさんもなんかページの書き換えをするネタがないのか、忙しいのか、なんか更新が少ないので、こういうネタがあると喜ぶんじゃないかなー、と希望的観測をしてますが。
忙しいのではなくてネタがないだけだと思います。
私のページへのリンクを頼んだら、すぐにやってくれましたので。
登録方法とか、いろいろ作ってモモデラさんの所からメーリングリスト紹介のページに飛ぶようにすればいいかな。
古籏一浩です。
At 1:42 97.3.31 +0900, zzz@mail.yamato.or.jp wrote:
伊藤です。僕はユードラでMLを見てるンですけど、自分の出したMLだけ通信相手がアドレスで表示されています。(他のMLは名前だけ表示されています)これって他の方は差出人のところには名前しか入力していないからなのですか?それとも自分のMLはそーゆー表示になってしまうのですか?
私の所は、アドレスで表示されたり名前で表示されたりしてますが・・・
これは詳しい人に聞いた方がいいかなあ。
よくわからんですf(^^b
ResEditの件、私のところだと、MacOS7.6なのですが、起きました。が、MacsBugに落ちて、_Get?CICNだったかなにかが表示されていました。
Finderのヒープが少なくなって、落ちるときと同じです。
PhotoShopでPICTリソースを別のファイルに書き出した後、ResEditで目的のファイルにコピー&ペーストしたあと、そのPICTリソースを開こうとした時に、落ちました。カラーアイコンを表示しようとしたとき見たいなのですが良く状況がつかみきれていません。(;_;)
At 7:21 PM 97.3.30, KaZuhiro FuRuhata wrote:
古籏一浩です。
At 1:42 97.3.31 +0900, zzz@mail.yamato.or.jp wrote:
伊藤です。僕はユードラでMLを見てるンですけど、自分の出したMLだけ通信相手がアドレスで表示されています。(他のMLは名前だけ表示されています)これって他の方は差出人のところには名前しか入力していないからなのですか?それとも自分のMLはそーゆー表示になってしまうのですか?
私の所は、アドレスで表示されたり名前で表示されたりしてますが・・・
これは詳しい人に聞いた方がいいかなあ。
よくわからんですf(^^b
EUDORAは、
From: openspc@po.cnet.or.jp (KaZuhiro FuRuhata)
From: zzz@mail.yamato.or.jp
というように、自分の名前の設定をしているかどうか、で変わってきます。
EUDORAの設定の中に、本名があると思うのですが、そこに設定をしていると、メールをかくときに、差出人の自分のメールアドレスの後に、()付けで、本名が添付されているはずです。上記、古籏さんのように...
森川 俊彦です。
At 11:44 PM 97.3.28 +0900, Tsutomu YANO wrote:
> ON EVENT FN〜などはメイン全体にその効力を及ぼすと考えられるのでメイン内でHandleeventsを何回呼び出しても(完全に独立していれば)大丈夫なような気がしますが...
あれ? むむっ? なんかこちらも混乱してきました(^^;) たしかにHANDLEEVENTS のたびに ON ???? FN ???? にジャンプするのを考えると、MAINファイル内部なら何回呼んでもいいような気がしますね。むむ、これは気になるので、英語版 FB-ML にポストして確認することにしましょう。返事がありしだい、ここに報告しますので、しばしお待ちを。
結果がわかったらお願いします(^_^)。
森川 俊彦です。
At 6:53 PM 97.3.28 +0900, KaZuhiro FuRuhata wrote:
古籏一浩です。
At 11:42 97.3.28 +0900, Toshihiko MORIKAWA wrote:
> でもJava&JavaSprictは切ったままになっています。使わないのだから起動時に initializeしなくもいいのに...もっと早く起動してほしい...というのが今の不満点です。
Javaは切っても表示に影響はありませんがJavaScriptを切るとFONTタグ等の働きが変わってしまいます。なんでかは知りませんが。
JavaScriptをきるとそうなるのですか...知らなかったです。JavaScriptだけは入れておいたほうがいいですね。
古籏一浩です。
At 9:31 97.3.31 +0900, Toshihiko MORIKAWA wrote:
JavaScriptをきるとそうなるのですか...知らなかったです。JavaScriptだけは入れておいたほうがいいですね。
でも2.0だと、バスエラー等で落ちる事もあります。
document.clear();
で自分自身を消してしまい暴走しちゃいます(笑)
3.0の方は結構安定しています。
JavaScriptに関してはWin95が一番不安定です。
EUDORAは、
> From: openspc@po.cnet.or.jp (KaZuhiro FuRuhata)
> From: zzz@mail.yamato.or.jp
というように、自分の名前の設定をしているかどうか、で変わってきます。
EUDORAの設定の中に、本名があると思うのですが、そこに設定をしていると、メールをかくときに、差出人の自分のメールアドレスの後に、()付けで、本名が添付されているはずです。上記、古籏さんのように...
なるほどなるほど。ではこれでいかがでしょうか?皆さん。
というわけで風邪が治ったと思って会社に行ったら治ってなかった伊藤でした。
古籏一浩です。
At 3:52 97.4.1 +0900, 伊藤とものり wrote:
> 添付されているはずです。上記、古籏さんのように...
なるほどなるほど。ではこれでいかがでしょうか?皆さん。
今度はちゃんと伊藤さんの名前がでてます(^^)
どーも伊藤です。
ついにモモデラーのHPが更新になったと思ったら社名変更……まあ変わって良かったかも(^o^)
At 5:22 AM 97.4.2 +0900, 伊藤とものり wrote:
どーも伊藤です。ついにモモデラーのHPが更新になったと思ったら社名変更……まあ変わって良かったかも(^o^)
さっそく見てみました。たしかに社名変更になっていました。個人的な好みをいえば旧名のほうがよかったけど...(^_^)
え、例の「ON ??? FN ??? がある MAIN ファイル上で、HANDLEEVENTS をループごとに別の場所に複数書いた場合、なにか問題が生じるか」という問題ですが、このたび英語版 FutureBASIC Mailing list での議論がだいたい終息しましたので、結論を報告します。
「再帰的に呼び出さない限りは問題は生じない」
これが結論のようです。
具体的には、僕が以前指摘したように、ON ???? FN ???? でジャンプした先の関数、さらにそこから呼び出される関数内で HANDLEEVENTS を呼び出した場合は、HANDLEEVENTS の処理が終わるまえにもう一度 HANDLEEVENTS を呼び出したことになり、一部のイベントが消去される事態になります。
一方、MAINファイルひとつだけで、あたまからずーっとつっぱしるタイプのプログラムなどで、複数のループ部がある場合、それぞれのループ内で HANDLEEVENTS を呼んでも問題はおきません。通常どおりイベントをとらえて、ON ???? FN ???? で示された関数にジャンプしてくれます。
よく考えれば当然のことで、HANDLEEVENTS 一個のプログラムでも、ループ内に HANDLEEVENTS をおいて、繰り返し呼び出しているわけで、それが2ヵ所に分かれたところでやはり問題は生じませんね。「これは再帰呼び出しではない」という確信がある場合は、別に使用しても機能的問題はありません。
一方で、次のような意見もあります。
The problems with HandleEvents come down more to programming style thantechnical difficulties. Using multiple HandleEvents calls typically meansyour program needs to be re-thought in certain areas. A well-designed,"normal" app will not need more than one HandleEvents call.
「この HANDLEEVENTS の問題は、技術的問題というよりは、プログラミング・スタイルの問題なんだ。複数の HANDLEEVENTS を使うってことは、きみはプログラムの一部を考え直す必要があるってことだ。うまくデザインされた『ふつうの』アプリケーションには HANDLEEVENTS は一つしか必要ないはずさ」
日頃、個人用「バッチ処理プログラム」より「Macintosh アプリケーション」を作ろうとしている僕もこの意見には賛成でして、いくら技術的に問題がないとはいえ、もし「プログラムを作ってフリーウェア (シェアウェア) として配布しよう」と考えているのなら、やはり HANDLEEVENTS はひとつにして、マックらしくプログラムしたほうが、わかりやすいプログラムになります。
一方で、「このプログラムは個人的な処理のためにかいたもので、配布するなど毛頭考えていない」ようなプログラムであれば、技術的には問題はないわけで、バンバン使ってもいいってことです。特に数多くのループをするプログラムをイベント・ドリブンでかくと、意外とたいへんな上に、そういう時に限って急いでいる場合がおおいんで、そんなときは難しいこと考えずに、(再帰呼び出しにだけ注意して) ループの中に一個ずつ HANDLEEVENTS をおけばいいでしょう。
つーわけで以上、結論でした。
古籏一浩です。
At 16:40 97.4.2 +0900, Toshihiko MORIKAWA wrote:
>ついにモモデラーのHPが更新になったと思ったら社名変更……まあ変わって良かったかも(^o^)
さっそく見てみました。たしかに社名変更になっていました。個人的な好みをいえば旧名のほうがよかったけど...(^_^)
4月バカ(笑)かと思ってましたが、違ってたみたい。
MODEですか。昔の方が覚えやすかったんだけどなあ。
これも時代の流れってヤツ?
古籏一浩です。
At 23:30 97.4.2 +0900, Tsutomu YANO wrote:
「この HANDLEEVENTS の問題は、技術的問題というよりは、プログラミング・スタイルの問題なんだ。複数の HANDLEEVENTS を使うってことは、きみはプログラムの一部を考え直す必要があるってことだ。うまくデザインされた『ふつうの』アプリケーションには HANDLEEVENTS は一つしか必要ないはずさ」
大抵の場合はイベントループは1つで足りるでしょう。
ゲームはモノのによって違いますが。
結局WAITNEXTEVENTとかに時間が消費されると困るのでイベントループはゲームのシステムでは1回も使ってないです(^^;
一方で、「このプログラムは個人的な処理のためにかいたもので、配布するなど毛頭考えていない」ようなプログラムであれば、技術的には問題はないわけで、バンバン使ってもいいってことです。特に数多くのループをするプログラムをイベント・ドリブンでかくと、意外とたいへんな上に、そういう時に限って急いでいる場合がおおいんで、そんなときは難しいこと考えずに、(再帰呼び出しにだけ注意して) ループの中に一個ずつ HANDLEEVENTS をおけばいいでしょう。
FBで求められているのは通常のアプリよりもバッチ的なもののような気がします。ほとんど個人で使うとすれば、別段どうでもいいんですが。
慣れれば、普通のアプリらしいものも簡単に作れますけどね。
At 11:30 PM 97.4.2 +0900, Tsutomu YANO wrote:
「再帰的に呼び出さない限りは問題は生じない」
これが結論のようです。
あっ、やっぱりそうなんですか、よかった...(^_^)。
とりあえず、作ったソフトも問題なく動いていたのですが、そういってもらえると安心します。
一方で、次のような意見もあります。
「この HANDLEEVENTS の問題は、技術的問題というよりは、プログラミング・スタイルの問題なんだ。複数の HANDLEEVENTS を使うってことは、きみはプログラムの一部を考え直す必要があるってことだ。うまくデザインされた『ふつうの』アプリケーションには HANDLEEVENTS は一つしか必要ないはずさ」
日頃、個人用「バッチ処理プログラム」より「Macintosh アプリケーション」を作ろうとしている僕もこの意見には賛成でして、いくら技術的に問題がないとはいえ、もし「プログラムを作ってフリーウェア (シェアウェア) として配布しよう」と考えているのなら、やはり HANDLEEVENTS はひとつにして、マックらしくプログラムしたほうが、わかりやすいプログラムになります。
一方で、「このプログラムは個人的な処理のためにかいたもので、配布するなど毛頭考えていない」ようなプログラムであれば、技術的には問題はないわけで、バンバン使ってもいいってことです。特に数多くのループをするプログラムをイベント・ドリブンでかくと、意外とたいへんな上に、そういう時に限って急いでいる場合がおおいんで、そんなときは難しいこと考えずに、(再帰呼び出しにだけ注意して) ループの中に一個ずつ HANDLEEVENTS をおけばいいでしょう。
たしかにその通りだと思います。できれば、マックらしいソフトにしたいのですが、これがなかなか難しそうなので...。
ループがいくつもあるソフトをイベントドリブンで書くときってどうするのでしょう?ループが短かければ多少レスポンスが悪くなるけど、そのままでもいいと思うのですが(^_^)。長いと(だいたい4、5分)止まるまで画面と睨めっこしなければいけない...
FOR...NEXTをやめてループの最後(最初)でIFによる条件判断にすればいいのかな?(^_^)それともON TIME FNで一定時間ごとに中止キーが押されたかどうかをチェックするのか...
なんかスマートな方法で、目から鱗が落ちるような解決法があるのでしょうか?
スタートアップマニュアルの中のボールキャッチを、丸写しにしたのですが、各、セクションの位置は分かりました。
しかし、関数の位置が、判らず、コンパイル出来ないのです。
なぜでしょうか?おしえてください、以下が私の張り付けた、各セクションの順序です。
なにか、間違いが、あるのでしょうか?
ここが、原因のようです。ここの、FN BuildWnd という、関数が、未定義になってしまうのです。
- 1.ヘッダ
- 2.定数
- 3.グローヴル変数
- 4.関数 (各関数の順序)
- 4.1(FN initialize)
- 4.2(FN BuildWnd)
マニュアルの丸写しなのですが.......?順番違いしか、おもいつきましぇん(;_;)
- 4.3(FN NewGame)
- 4.4(FN UpdateWnd)
- 4.5(FN DoDialog)
- 4.6(FN DiMenu)
- 4.7(FN DoTimer)
- 4.8(FN NewFootball)
- 4.9(FN ChekCatch)
- 4.10(FN MoveBall)
- 4.11(FN MoveMan)
- 5.メインプログラム
ループがいくつもあるソフトをイベントドリブンで書くときってどうするのでしょう?ループが短かければ多少レスポンスが悪くなるけど、そのままでもいいと思うのですが(^_^)。長いと(だいたい4、5分)止まるまで画面と睨めっこしなければいけない...
これはいわゆる「プログレス・バー」を表示するような長い処理ではとくに問題になります。10周くらいのループだと、おそらく1秒程度しか処理を奪わないと思われるので、こういうのは FOR...NEXT, WHILE....WEND などで十分。長い処理の場合はいくらかやり方があります。一応「イベント・ドリブン」の場合、という指定がありますのが、HANDLEEVENTS が複数ある場合は、このやり方はたとえばボタンがおされたらとにかく終了、など、バッチ処理では便利です。
- ループに条件式をかき、真のときは EXIT でループを脱出するか、すぐさまプログラムを終了する。
FOR i = 1 TO 100 処理 HANDLEEVENTS IF FN BUTTON THEN EXIT NEXT iとかです。(この場合、マウスボタンがおされるとループから脱出します。)
次のやり方は、HANDLEEVENTS が一つの標準的マックアプリの、つまり純「イベント・ドリブン」なやりかた。「フラグ」と呼ばれるスイッチを使います。
ここに gStartFlag というグローバル変数があるとします。さらに、ON TIMER(-1) FN DoTimer として、60分の1秒ごとに FN DoTimer がよばれるとします。ループ構文は一切しようする必要はありません。処理の目的はファイルから1行読みこむことだとします。
ON TIMER(-1) FN DoTimer CLEAR LOCAL FN DoTimer DIM theString$ LONG IF gStartFlag <> _false '"処理を一回実行 theString$ = LINE INPUT #1 END IF END FN DO HANDLEEVENTS UNTIL gEndProgram <> _falseこのサンプル自体には何の意味もないのであしからず(^^;)
FN DoTimer は、どこかで処理時間が奪われていない限り、必ず60分の1秒に1回呼び出されます。繰り返し繰り返し呼び出されます。つまり TIMER イベント自体がすでにループになっているので、ループ構文をつかう必要がないわけです。
そのかわり、何がなんでも呼び出されるので、処理をしたくない時には行わないようにしなくてはいけません。その「スイッチ」が gStartFlag です。これが 0 (_false) 以外の値になると、処理が始まり、以降60分の1秒ごとに処理が進みます。処理の終了を確認したら、gStartFlag を _false にセットします。すると処理は行われなくなるわけです。
このやり方の場合、TIMER イベントという、イベントの一つを使っています。
HANDLEEVETS は他にイベントがある場合は先にそちらを処理するようになっているので、アップデートやら BREAK (Command + . ) やらを阻害せずに、うまくイベントを割り振ってくれます。他のイベントがない場合で、指定時間が経過しているときのみ、TIMER イベントに処理が割り振られます。
とまあ、こんなとこです。本来なら ON EVENT FN ???? で分岐して、Macintosh の Null Event をつかまえるのが普通のやり方ですが、別に TIMER でも問題ありません。ただ、どのくらいの時間で TIMER イベントを起こすかについては、ちょっと考える必要はあるでしょう。60分の1秒に一回だと、場合によっては多すぎるでしょう。
イベント・ドリブンではループはややこしいんです(^^;) やっぱ HANDBOOK を読まないとね。
え、FB では Pascal と同じく、使用する関数は、使用するよりも先に定義されている必要があります。(というより、C言語でもいっしょなんだけど、C にはHeader があるので気にならないだけ)
この場合、FN Initialize 内で FN BuildWnd とか FN NewGame を呼び出しているので、この2つは FN Initialize よりも上にある必要があるわけです。
自分でプログラムを書く時には、イベント・ハンドラ(ON ??? FN ???) で飛ぶさきの関数によって区分をつくり(つまり FN DoMenu を中心にメニュー関係の関数をかためる、とか)、「下から積み上げる」ようにして関数を書いていくと、混乱しません。
さらに、FB では "@MENU HANDLER" などと、ダブルクォーテーションで囲まれたもの_だけ_の行は「ラベル」とみなされ、プロジェクト・ウインドウに表示されるので、これを使えば、各イベントごとに関数を固めておくのも楽になります。
実はこのサンプル、自分でうちこまないでも、ディスクに入ってますよ。うちは英語版なんでフォルダ名が不明ですが、英語版では :Getting Started:Sample Game フォルダにあります。
それにしても、このサンプル、今日はじめて読んだんですが、たしかに順番が不明ですね。おまけに全部の関数がマニュアルに書かれているわけでもないようなんで、順番どおりにならべても動かないですね(^^;) だって FN UpdateField なんてマニュアルにはのってないけど、FN DoTimer内で呼び出してますし。
つーわけで、内容が理解できたのであれば、素直にディスク内のファイルで実行しましょう(^^;)
うーむ、サンプルを実際に打ち込むのは一番いい練習法なんだけどなあ。これではそれができんでわ。
古籏一浩です。
At 2:33 97.4.4 +0900, Tsutomu YANO wrote:
うーむ、サンプルを実際に打ち込むのは一番いい練習法なんだけどなあ。これではそれができんでわ。
でも、そうやって失敗しながら覚えていくのでは?
どーも伊藤です。
このやり方はたとえばボタンがおされたらとにかく終了、など、バッチ処理では便利です。FOR i = 1 TO 100 処理 HANDLEEVENTS IF FN BUTTON THEN EXIT NEXT iEXITでループを抜け出せるんですね、知りませんでした。他のBASICだとEXITとかBREAKとかで抜け出せるけど、なんでFBにはそれが無いんだろう……と困っていました。で、大きなlong if文で間に合わせてました。
ところでFBって書類を開いていないとヘルプで検索できないようですけど……僕のだけかな。
At 5:19 AM 97.4.4 +0900, 伊藤とものり wrote:
どーも伊藤です。
> このやり方はたとえばボタンがおされたらとにかく終了、など、バッチ処理では便利です。
> FOR i = 1 TO 100
> 処理
> HANDLEEVENTS
> IF FN BUTTON THEN EXIT
> NEXT i
>
EXITでループを抜け出せるんですね、知りませんでした。他のBASICだとEXITとかBREAKとかで抜け出せるけど、なんでFBにはそれが無いんだろう……と困っていました。で、大きなlong if文で間に合わせてました。
リファレンスを見るとたしかにありますね。「EXIT FN」文で紹介されていますね。私も始めて知りました。
「FOR...NEXT」の説明には一言もでてきませんから...ないと思っていました。FBIIのONLINE HELPにはないですね...(英語版)。
ちなみに「WAIT」文(?)をご存じの方いますか?WAITっていれると予約語みたいに大太字になるのですがリファレンスにもHELPにもないようなんですが...「WAVE」というのはリファレンスにはなくて、HELPには説明があります(使ったことありませんが)。
ところでFBって書類を開いていないとヘルプで検索できないようですけど……僕のだけかな。
私のところではできますよ。英語版のVersion2.3です。ただ、拡張キーボードの「help」キーの動作が違います。書類を開いていれば「help」キーでHELPがでますが、開いていないとポーンとなるだけで何もおきません。その時もアップルメニューから選べば、問題なく使えます(^_^)。もちろん検索も。
At 2:34 AM 97.4.4 +0900, Tsutomu YANO wrote:
このやり方はたとえばボタンがおされたらとにかく終了、など、バッチ処理では便利です。
FOR i = 1 TO 100とかです。(この場合、マウスボタンがおされるとループから脱出します。)
処理
HANDLEEVENTS
IF FN BUTTON THEN EXIT
NEXT i
ハッハッハ、じつはよく使っています。これはホント便利ですね。何にも考える必要がないし...(^_^)
とまあ、こんなとこです。本来なら ON EVENT FN ???? で分岐して、Macintosh の Null Event をつかまえるのが普通のやり方ですが、別に TIMER でも問題ありません。ただ、どのくらいの時間で TIMER イベントを起こすかについては、ちょっと考える必要はあるでしょう。60分の1秒に一回だと、場合によっては多すぎるでしょう。
イベント・ドリブンではループはややこしいんです(^^;) やっぱ HANDBOOK を読まないとね。
なるほど...ハンドブックを読んでみると、たしかに、そのように書いてありますね。う〜ん、私の作ったソフトでこれを実現するには、かなり書き換えないとこうはできないです(^_^)。
HABDLEEVENTSはいろいろやってみるとおもしろそうな使い方があるかもしれませんね。
ところで、余談ですが...
つい先日、頼んであって資料が届きました。何の資料かというと職場にある画像診断機器のバックアップ用5インチMOのフォーマットについてものです。この5インチMOをMACで読み込むソフトと作るために頼んだですが...(2台のうち1台はすでに作製済)。なんと送ってきたのはこの診断機器がMOに書き込むソフトのソースリスト(千ページくらいある)でした。メーカーの人がいうのには「どういうフォーマット書き込んでいるかを明記した資料はありません。とりあえず、読み書きするためのソフトのソースをおくるのでそれを解析して、フォーマットを調べてください...」。
「おいおい、あんたの会社で作ったじゃないのか?!」といいたくなりますが、これが現実なのでしょうがないです。ちなみにこの機械のコンピュータはDECのPDP-11、ソースはFORTRAN77で書いてありました。
というわけでちょっと仕事をしなければならなくなりました(^_^)。
HANDLEEVENTSはちょっとお預けです。せっかく、おもしろそうなところなのに...とりあえず、HANDLEEVENTSやGUIを無視してでも一応、形のあるものを作らないといけないので(^_^)。その後でPG化しようと思います。
はじめてメールさせていただきますyukiと申します。このメーリングリストは古旗さんから紹介していただきまして加入させていただきました。
古旗さんには1度、HPを参考にさせていただき大変お世話になりました。FutureBASICは1.03から使用しておりますが、何分理解が遅いため四苦八苦しております。
ちなみに初めてということで、私の使用環境を記入させていただきます。
HardWare:Mac IIvi/10MB,Hard 110MB
SoftWare:FutureBASIC II2.1.3
です。一応仕事で使用しているのですが、今後個人的なプログラムでも試して見たいと思っております。
プログラム感覚があまりよろしくないのですが、これからご指導よろしくお願いいたします。
さっそくですが、皆さんに初歩的なことでお聞きしたいことがあります。
1.変数の割り振りで
DIM XXX.8
DIM XXX;8
という方法でメモリを割り当てられると思うのですが、これらの実際的な違いが解りません。マニュアル(英語版...)には";"は強制的にメモリを指定バイト数割り当てると書いてある(と思う)のですが、どなたかお教えください。
2.最近話題にあがっているプログラム作法の件ですが、やはり私もまだ理解できていないのです。たとえばMENU,DIALOG,MOUSEのイベントをHANDLEEVENTSで制御する場合に
といった流れの作業があり、メニューにより操作内容が異なって得いる場合にはやはり各々のイベント先にメニューによってSELECT文で分岐させるしかないのでしょうか。この方法だとプログラムが処理によってあちこちにとんでしまい、仕上げ段階にくると何が何だか解らなくなっていることが多々あります。もっと目から鱗が飛び出る方法がありましたらお教えください。
- 1.
- MENU(MENU)選択
- 2.
- WINDOWリサイズ(DIALOG)
- 3.
- MOUSE操作(MOUSE) ---->画像処理の領域指定など
- 4.
- BUTTON操作(DIALOG)
3.画像処理関連でよくでてくるキーワードに
grafPort,wndPort,grafPtr,pixMapH,bitMap,...
というものが多用されていますが、これらの関係がよく理解できていません。
今はごまかしながらなんとか使用しているため、頻繁にシステムエラーにお世話になっております。どなたか素人でも解りやすいように御説明していただけないでしょうか。
4....以上です......(まだ数えきれないほど疑問があったような気がする...)
初回から複数の質問で申し訳ありませんが、よろしくお願いいたします。
石橋です。
PictureFieldをスクロールさせたいのですが、PGではどのあたりから攻略していけばいいのでしょうか? ちなみにウィンドウ全体ではなく、ウィンドウの一部分にその領域を割り当てたいのです。
どうぞよろしくお願いします。
#めまいが止まらなかったので、これから今期初出勤します。
#今日も注射2発....。