注意

この色の文字は「引用」を表しています。また、連絡メール等は削除してあります。

古籏一浩です。

At 10:10 97.4.4 +0900, Toshihiko MORIKAWA wrote:
ハッハッハ、じつはよく使っています。これはホント便利ですね。何にも考える必要がないし...(^_^)
　私はその親戚でEXIT FNをたくさん使う人間です(^^;
　なんだかんだ言っても楽です。

の人がいうのには「どういうフォーマット書き込んでいるかを明記した資料はありません。とりあえず、読み書きするためのソフトのソースをおくるのでそれを解析して、フォーマットを調べてください...」。
　「おいおい、あんたの会社で作ったじゃないのか？！」といいたくなりますが、これが現実なのでしょうがないです。ちなみにこの機械のコンピュータはDECのPDP-11、ソースはFORTRAN77で書いてありました。
　仕様書は出さないのかもしれないですよ。
　プログラムはなくなっても、フォーマットを明記した資料がなくなるとは思えないのですが。
　なくなっていたとしたら、嫌気がさしたプログラマが資料ごと焼き捨てた（笑）とか、考えられます（？）

　もしかして、たまたま動いているなんて怖いことはないですよねぇ・・・

Tsutomu YANO 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にはないですね...（英語版）。
　その後試したんですが「"EXIT"は云々...」というエラーが出ます。他のメールを見て考えると、EXIT FNの事でしょうか。それなら僕も使ってはいましたが、それってlocal FNから抜けさせる命令ですよね。ループの中で使うとループから抜け出すだけでlocal FN内にとどまるんですか？

　ちなみに「WAIT」文(?)をご存じの方いますか？WAITっていれると予約語みたいに大太字になるのですがリファレンスにもHELPにもないようなんですが...「WAVE」というのはリファレンスにはなくて、HELPには説明があります（使ったことありませんが）。
　最近「WAVE」を使ってちょっと企んでいるんですが(成功すれば仕事がはかどるんです)、HELPだけではイマイチわかんないです。パラメーターを変えても音が変わらないし……モモデ、いやMODEに聞いてもHELPの解説そのまんまだし……

古籏一浩です。
たくさん、質問があるので割と知っている画像の部分を説明します。

At 10:46 97.4.4 +0000, akiyuki wrote:
3.画像処理関連でよくでてくるキーワードに
grafPort,wndPort,grafPtr,pixMapH,bitMap,...
というものが多用されていますが、これらの関係がよく理解できていません。
今はごまかしながらなんとか使用しているため、頻繁にシステムエラーにお世話になっております。どなたか素人でも解りやすいように御説明していただけないでしょうか。
　とりあえず分類して説明します。

grafPort（グラフポート）
　画像を描いたり文字を表示したりする場所(pixMapH,bitMap)や大きさなどが格納されている情報の塊です。

wndPort（ウィンドウポート）
　こちらはウィンドウの情報（タイトル文字や大きさ、種類など）が格納されている情報の塊です。

grafPtr（グラフポートポインタ）
　グラフポートの場所を示すものです。

pixMapH（ピックスマップハンドル）
　カラー画像の実際のデータが格納されている場所を示すハンドルです。

bitMap（ビットマップ）
　白黒画像の実際のデータが格納されている場所を示すポインタでしたっけ？
　ここは、忘れてしまいましたf(-.-b

　その後試したんですが「"EXIT"は云々...」というエラーが出ます。他のメールを見て考えると、EXIT FNの事でしょうか。それなら僕も使ってはいましたが、それってlocal FNから抜けさせる命令ですよね。ループの中で使うとループから抜け出すだけでlocal FN内にとどまるんですか？
　失礼、ちょっと間違いがありました。EXIT だけではループの脱出はできないようですね。ラベルをつけないとだめのようです。

WHILE flag = _false
'"なんか処理"
EXIT "Label1"
WEND
"Label1"
'"つづきの処理

　としないとだめみたいですね。ぼくが試しに使ったサンプルを一応いっしょに挙げておきます。

flag = _false
WINDOW #1,"myWindow",(0,0)-(400,400)
FOR i = 0 TO 20
  PRINT i;"This is Sample"
  LONG IF i > 10
    EXIT "Label1"
  END IF
NEXT i
STOP

"Label1"
PRINT "EXIT!"
STOP

　どうも、ベン/矢野　勉です。

1.変数の割り振りで

　DIM XXX.8
　DIM XXX;8

という方法でメモリを割り当てられると思うのですが、これらの実際的な違いが解りません。

　え、「DIM XXX.8」のほうは、「XXXは８バイト型の変数である」ということをコンパイラに指定し、コンパイラは以後 XXX を (２バイトの整数型ではなく) ８バイトの変数とみなします。「DIM XXX;8」は「XXXの型はそのままに、実際には８バイトを割り当てよ」とコンパイラに告げます。この場合、XXX は整数型(２バイト)とみなされますが、実際には８バイトのメモリ空間を割り当てられています。

　例として、

DIM rect.8;0, top, left, bottom, right

　というのもありです。rect は８バイト型の変数ですが、実際にはメモリ空間を割り当てられていません。つまり実際のメモリ割り当てでは「;」のほうが優先されるのです。ではどうなるかというと、rect という変数は top と同じ番地から始まる８バイトの変数とみなされます。上記の定義をつかって CALL SETRECT すると、

CALL SETRECT(rect, 0,0,10,10)

　このあと、rect.bottom% で 10 が取り出せるのはもちろんですが、top以降８バイトが rect と同じ領域を使っている関係上、じつは

top = 0 left = 0, bottom = 10, right = 10

　と値が入っており、rect.top% などと打ち込む必要はありません。top は常にrect.top% と同じ値をもつことが保証されます。

　つまり「.」は「型定義」で、「;」は「メモリ割り当て」命令で、「;」のほうが優先順位が高いわけです。

一般的に、Rect型とか Point型の変数がほしいときに、手っ取り早く使うために使用します。普通は上記のような、.8 というのはつけず、

DIM theRect;0, top, left, bottom, right
DIM thePoint;0, h, v

　という定義の仕方をします。Rect や Point を必要とする ToolBox には theRect, ThePoint を渡してやればいいですし、値が欲しいときは、top や h から手軽に取り出せるわけです。

　おわかりでしょうか？

メニューにより操作内容が異なって得いる場合にはやはり各々のイベント先にメニューによってSELECT文で分岐させるしかないのでしょうか。この方法だとプログラムが処理によってあちこちにとんでしまい、仕上げ段階にくると何が何だか解らなくなっていることが多々あります。
　これはその通りです。ON MENU FN DoMenu と定義していた場合は、FN DoMenu 内でどのメニューが選ばれたかを調べ、そこから例えば FN NewItem とかに飛ぶわけです。
　こんがらがるのもそのとおりで、これは自分で工夫して、ラベルとかを使って関数を処理ごとにまとめておくしかないでしょう。僕の場合、ウインドウ関連の関数の最初に "@WINDOW RILATED ROUTINES" というラベルをつけ、その下にウインドウ関連の関数をまとめています。もちろん「関数は呼び出すよりも先に定義されていなくてはならない」というルールも守って、「より些末な処理をする関数が上にくる」ようにしています。

　さらに「メニューを選んだらウインドウが開く」てのはよくあることなので、メニュ−関係の関数群はウインドウ関係の関数群よりも下に置く、など工夫しています。これは自分で整理するしかないです。だいたいは

top

「かなり細かい処理」

2

「ウインドウ内部の情報」

3

「ウインドウ関数群」

4

「メニュー関数群」

5

「初期化、終了関数」

6

「イベントループ」

　という枠組みを考えておいて、関数ごとに「どこにいれるべきか」を考えます。必要があれば「マウス処理関数群」というようなグループを新たに作ったりもします。

3.画像処理関連でよくでてくるキーワードに
　と、ちょっと発言が長くなってきたので、いったん切って、別のメールでこれには解答します。

　どうも、ベン/矢野　勉です。

　さて、解答第２弾です。

3.画像処理関連でよくでてくるキーワードに
grafPort,wndPort,grafPtr,pixMapH,bitMap,...
というものが多用されていますが、これらの関係がよく理解できていません。

GrafPort, wndPort, grafPtr

　え、まず Macintosh のあらゆる描画には描画場所が必要です。これが「クラフ・ポート(GrafPort)」です。描画はすべてグラフポートに行われる点、Macintosh の描画の根幹と言えるでしょう。実際にはグラフポートは Inside Macintosh で定義されているレコードの名の一つでして、このレコード型には、描画領域の大きさ、描画された内容、背景色などといった情報が記録されています。

　GrafPtr というのは、この「グラフポート」レコードへのポインタのことです。

　実際には、画面の一部を覆う複数のグラフポートを必要に応じて切り替えて描画します。それが我々が「ウインドウ」と呼んでいるものの正体、といっていいでしょう。

　wndPort というのはそのまま「ウインドウ・ポート」という意味ですが、実際にWindowPort というレコード型があるわけではありません。これは「ウインドウがもっているグラフポートの通称」と思ってもらって結構です。ToolBox の NewWindow や、FB の WINDOW statement を使用したら、Macintosh は WindowRecord の一部として、グラフポートを作成します。ウインドウへの描画はすべてここに行われるのです。

　さて、一般に使われる描画場所はウインドウだけではありません。いわゆる「オフスクリーン・グラフポート(Offscreen GrafPort」と呼ばれる「画面上に存在しない描画領域」があります。オフスクリーンの使用は近年、どんどん増えていき、いまや Macintosh の描画領域といえば、Window か Offscreen のどちらか、という状態になっています。

　これが windowPort という通称の出てきた理由と思われます。オフスクリーンとウインドウを併用する必要上、プログラム上で両者を区別する必要があります。
で、ほとんどのひとがウインドウのグラフポートには、なぜか wndPort という名前を使用するようです(^^;)　 wndPort というのはその程度のものです。

●pixMapH, bitMap
　まず bitMap を知る必要があるでしょう。画面上の描画情報は、ビットマップと呼ばれる形式で保存されます。これは０と１の数字の羅列で、画面上には０が白、１が黒として反映されるわけです。つまりは bitMap は白黒情報を保存するためのものです。実際には BitMap という名のレコードがあり、そこには画像のサイズ、実際のビット情報などが記録されているわけです。

　さて、Color QuickDraw の登場で、カラー情報を記録するためのレコードが必要になりました。カラーでの画面要素のことを「ピクセル(Pixel)」と呼ぶことから PixMap という名のレコードが用意されました。機能的には、カラー情報を保持する以外は BitMap と同じだと思ってください。

　で、変数名の最後に H とか Hdl とか Hndl というのがついている場合、それが「ハンドル」であることを意味しています。ハンドルが何かは分かっていると思いたいのですが、分かってない場合は HANDBOOK とか古旗さんのページを参考にしてください(^^;) まあ、ポインタのちょっとややこしいやつです。

　もうおわかりかと思いますが、pixMapH というのは、単に「PixMap へのハンドル」という意味にほかなりません。こうしか説明できません。ToolBox では bitMap がそのままレコード型として使用することが多いのに比べ、PixMap はハンドルとして要求されることが多いので、こういう変数名がでてくるわけです。

　とまあ、こんなもんですかね。

WHILE flag = _false
'"なんか処理"
EXIT "Label1"
WEND
"Label1"
'"つづきの処理

なるほどなるほど。こりゃ便利ですね。

初歩的な質問です。ご教示下さい。

以下のような処理（ＶＢで書いてみましたが）のFBでの書き方がよくわかりません。
動的配列の宣言とインデックスの内容を保持しながらインデックスを拡張したいのですが....

Option Base 1

Dim StrList() As String  '----動的配列宣言
Dim i As Integer

として例えば、

For i=1 to 10
   ReDim Preserve StrList(i) '----すでにある要素の中身を保持しながら要素
                             '    数を増やす
   StrList(i)="Test" & Str(i)
Next i

ちなみに、本当にしたいことは、エディトフィールドに入力した複数行の文字列を１行づつ取り出して配列に入れるということです。もちろん、行数はときどきで異なります。

マニュアルを読んでも理解できない、お馬鹿な男をお助け下さい。

　ベン/矢野　勉　です。

PictureFieldをスクロールさせたいのですが、PGではどのあたりから攻略していけばいいのでしょうか？

ちなみにウィンドウ全体ではなく、ウィンドウの一部分にその領域を割り当てたいのです。
　...石橋さん、またハードなことを試みはじめましたね(^^;)

　ウインドウ全体のスクロールなら PICT.FLTR があるのですぐなんですが、ウインドウの一部領域に絵を表示してスクロールするようなフィルタはまだ見たことがないので、自前でフィルタを書くしかないかと。

　ひまがあればやるんですが、いまはないんです〜。

　HANDBOOK の p98 なんかを参考に、USER OBJECT フィルタを書いてやれば、のちに他の人も再利用できて便利ですよ。(などといって勧めてみる(笑))

PG Manual の p164 なんかも、USERフィルタを書くには必読ですね。ここにある_oUserInit 以降のアクションを引っかけていけば、わりと簡単に書けそうな気がします。PICT.FLTR, PIC2.FLTR も参考になるでしょう。

　暇ができたらぼくも挑戦するかもしれませんが、練習がてらに挑戦してみることをお勧めします(^^;)

ちなみに、本当にしたいことは、エディトフィールドに入力した複数行の文字列を１行づつ取り出して配列に入れるということです。
もちろん、行数はときどきで異なります。
　Visual BASIC ですか。マイクロソフト系BASIC は昔から(QuickBASIC のころ)動的配列には強かったから便利だよなあ。おまけに文字列型変数は30,000文字も入るし。(というか、BASICの標準仕様ではそうなんですけどね)

　とりあえず FB には INDEX$ という、動的文字列配列をあつかう命令があります。まず

CLEAR bytes% [,indexNum%][,StringLength%]

で、INDEX$ 配列にメモリを割り当て、

INDEX$, INDEX$ I, INDEX$ D

といった statement で配列を操作できます。まー、ToolBox の関係上、文字列型が Pascal と同じ 255 文字に制限されるところが難点かもしれません。エディットフィールドが小さいものなら問題なしですが、テキストエディタなみに入力できたりすると、一行取り出すのは割りとたいへん。(255文字を超えることがあるから)

(FB)Example:References:I に INDEX$ 関連のサンプルも入っているので、参考にしてください。

#ぼくはこの手のは Handle を使って動的リストを自前で作ってしまふ(^^;)
#いずれこのやりかたをINCLファイルとしてまとめようかと思ってます。

　それとも INDEX$ をつかうってことは分かっているが、その使い方がわからない、という質問なんだろうか。

At 2:47 PM 97.4.4 +0900, KaZuhiro FuRuhata wrote:
　プログラムはなくなっても、フォーマットを明記した資料がなくなるとは思えないのですが。
なくなっていたとしたら、嫌気がさしたプログラマが資料ごと焼き捨てた（笑）とか、考えられます（？）
　結局、ソースコードをもとにフォーマットを調べ上げて、なんとか読み出すことはできそうです（ディレクトリーを読み出すソフトはできたので）。
　はっきりいって、メーカーのサポートはまったくあてにしていないので、「ソースでも何でも出してくれれば後はこっちがやるから資料を早く持ってこい！」と考えています(^_^)。

　もしかして、たまたま動いているなんて怖いことはないですよねぇ・・・
　う〜ん、私の書いたプログラムにはこれがあるかもしれない...(^_^)

今日は、yukiです。

古旗さん、ベンさん御指導有難うございました。御陰様で何となく理解できたような気がします。

1.DIM XXX.8とDIM XXX;8の違いについて

なるほど良く解りました。メモリ上では配列の大きさに違いはないのですね。使用する関数によって使い分ける必要があるんでしょうね。

2.プログラムスタイルについて

やはりそうですか....。私はEVENTで処理をするときには、まず

DIM record evt
         DIM Edialog&
         DIM Emouse&
         DIM Emenu&
DIM END RECORD.evt
DIM gMainEvent.evt

という配列を作成して、各EVENTのジャンプ先で必ずこれに状況を書き込むようにして、メインの関数は一箇所で処理しようとDefultのプログラムを書いているのですが（DIALOGのようにevent,idがあるものはgMainEvent.Edialog% =evnt*1000+idにする）、このような使い方に問題はありますでしょうか（例えばこのような使用法をすると実行速度が遅くなる等）。もしぱっと思いつくような問題点がありましたらお教えください。

3.grafPort,wndPort,grafPtr,pixMapH,bitMapについて

これも何となく理解できました。ただ、例題のなかにはによってはwindPortにgrfPortをコピーすることがおおいのですが、するとwindPortとgrfPortは同じ形のレコードなのですじか？
あ、もう一つありました。gWorldです。FN NEWGWORLDで得られたgwPtr&とgrafPtr&は同一なのでしょうか？......初心者には非常に難しいですね。Inside Macintoshを至急入手せねば.....。

古籏一浩です。

At 11:29 97.4.7 +0900, Toshihiko MORIKAWA wrote:
　結局、ソースコードをもとにフォーマットを調べ上げて、なんとか読み出すことはできそうです（ディレクトリーを読み出すソフトはできたので）。
　はっきりいって、メーカーのサポートはまったくあてにしていないので、「ソースでも何でも出してくれれば後はこっちがやるから資料を早く持ってこい！」と考えています(^_^)。
　仕様書よりもソースリストが一番確実という話しもありますが、それにしても、お粗末ですねぇ。企業秘密ならソースリストも出てこないですよね。

>　もしかして、たまたま動いているなんて怖いことはないですよねぇ・・・
　う〜ん、私の書いたプログラムにはこれがあるかもしれない...(^_^)
　私のプログラムでもいくつかあります。
　そういえば初級編の印刷のヤツは確か間違っていて直してない(^^;
　＃＄の間違いもあるし(^^;

古籏一浩です。

At 13:03 97.4.7 +0000, akiyuki wrote:
これも何となく理解できました。ただ、例題のなかにはによってはwindPortにgrfPortをコピーすることがおおいのですが、するとwindPortとgrfPortは同じ形のレコードなのですじか？
　先頭部分が同じになってます。
　だからコピーしても大丈夫です。

あ、もう一つありました。gWorldです。FN NEWGWORLDで得られたgwPtr&とgrafPtr&は同一なのでしょうか？......初心者には非常に難しいですね。Inside Macintoshを至急入手せねば.....。
　確か同じ扱いだったと思います。
　Inside Macは眠くなります（笑）
　インターネット上でオンラインでも見れますよ。英語ですが(^^;

という配列を作成して、各EVENTのジャンプ先で必ずこれに状況を書き込むようにして、メインの関数は一箇所で処理しようとDefultのプログラムを書いているのですが（DIALOGのようにevent,idがあるものはgMainEvent.Edialog% =evnt*1000+idにする）、このような使い方に問題はありますでしょうか（例えばこのような使用法をすると実行速度が遅くなる等）。
　技術的には問題ないんでしょうが、しかし ON DIALOG なんかで分岐したところから、さらに細かく分岐したほうが分かりやすいと思いますけどねえ？　分岐するほど処理が細かくなるのが一目瞭然なわけで。メインのループを一箇所にまとめると、本来のマックのイベントループと変わらなくなるわけで、FB の便利さを削いでしまうような気がします。Ｃのイベントループなんかだと、メインのループだけで数百行を占めかねませんし、そのおかげでコードの見通しは非常に悪い。FB ではせっかくそれが起きないよう、イベント分岐が簡単にできるようになっているわけですが、あえて一箇所にまとめたい理由は、やはり「複数の関数に分かれるとごちゃごちゃしてわかりにくい」からですか？　ぼくはひとつの関数で処理したほうが「読みにくい」と思っているんですが...

　ソースコードがごちゃごちゃするのは、分岐が多いからというより、各関数をどう置くか、の問題ではないでしょうか？　関係関数群がきちんとまとまっていれば、そんなにごちゃごちゃしませんし。人によっては「１画面に表示できないような関数は長すぎる」とまでいいますし、小さな関数に分離すること自体は問題ないとおもうんですけどねえ？

ただ、例題のなかにはによってはwindPortにgrfPortをコピーすることがおおいのですが、するとwindPortとgrfPortは同じ形のレコードなのですじか？
　ですから、windPort とよばれるものは、WindowRecord 内の GrafPort のことですので、やはり GrafPort なんです。WindowRecord の一つの要素として、GrafPort があるんです。論理的にまったく同じものです。おまけに WindowRecord の先頭は GrafPort ですから、WindowRecord をそのまま GrafPort として使っても、とくに問題はおきません。

　ついでに説明しておくと、ソースコード内の windPort とか grfPort ってのは「変数名」に過ぎないんですが、それでこんがらがってませんか？　このソースを書いた人はウインドウの GrafPort に windPort という名の変数を、もうひとつの GrafPort に grfPort という名の変数を使っただけで、変数の名前は変数の中味とは特に関係ありません。(この場合はどちらの変数にも GrafPortレコードが入っているんでしょう)　 プログラマの趣味次第です。べつに grf1 と grf2 でも、極端にいえば、ben と furuhata でもいいわけで(^^;)

あ、もう一つありました。gWorldです。FN NEWGWORLDで得られたgwPtr&とgrafPtr&は同一なのでしょうか？
　GWORLD と GrafPort はプログラム上の定義としては違うものですが、概念的には同じものです。以前も説明したとおり、Macintosh の描画のキャンパスはやはり GrafPort です。GWORLD は、一般に Offscreen GrafPort と呼ばれるもののカラー版でして、その名のとおり、GrafPort の一種です。白黒時代はオフスクリーンにポートを作るのは大変だったんですが、GWORLD の登場で、公式にオフスクリーン・グラフポートの作成がサポートされた、という経緯があり、オフスクリーン以外で GWorld を使うことはありません。

　もちろんプログラム上のあつかいが異なるため、GWorld に関しては専用の関数を使用する必要ことがあります。しかし「ポート」である点は同じなので、ポートからポートへのビットの転送などは、ウインドウからウインドウへのコピーのように、まったく同じに行えます。GWorld は GrafPort の上位互換品だ、といえば分かりやすいでしょうか。

　まー Inside Macintosh はたかいので、本屋でＣ言語系の Macintosh プログラミングの本を買ってみるのがいいかと。僕は Inside Macintosh なんて持ってませんし。いまだと「Macintosh アプリケーション・プログラミング」あたりがおすすめかな。

yukiです。

ちゃごちゃしてわかりにくい」からですか？　ぼくはひとつの関数で処理したほうが「読みにくい」と思っているんですが...
うーん。確かに関数が長くなるのは読みづらいです。構造化プログラミングと言うことが売りのFutureBASICですから、やはり各関数ごとにまとめるのがいいのでしょうかねぇ。
プログラムに慣れるまでは、きちんと計画をたててから始めないときれいなプログラムは書けないのでしょうね。

に、まったく同じに行えます。GWorld は GrafPort の上位互換品だ、といえば分かりやすいでしょうか。
なるほど。なんとなく解っていたのですがこれですっきりいたしました。

　まー Inside Macintosh はたかいので、本屋でＣ言語系の Macintosh プログラミングの本を買ってみるのがいいかと。僕は Inside Macintosh なんて持ってませんし。いまだと「Macintosh アプリケーション・プログラミング」あたりがおすすめかな。
もう少しがんばります。

ベンさんありがとうございました。
あっというまに出来てしまいました。

　それとも INDEX$ をつかうってことは分かっているが、その使い方がわからない、という質問なんだろうか。
最近ＶＢ、ＶＢＡがらみの仕事が多く、頭の中をＶＢがぐるぐる回ってます。
ＦＢのマニュアルを読んでもすんなり頭に入ってくれないです。

#いずれこのやりかたをINCLファイルとしてまとめようかと思ってます。
ＰＧ関係のホームページを計画中とのことでしたので、これもそちらで公開されるんでしょうね。期待してしまいます。

いま作っているのは、ＰＧを使いました。
「マニュアルが悪いから使っていない」みたいな人も多いようですが、何か作って、感じをつかんでしまえば便利この上ないってとこです。わからないところも異常に多いので、ベンさんのホームページ完成を心待ちにしています。

yukiです。

また基本的な質問で申し訳ありませんが、計測器から送られるシリアルデータのログを記録するプログラムを製作しています。そこで問題になっているのが（この間、話題になっていた）可変長のテキストをエディットフィールドに表示する方法です。次々と送られてくるデータを

R( 1):abcdefg.....　　　**最初に読み込んだデータ
R( 2):abcdefg.....　　　**2番目に読み込んだデータ

というようにデータを追加してエディットフィールドに表示させたいのです。
INDEX$で追加していくことはできるのですが、エディットフィールドに追加して表示するやり方が解りません。どなたかお助けください。

また、INDEX$は初めにバイト数を宣言して使用しますが、できればFN NEWHANDLEなどの動的な方法で行う、最後にテキスト形式でファイルに保存する方法を御存じの方はいらっしゃらないでしょうか。

　どうも、ベン/矢野 勉　です。

R( 1):abcdefg.....　　　**最初に読み込んだデータ
R( 2):abcdefg.....　　　**2番目に読み込んだデータ

というようにデータを追加してエディットフィールドに表示させたいのです。INDEX$で追加していくことはできるのですが、エディットフィールドに追加して表示するやり方が解りません。どなたかお助けください。
　要するに、すでに文字の入っているフィールドに、文字列を追加したいわけですね。それならば、PG Manual の p150 に出ている、以下の関数を使用してください。

-----------
'"theField はフィールドの参照番号
'"theTxt$ は追加する文字列

CLEAR LOCAL FN TEappend(theField, theTxt$)
  AUTOCLIP = 0
  TEHndl& = TEHANDLE( theField)
  LONG IF TEHndl&
    txtLgth = {[TEHndl&]+_TELength}
    CALL TESETSELECT(txtLgth, txtLgth, TEHndl&)
    CALL TEINSERT(@theTxt$ + 1, LEN(theTxt$), TEHndl&)
  END IF
END FN
-----------

　参照番号theFieldのテキストフィールドに、theTxt$ を追加します。文字列に改行コードが含まれていない場合、改行されずに、横方向に追加されていくことになるので、

TEKEY$ = CHR$(13)　'"CHR$(13) は改行コード

これを上記の FN TEappend の直後に呼び出すか、追加文字列theTxt$ に改行コードを含まなければいけません。スクロール可能フィールドの場合は、前者の TEKEY$ を使ったほうが、挿入位置にオートスクロールしてくれるので便利です。
ただし、TEKEY$ はアクティブなテキストフィールドにしか機能しません。

>また、INDEX$は初めにバイト数を宣言して使用しますが、できればFN NEWHANDLEなどの動的な方法で行う、最後にテキスト形式でファイルに保存する方法を御存じの方はいらっしゃらないでしょうか。
　ぼくは INDEX$ を実際に使ったことがないので、確認はしてませんが、Reference Manual の INDEX$ を読む限りでは、すでに存在する INDEX$ 配列に「CLEAR bytes%, indexNum%」とすれば、配列のサイズを動的に変更できるようにみえますけど？(だから「動的文字列配列」と呼んだわけです)

　ファイルへの保存方法についても、Reference Manual の INDEX$ のページにちゃんと書いていますよ。(p184) 読み込みのときは、まず INDEX$ 配列をつくってそこに読み込むようにしなくちゃいけませんが、なぜかそこまでは書いてませんね。
　なんか _indxAddr の前１２バイトがヘッダになっていて、情報が隠されているみたいですね。

----------

　一応、自前で確保したメモリ空間を配列として使用し、必要に応じて拡張していく方法もあります。XREF@ fn という関数がそれです。 FN NEWHANDLE _clear でハンドルを作成し、(仮に) theArray& に格納したとしますと、

XREF@ theArray$(100) '"配列の変数名はハンドルの変数名と'"同じでなければいけない。

　で、作成したメモリ空間を theArray$(100) という配列を介して操作できます。
同等のものとして XREF というのもありますが、こちらは Pointer で同じことをするもの。ハンドルでないと、動的な拡張ができないのでペケです。

　ハンドルならば、ToolBox の FN SETHANDLESIZE(Array&, newSize&) でサイズを大きくしたり小さくしたりできますから。ただし、オーバーフローを起こさないように、自前でハンドルのサイズをきっちり把握しておいてください。

-------------

ToolBox に慣れているなら後者でもわりと使えます。が、ちょっとでもメモリを節約しようと思うなら、INDEX$配列のほうが強いです。文字列を扱う限りでは、INDEX$配列のほうがメモリ消費量を小さくできる点を除くと、どちらも機能的には同じです。どちらも動的サイズ変更できますし、オーバーフロー (準備したメモリ以上に文字列を格納したときにおきる) に注意しなくてはいけないのも同じです。

　あ、あと、INDEX$ は参照番号で配列を参照できるけど、XREF@ ではハンドルをグローバル変数にいれるなどして、自前で保持しておかないと、あとで破棄できませんね。

古籏一浩です。

今日、Developer's Journalを買ってきたら、冨山氏がFB IIの記事を書いていました。もっとも連載なので、しばらくDJを買うとよいでしょう。

＃FB Bookは、インプレスで没をくらいました。
＃次は技評に持っていこうと思います。が、技評の他の本の執筆中なのでそれが終わるまでは駄目です(^^b

　どうも、ベン/矢野 勉　です。

今日、Developer's Journalを買ってきたら、冨山氏がFB IIの記事を書いていました。もっとも連載なので、しばらくDJを買うとよいでしょう。
　さっそく立ちよみ(^^;)してきました。思ったよりページが多くて、期待してます。Ｃのソースコードを載せて、いかに FB がシンプルで強力かをアピールしているあたりはすごいものが。だって FB とは直接関係のないＣ言語コードだけで１ページ割いているし。最初みたとき、「なんでこんなとこにＣのコードがっ。乱丁か？」とか思ってしまった。

＃FB Bookは、インプレスで没をくらいました。
＃次は技評に持っていこうと思います。が、技評の他の本の執筆中なのでそれが終わるまでは駄目です(^^b
　インプレスって BASIC とは関係なさそうだからなあ。技術評論社はちょっとは期待できそうな気がします。技評の本って、JAVA関係ですか？(笑)

　以下余談。

　最近リストが寂しくなりましたね。ちょっとややこしい話をしすぎたかなー、とか心配してるんですが(^^;)

　まだインターネット・サービスプロバイダと契約してないんですが、今月はするつもり。近畿圏ではわりと有名な 3WEB にしようかと思ってます。で、HTML ツールを集めようと、Nifty から HomeMaker という Home page 作成プログラムを入手したのですが、「漢字talk 7.5以上、QuickTime 2.5が必要」とか言われまして、漢字talk 7.1 に QuickTime 2.0 のわたくしめは、やはりはねられました(^^;)　
まー、どのみち派手なページより、読み込みの早いページにしようと思っているので、いまから HTML 勉強して、手書きでやっちゃおうとおもってます(^^;;)　ざっと立ちよみした限りでは、TeX よりは簡単そうだし。

　実はうちには 386 の EPSON Note がありまして、DOS用の TURBO C++ 1.0 もあるのですが、「さすがにもう本屋で本は入手できんだろうなあ」とか思っていたら、ありました。技術評論社(ともうひとつどっか)のが(笑)
技評おそるべし。(たぶん在庫品なんだろうけど)

yukiです。

ベンさん、いつもいつも有難うござます。EDIT FIELDへの追加の方法は分かりました。
やってみるとするすると追加されていきます。これはPrintに比べ便利ですね。
御陰様でEDIT FIELDの使い方がやっと理解できてきました。

で、また皆さんに質問なんですけれども（いつもすみません）、RS232Cで以下の設定でモデムからデータを読み込むプログラムを作成したのですが、データの取りこぼしが発生します。どこかに問題があるのでしょうか。

まず設定ですが、
OPEN "C",_modemPort,9600,_noParity,_oneStopBit,4096
HANDSHAKE _modemPort,_cts '---->ハード的にフロー制御している
としています。（これはモデム側で設定されていることを確認しました。）
で、問題の部分ですが、

    DO
      DO
        READ #_modemPort,rcvd$;0
        readText$=readText$+rcvd$
      UNTIL rcvd$= endCha$ OR FN BUTTON
      '----
'(a)
      TEKEY$ = readText$
      SETSELECT WINDOW(_selEnd),WINDOW(_selEnd)
      SCROLL BUTTON _gReadWriteField,WINDOW(_selEnd)
      DELAY 10
'(b)
    UNTIL LOF(_modemPort)=0 OR LEN(INKEY$)

としていました。ところが、いざreadText$を出力させると文字化け（文字落ち）が発生してしまいました。そこで(a)-(b)を

'(a)
      print readText$
      DELAY 10
'(b)

に変更すると文字落ちは発生しませんでした。何度かトライして見た結果、シリアルでデータを取り込み中にEDIT FIELD等を操作するとエラーなしに文字落ちが発生し、確実な通信ができなくなることが原因ではないかと思いました。

で、皆さんにお聞きしたいことはTOOLBOXなどにアクセスするとシリアル等のハードウエアに影響が出るのでしょうか。

yukiです。

すみません....先程お願いした通信関連の質問は解決しました。
....バッファーのグローバル定数は宣言していましたが、OPEN "C"に書かれていなっかった.....

すみませ−−−−ん（2日間悩み続けていたのに.....）

　ご無沙汰の伊藤です。
　先日futureBasicToolsの案内が来ました。皆さんのトコにも来てると思いますが、アレって買いですか？個人的にはJPEGが簡単に扱えたり、ドラドロとかプレビュー付きFILESとよだれモノなんですが……
　日本語版ってことはそれ以前に英語版が存在していますよね？英語版をお持ちの方、ご意見聞かせてください。なにせ思った以上に高額なので(^_^;;;;;;)

At 2:14 AM 97.4.14 +0900, Tsutomu YANO wrote:
　どうも、ベン/矢野 勉　です。

>今日、Developer's Journalを買ってきたら、冨山氏がFB IIの記事を書いていました。もっとも連載なので、しばらくDJを買うとよいでしょう。

　さっそく立ちよみ(^^;)してきました。思ったよりページが多くて、期待してます。Ｃのソースコードを載せて、いかに FB がシンプルで強力かをアピールしているあたりはすごいものが。だって FB とは直接関係のないＣ言語コードだけで１ページ割いているし。最初みたとき、「なんでこんなとこにＣのコードがっ。乱丁か？」とか思ってしまった。
さっそく買ってきて読んでみました。なかなかおもしろく読ませてもらいました。
「なるほど、なるほど」と思う部分もあって1800円はちょっと高いですが、それなりの価値はありました(^_^)。
　今後も期待したいです。

　最近リストが寂しくなりましたね。ちょっとややこしい話をしすぎたかなー、とか心配してるんですが(^^;)
　いや、そんなことないです。日本語の取り説では何をいっているかよくわからない部分などベンさんの説明はとてもありがたいです。
　私の書き込み少ないのは、今、プログラムを作っていないので新たな問題がでてこないだけです(^_^)。
　そろそろ、ＰＧを使ってソフトを全面的に書き直そうと思っているので、その勉強中です。画面のデザインをどうするかとか、どんな仕様にするか考えています。
　作り出したらまた、疑問点がたくさんでてくるかもしれないので、そのときはこのＭＬをあてにしています(^_^)。

古籏一浩です。

次号のMac FanからFuture BASIC IIのプログラミング講座（かな）が始まるようです(^^)/

今度はMac Fanも買わないといけないみたいですね〜

　PGのハンドブックを片手に簡単なアプリを作ってみました。アプリというかテスト用のものなのですが...。しかし、これはすごい！！僕が作ったのはPGで２枚のWindowとボタンを１つだけのシンプルなものですが、FBIIで書いたコードはたったの１０行くらいで完全なアプリになってしまいました。
　他のタスクにも切り替わるし(^_^)、Windowの書き換えや移動も完全に機能しています。これはすごい！（繰り返してしまった）

　これはなかなかのものですね。ハンドブックの例をもとにちょっといじってみただけですが簡単にできてしまった。

　役に立たない書き込みですが(^_^)、うれしくて、つい...

　PGのハンドブックを片手に簡単なアプリを作ってみました。アプリというかテスト用のものなのですが...。しかし、これはすごい！！僕が作ったのはPGで２枚のWindowとボタンを１つだけのシンプルなものですが、FBIIで書いたコードはたったの１０行くらいで完全なアプリになってしまいました。
　他のタスクにも切り替わるし(^_^)、Windowの書き換えや移動も完全に機能しています。これはすごい！（繰り返してしまった）
　むむ、ついに第一歩をふみだしましたね。PG は内部で思っている以上のことをしています。必須アップルイベントへの対応はもちろんですが、じつは、マック特有の「マルチ・ディスプレイ」にもしっかり対応しています。この２枚ウインドウのサンプルも、マルチ・ディスプレイ完全対応なわけです。わっはっは。(なぜいばる)

　奥深いところは融通がきかないところもあるのですが(ふう)、しかし Filter をみんなでつくって共有すれば、格段に生産効率があがります。いま PICTBOX.FLTR を鋭意制作中ですので、うまく完成したらどっかで公開したいと思います。

　しかし最初に PG をつかった時に衝撃を感じるタイプの人間は、ぼくのようになってしまう素質があります(笑)

　ベン/矢野 勉　です。

　日本語版ってことはそれ以前に英語版が存在していますよね？英語版をお持ちの方、ご意見聞かせてください。なにせ思った以上に高額なので(^_^;;;;;;)
　英語版が存在しました。これを見たときはもう、衝撃うけまくりでした(^^)　だって、ドラッグ＆ドロップにあっというまに対応できて、TIFF, GIF, PICT がウインドウにドロップしまくりですよ。ううむ、よさすぎる。STAZ ポロシャツもなんとなくほしい気がする(笑)

　値段なんですが、英語のカタログによると、フルセット版で $249.50 となってますね。３万円くらいかな？　日本語版はいくらなんですか？　僕は買おう買おうと思っていて、まだ買ってないんですが...

　ベン/矢野 勉 です。

次号のMac FanからFuture BASIC IIのプログラミング講座（かな）が始まるようです(^^)/

今度はMac Fanも買わないといけないみたいですね〜
　おお、いったい何がおきているんだっ　たぶん、最近いろんな雑誌がプログラム系の連載を始めてみたところ、意外に人気があるので、突如 BASIC の(雑誌社側の)需要が生まれてきたのではないかと見ているんですが。

　あ、なんか FB本計画が遠のいているみたいなんで、画面キャプチャはちょっとおいといて、以前石橋さんから要望のあった、スクロールする PICT ボックス.FLTR を作成する計画を先にさせていただきます。ちょっとやってみたところ、けっこうな壁が立ちはだかっていました。これはなかなかやりがいのあるパズルです。

　ベン/矢野 勉　です。最近あった話なぞを。

　ColorClassic を Booster 33 で加速する予定でしたが、いざお金をひっつかんで日本橋に行ってみると、実は LC2 用のものだと発覚。LC2 と ColorClassic ってボードはほとんど同じなんだから、動いてもよさそうなのに、Booster ColorClassic というのが別にあるそうな。それは入荷せんのかと店員に聞いたら、「ん〜、ColorClassic 自体が人気商品で入ってこないですからね〜」とか。世のものども、このカラクラやるからおまえの PowerMac くれって。

　仕方がないので、前から買おう買おうと思っていた(こればっかり) CD-ROM ドライブ(２倍速) を物色。6000円くらいで入手できるので、その場で購入。さらに別の店にいって、NetScape 3.01 を買おうと思ったら、なんと漢字talk 7.5以上でないと動かんとか。店員曰く「いや〜、いまのは全部 7.5 以上ですよ」　そらそーだわな。Booster のために持ってきたお金がまだまだ残っていた上に、CD-ROM ドライブを買ったので(そう、これがなかったからいままでアップグレードできなかったのだ)、いっそのこと漢字talk 7.5.3 を買っていこうと、ふと見ると...

　ああっ、MacOS 7.6 が発売になっているっ(笑)　はり紙がしてあって「68040以上でないと動きません」　むう。店員に 7.5 はないかと聞くと、「ちょっと前まであったんですけどー」とか。もしかして僕のようなやつがたくさん来たのか(笑)

　...結局、ほかのみせで 7.5.3 を見つけて、一日がかりでインストールしました。Disk FirstAid に「修復不能のエラー」を発見されてしまったので、ZIP に退避して初期化してからインストールしました(^^;)

　おかげでメニュー表示がはやくなった(キャッシュがきくようになったんですね)のですが、これがまた、仮想記憶を ON にするとキャッシュがきかなくなるという... 不幸ですね、ColorClassic ユーザーって。CD-ROMドライブのおかげで雑誌の付録CD-ROM が読めるようになった(これがうれしい)ので、7.5.5 にしたら仮想記憶もちょっとはましになるかなー、とか思ってますが...

　まー、NetScape 3.01 は入手したし、HomeMaker は動くようになったし、いよいよページをつくるだけ。

　あ、そうそう。帰りに駅の前で「安いっ、スリーウェブ (入ろうとおもっていたプロバイダ)」とかいっていたのでチラシをもらうと、なんかそれで申し込むと、初期加入料が半額らしい。もう運命がそっち方向に流れているとしか思えない(笑)

　いやー、オーディオＣＤ機能で音楽ききながらメールかくのもいいもんですね　時代にやっとすこしだけ追い付いた気分。

伊藤です

　英語版が存在しました。これを見たときはもう、衝撃うけまくりでした(^^)　だって、ドラッグ＆ドロップにあっというまに対応できて、TIFF, GIF, PICT がウインドウにドロップしまくりですよ。
なるほどなるほど、買いのようですね。といいつつもう買う気でいました。(^o^)

　値段なんですが、英語のカタログによると、フルセット版で $249.50 となってますね。３万円くらいかな？　日本語版はいくらなんですか？　僕は買おう買おうと思っていて、まだ買ってないんですが...
29800円です。通販だけだそうです。

　むむ、ついに第一歩をふみだしましたね。PG は内部で思っている以上のことをしています。必須アップルイベントへの対応はもちろんですが、じつは、マック特有の「マルチ・ディスプレイ」にもしっかり対応しています。この２枚ウインドウのサンプルも、マルチ・ディスプレイ完全対応なわけです。わっはっは。(なぜいばる)
やってみると以外に簡単だったというのが感想です。まあ、たいしたことはしていないので当然かもしれませんが...(^_^)もっとも、PGを使わずにFBIIだけで同じようなものを全て書こうと思ったら相当の時間がかかることは間違いないです（これは断言できます）。

　しかし最初に PG をつかった時に衝撃を感じるタイプの人間は、ぼくのようになってしまう素質があります(笑)
　えっ、まずいな...(^_^)

At 4:18 AM 97.4.17 +0900, Tsutomu YANO wrote:
　おお、いったい何がおきているんだっ　たぶん、最近いろんな雑誌がプログラム系の連載を始めてみたところ、意外に人気があるので、突如 BASIC の(雑誌社側の)需要が生まれてきたのではないかと見ているんですが。
　もともと「できることなら、いつかは自分の手でアプリを」という人が一定数いると思います。ただ、「Ｃは何が書いてあるかわからない」、「ＧＵＩは難しい」という考えが広まっているので、やりたいけどなかなか一歩踏み出せないんだと思います。
　ところがFBIIがでて、それも完全日本語版、いままで「Ｃはちょっと」と思っていた人たちが「こりゃおもしろそうだ」となったのではないでしょうか？(^_^)

　この流れがもっと大きくなればFBIIもひなた(?)にでられるのではないでしょうか？(^_^)　がんばれFBII！

At 5:12 AM 97.4.17 +0900, 伊藤とものり wrote: > 　値段なんですが、英語のカタログによると、フルセット版で $249.50 となってますね。３万円くらいかな？　日本語版はいくらなんですか？　僕は買おう買おうと思っていて、まだ買ってないんですが...

29800円です。通販だけだそうです。
ではでは。
　うちにも来ました。とっても魅力的なんだけど五月の連休前のこの時期、３万円は...(^_^)

古籏一浩です。

At 4:19 97.4.17 +0900, 矢野　勉 wrote:
ら、「ん〜、ColorClassic 自体が人気商品で入ってこないですからね〜」とか。世のものども、このカラクラやるからおまえの PowerMac くれって。
　それならウリにだしたら（笑）？

　まー、NetScape 3.01 は入手したし、HomeMaker は動くようになったし、いよいよページをつくるだけ。
　これでＰＧのページができそうですね(^o^)/

　いやー、オーディオＣＤ機能で音楽ききながらメールかくのもいいもんですね　時代にやっとすこしだけ追い付いた気分。
　ハングアップしても音楽だけが流れ続ける・・・いいですねぇ（笑）

＃FB TOOLsは、まあGIF,TIFFの実装を考えれば安いかな〜と。
＃ただTIFFは、どこまで実装しているか気になる所だけど・・・
＃Ver 6.0仕様の半分〜２／３程度であれば十分買いかな。

古籏一浩です。

At 14:33 97.4.16 +0900, Toshihiko MORIKAWA wrote:
　他のタスクにも切り替わるし(^_^)、Windowの書き換えや移動も完全に機能しています。これはすごい！（繰り返してしまった）
　ああＰＧ派が増える（笑）。
　雛形作れば、あんまり変わらないような気もするけどメニューとか配置は楽ですよねぇ。

　ＰＧだけでなくTOOLSも同梱してくれたらありがたいんだけどなあ。

At 7:50 PM 97.4.17 +0900, KaZuhiro FuRuhata wrote:
>　他のタスクにも切り替わるし(^_^)、Windowの書き換えや移動も完全に機能しています。これはすごい！（繰り返してしまった）
　ああＰＧ派が増える（笑）。
　雛形作れば、あんまり変わらないような気もするけどメニューとか配置は楽ですよねぇ。

自分で使うだけのものならGUIでなくてもいいのですが、公開しようとなるとそれなりのGUIがないと、かっこわるいから...(^_^)そういう意味で、すべての人にPGが必要かどうかはわかりませんが、全コードをFBIIで書いて作るのとは違う衝撃があると思います。

　ＰＧだけでなくTOOLSも同梱してくれたらありがたいんだけどなあ。
　これ賛成！(^_^)

古籏一浩です。

At 10:59 97.4.18 +0900, Toshihiko MORIKAWA wrote:
自分で使うだけのものならGUIでなくてもいいのですが、公開しようとなるとそれなりのGUIがないと、かっこわるいから...(^_^)そういう意味で、すべての人にPGが必要かどうかはわかりませんが、全コードをFBIIで書いて作るのとは違う衝撃があると思います。
　手軽に作る分にはＰＧの方がいいでしょう。
　早くＰＧのページを誰か作らないかなあ（笑）
　誰かって誰(^^;
　私のページは日曜日の夜に更新予定です。
　予定と違うけど（笑）


>　ＰＧだけでなくTOOLSも同梱してくれたらありがたいんだけどなあ。
　これ賛成！(^_^)
　TOOLSでGIF89aアニメーションに対応しているかどうか知りたいんですけどね。対応しているならば絶対に買いますけど。
　そうすればＦＢでPICT選択して自動的にGIFアニメが生成できる(^^)/

　ＰＧだけでなくTOOLSも同梱してくれたらありがたいんだけどなあ。
＞＞これ賛成！(^_^)
こんにちは。
TOOLSってそのうちFBがバージョンアップすれば標準機能に盛り込まれちゃいそうな気がするんですけど・・
どうなんでしょう・・・
3万近く払って買うのは、・・・でもほしいな・・・（笑）
ついでにQD3DとかQT2.5などに対応のTOOLSも販売してほしいですね。

次期FBはコアの部分が書き終わったらFB自体で周辺を作っていくとのことですから、他の開発環境に負けないくらいのペースで製品がいろいろ出てくるといいですね。

古籏一浩です。

At 22:58 97.4.18 +0900, HIS wrote:
TOOLSってそのうちFBがバージョンアップすれば標準機能に盛り込まれちゃいそうな気がするんですけど・・
　ああ、確かにありがちですねぇ。
　逆にある程度の知識があればTOOLSくらいは、割と簡単にできそうです。
　画像関係ならなんとかですが私はAppleEventとか駄目だからなあ・・・

ついでにQD3DとかQT2.5などに対応のTOOLSも販売してほしいですね。
　QD-3DとQT2.5に対応すると凄くいいですよね。
　手軽にスプライトトラックとかテキストトラックとか。
　PICTを指定して変形させながらQTに記憶とか。
　でもBASICならば
GSAVE "Filename"
　でPICT保存して欲しいですよねぇ。

中野＠Kyoto-inetです。

# 引用箇所は順不同です。

ベンさん(QZG00075@niftyserve.or.jp) 》　ああっ、MacOS 7.6 が発売になっているっ(笑)　はり紙がしてあって「68040以上でないと動きません」　むう。店員に 7.5 はないかと聞くと、「ちょっと前まであったんですけどー」とか。もしかして僕のようなやつがたくさん来たのか(笑)
　試しに LC3 に MacOS 7.6-J をインストールしてみましたが，問題なくインストールできましたし，安定して動作しています。
　7.6 の英語版は 68030 もサポートしているんですから，日本語版だけ動作しないわけがないです。日本語版で 68030 をサポート外にしたのは，単に「重い」からとちゃうかなあ。

》世のものども、このカラクラやるからおまえの PowerMac くれって。
　そんなこと言うたらカラクラがかわいそうやん。コンパクト型 Macは大事にしたらなあかんって。

　わたしは EXPO で中古の MacSE を入手したんですが，なかなかかわいい奴です。KT6.0.7 での動作チェックが出来るところが貴重ですし。

　でもBASICならば
GSAVE "Filename"
　でPICT保存して欲しいですよねぇ。
フフフフ、ですね。伊藤でした。

At 10:58 PM 97.4.18 +0900, HIS wrote:
こんにちは。
TOOLSってそのうちFBがバージョンアップすれば標準機能に盛り込まれちゃいそうな気がするんですけど・・
どうなんでしょう・・・
3万近く払って買うのは、・・・でもほしいな・・・（笑）
ついでにQD3DとかQT2.5などに対応のTOOLSも販売してほしいですね。
でしょうね。問題はそのバージョンアップがいつかことですよね(^_^)。
あと、その料金ですね。

At 2:32 AM 97.4.19 +0900, NAKANO Takayuki wrote:
》世のものども、このカラクラやるからおまえの PowerMac くれって。

　そんなこと言うたらカラクラがかわいそうやん。コンパクト型 Macは大事にしたらなあかんって。
　まあ、そうなんですけど、でもカラクラだけではちょっと辛いんじゃないかな...。私も最近までカラクラIIがメインでしたが、「もう少しスピードが」と思ったことは何度もありました。
　サブマシンで使うのにはコンパクトだし重宝しますが...

　ホント、交換してくれるのなら私もしてほしい...(^_^)

中野＠Kyoto-inet です。

森川さん(toshi@nsknet.or.jp)
》　そんなこと言うたらカラクラがかわいそうやん。コンパクト型 Macは大事にしたらなあかんって。
》
》　まあ、そうなんですけど、でもカラクラだけではちょっと辛いんじゃないかな...。私も最近までカラクラIIがメインでしたが、「もう少しスピードが」と思ったことは何度もありました。
》　サブマシンで使うのにはコンパクトだし重宝しますが...
　確かに，カラクラがメインマシンというのはつらいでしょうねえ。
中古のPowerMac だと10万程度ですし，LC475 だったら13インチモニタ込みで 5万ちょっとで買えると思います。いかがなものでしょうか。

古籏一浩です。

At 11:23 97.4.19 +0900, Toshihiko MORIKAWA wrote:
　サブマシンで使うのにはコンパクトだし重宝しますが...

　ホント、交換してくれるのなら私もしてほしい...(^_^)
　うちにもSE/30があります(^-^)/
　カラクラとPC88VAと交換とか？（笑）
　VAの方が貴重品だから駄目か〜

＃どこかにMZ-3500ありませんか？

At 9:54 PM 97.4.19 +0900, KaZuhiro FuRuhata wrote:
＃どこかにMZ-3500ありませんか？
さすがにMZ-3500はないでしょう...(^_^)だれか使っている人っているのかな？しかし、懐かしい名前を聞きました。たしか3500ってZ80A*2のマシンでしたっけ？
　私も一時期X1CやMZ-2000を使っていました（っといっても、ゲームばかりでしたが）。ちなみに初めて触ったのは兄が買ってきたパピコン（PC-6001）です(^_^)。

古籏一浩です。

At 9:53 97.4.21 +0900, Toshihiko MORIKAWA wrote:
さすがにMZ-3500はないでしょう...(^_^)だれか使っている人っているのかな？しかし、懐かしい名前を聞きました。たしか3500ってZ80A*2のマシンでしたっけ？
　いえいえ２週間前にかなり完全な状態（ソフト付き）で入手した輩がおるんですよ。おまけにMZ-800まで手に入れたという・・・
　別に対抗しているわけじゃないんですけどねぇ。
　私は日本で一番多くMZ-2500を持っていると思うけど（笑）

　なんかＦＢネタから離れていく(^^;

山野です。

だいぶまえに「まだＦＢ買ってないんです」という自己紹介を書いたきりご無沙汰しておりました。いまだに買っておりませんが、５月末にはまとまったお金が入る予定なのでなんとか……。

古籏さんwrote:
　いえいえ２週間前にかなり完全な状態（ソフト付き）で入手した輩がおるんですよ。おまけにMZ-800まで手に入れたという・・・
　別に対抗しているわけじゃないんですけどねぇ。
　私は日本で一番多くMZ-2500を持っていると思うけど（笑）
MZ-800って、MZ-700のヨーロッパ向けバージョンでしたっけ。きっと700とは入ってる文字なんかが違うんでしょうね。

古籏一浩です。

At 0:51 97.4.22 +0900, YAMANO wrote:
だいぶまえに「まだＦＢ買ってないんです」という自己紹介を書いたきりご無沙汰しておりました。いまだに買っておりませんが、５月末にはまとまったお金が入る予定なのでなんとか……。
　も〜ど（旧名：デモデラーズブランド）の社長さんに懇願すれば消費税分くらいまけて・・・くれないかナ(^^?

>　私は日本で一番多くMZ-2500を持っていると思うけど（笑）

MZ-800って、MZ-700のヨーロッパ向けバージョンでしたっけ。きっと700とは入ってる文字なんかが違うんでしょうね。
　ハード構成が全く異なります。
　MZ-2500 / 2 + MZ-700 といった感じです。
　スムーズスクロールもできるらしいんですが・・・

At 1:14 PM 97.4.21 +0900, KaZuhiro FuRuhata wrote:
　いえいえ２週間前にかなり完全な状態（ソフト付き）で入手した輩がおるんですよ。おまけにMZ-800まで手に入れたという・・・
　別に対抗しているわけじゃないんですけどねぇ。
　私は日本で一番多くMZ-2500を持っていると思うけど（笑）

　なんかＦＢネタから離れていく(^^;
　へえ〜どこからでてくるんでしょうか？
まあ、あるところにはあるのでしょうね...(^_^)

古籏一浩です。

At 4:51 97.4.19 +0900, 伊藤とものり wrote:
> 　でもBASICならば
> GSAVE "Filename"
> 　でPICT保存して欲しいですよねぇ。

フフフフ、ですね。伊藤でした。
　どうせなら複雑なことは出来なくてもいいからPerlのような文字列処理と画像処理だけに特化したようなBASICをFBで作るとかってのは、どう？

　ベン/矢野 勉　です。

　試しに LC3 に MacOS 7.6-J をインストールしてみましたが，問題なくインストールできましたし，安定して動作しています。
　7.6 の英語版は 68030 もサポートしているんですから，日本語版だけ動作しないわけがないです。日本語版で 68030 をサポート外にしたのは，単に「重い」からとちゃうかなあ。
　そーですよね、たしか、純正32bit対応でないマシン(MODE32を使っていたやつ)が対象外だったはずですが...　しかし、やっぱり重いんでしょうか。7.5.5 よりも 7.6 のほうが重くなった、というのであれば、僕としては「選択外」になりますが...　 そのへんはどうなんでしょうか？

　実は 7.1 から 7.5 へのアップグレードで、実感速度ではものすごく速くなっているんです。スクロールもはやくなったし、ことえりが辞書を読み込むようになったためか、入力がキー入力速度においついてくれる(笑)　仮想メモリが速くなったのだけが原因とは思えない... メニューもキャッシュされるようになって、アップルメニューが一瞬で表示されるのに感激しているのですが、もし 7.6 にすることで、これが失われるのであれば、このマシンには 7.5.5 と最後まで運命をともにしてもらおうと考えています。

#まあ、システムの占有メモリが 4MB から 5MB になりましたが(^^;)
#たぶんことえりの辞書だろな。機能拡張もえらく増えてるし。

　そんなこと言うたらカラクラがかわいそうやん。コンパクト型 Macは大事にしたらなあかんって。
　基本的には、新機種をいつか購入することがあっても、売る気はありません(^^)
　しかし、ColorClassic が出たときの各方面の批判のことばを思い出すと、いまの中古市場での人気ぶりは、なんか意外な気が。「冷蔵庫みたい」「豆腐かっ」「ポチ」とか言われまくってましたからね。ほかのマックが一様にダサくなったので、もはや ColorClassic のデザインでも許されてしまうのでしょうか(笑)　頭でっかちのパフォーマなんて最悪だったからな(^^;)

#ColorClassic が出たころは、まだ店に Classic II がありまして、Classic専用のパソコンテーブルにおかれた姿の美しいこと...
# ColorClassic にするか Classic II にするか、本気でなやんだもんな...

　さらに話はとびますが、MacPower誌でいつか載っていた、キーボードが小さくなる、幻の原色系(赤と青) PowerBook のプロトタイプ、あれ、どっかが出そうとデザイナーの川崎和男さんにコンタクトをとっているという噂が... あれが出るんだったら、大金はたいてもいいなあ。知らない人は、今でている MacPower誌に、キーボードだけがでています...なんかニュートンの備品として、キーボードだけ一人歩きしたみたい。かっこよかったもんなあ...

　ああ、FB の話題がひとつもないっ(^^;)

　ベン/矢野勉　です。

中古のPowerMac だと10万程度ですし，LC475 だったら13インチモニタ込みで 5万ちょっとで買えると思います。いかがなものでしょうか。
　これはっ　接続プロバイダとの契約をやめれば買えるかもっとかいったら一部からブーイングかな(笑)

　しかしほんとに魅力的な... LC475 って 040 だったな。夢のような速度なんだろうな...

伊藤です。

At 9:55 PM 97.4.19, KaZuhiro FuRuhata wrote: 古籏一浩です。

At 4:51 97.4.19 +0900, 伊藤とものり wrote:
>> 　でもBASICならば
>> GSAVE "Filename"
>> 　でPICT保存して欲しいですよねぇ。
>
>フフフフ、ですね。伊藤でした。
　どうせなら複雑なことは出来なくてもいいからPerlのような文字列処理と画像処理だけに特化したようなBASICをFBで作るとかってのは、どう？
BASICでBASICをつくっちゃう！！(爆)でも面白そ。

FBとは、関係ないですが、私のPerforma5220はなんと、4牧目のアナログボードがはいっています。
アナログボードを3回交換したともいいますが、、、
何か、得した気分、、、、ぶははははっ、、、、(;_;)

古籏一浩です。

At 0:13 97.4.20 +0900, Tsutomu YANO wrote:
　しかしほんとに魅力的な... LC475 って 040 だったな。夢のような速度なんだろうな...
　475は結構速いですよ。
　30と40の差は相当大きいですね。
　powerPCの603と604くらい違います。
　603e/240と604/120と速度は同じか、まだ604の方が速いくらいです。
　酷使するようなプログラムだと特に差が出ます。

古籏一浩です。

At 0:40 97.4.20 +0900, 伊藤とものり wrote:
BASICでBASICをつくっちゃう！！(爆)でも面白そ。
　（爆）ではなくて昔は結構そういうパターン多かったんですよね。
　最近はＣコンパイラでＣコンパイラを作るといったくらいかなあ。

　でも、ちょっと作ってみるといいかも。
　BASICでなくても、特化したものだと楽でしょう。
　ＦＢみたいになんでもやろうとすると何だけど・・・

At 1:03 AM 97.4.20 +0900, KaZuhiro FuRuhata wrote:
>　しかしほんとに魅力的な... LC475 って 040 だったな。夢のような速度なんだろうな...
　475は結構速いですよ。
　30と40の差は相当大きいですね。
　powerPCの603と604くらい違います。
　603e/240と604/120と速度は同じか、まだ604の方が速いくらいです。
　酷使するようなプログラムだと特に差が出ます。
　たしかにそうです。私はColorClassicII(68030-33)からLC475改（68040-33）に変えましたが体感は倍くらい違う感じです。Photoshopみたいなものや3Dものをやる気はありませんが、それ以外ではぜんぜん問題ないです。

　ColorClassicならLC575のマザーボードを入れれば68040-33マシンになりますよ。それに画面の解像度を640*480に改造することもできるし...。新しいのを買ったほうがコストパフォーマンスは良いと思いますが、ColorClassicに愛着があればそういう方法もあります(^_^)。

須澤裕典です。

At 0:40 97.4.20 +0900, 伊藤とものり wrote:
BASICでBASICをつくっちゃう！！(爆)でも面白そ。
At 20 Apr 1997 02:54、古籏一浩　wrote:
（爆）ではなくて昔は結構そういうパターン多かったんですよね。
最近はＣコンパイラでＣコンパイラを作るといったくらいかなあ。
僕も(爆）してしまいました。
でも、そういう意味で言ったのですね。
FBなども核の部分以外はFBで作っているらしいですしね。
僕はてっきりPGやPrographのようなグラフィカルな作業環境の言語やFBよりもさらに高級言語にしたものからFBのソースを生み出すものを作るのかと思ってしまいました。
だってPowerPCの機械語や環境を学ぶのって大変そうですものね。
でも僕としては言語を作るよりToolsのようなpartsをいっぱい作って頂きたい（笑）
それと、それらを集めたwebページも・・・

古籏一浩です。

At 9:53 97.4.21 +0900, Toshihiko MORIKAWA wrote:
　たしかにそうです。私はColorClassicII(68030-33)からLC475改（68040-33）に変えましたが体感は倍くらい違う感じです。Photoshopみたいなものや3Dものをやる気はありませんが、それ以外ではぜんぜん問題ないです。
　604だと3Dは高速ですが３Ｄ以外であれば問題ないでしょう。
　どうせMacOS8もぽしゃった事だし安心して使えますね（笑）
　おまけにOSのバグフィックスをしてくれているのでいいかも。