RealBasic University

このコラムはStone Table Softwareのオーナーであり、またREALbasic Developerの編集者でもあるMarc Zeedar氏により書かれたものを、著者の許可を得て翻訳したものです。この翻訳はHREM Researchにより提供されています。この日本語版へのご意見はRBU-Jまでご連絡下さい。

URL: http://www.applelinks.com/rbu/012/
INDEXに戻る

Rename ダイアログ

今週は、2つのダイアログボックス, renameDialogeditDialog にコードを追加して、我々の最初のプロジェクトであります GenderChangerを完成させます。

では、簡単な renameDialog から始めましょう。これはユーザが記憶されている項目をダブルクリックしてその名前を変更するときに、Edit Types ダイアログから呼ばれます。

まず最初に、renameDialogの Open イベントに行きましょう。そのコードに "editField1.text = gDialogReturn" と入力します。これはグローバルな文字列変数 gDialogReturn の内容をダイアログの editField に代入します。何故そのようなことをするのでしょうか?私はダイアログが開かれたときに gDialogReturn が現在のファイルタイプを保持していることに思いつきました。それで、現在の名前を文字入力欄に設定しているのです。

次は、renameDialogの canvas1 オブジェクトの Paint イベントです。ここでは、ただ Macintosh の標準アイコン("note" アイコン)をキャンバスに描こうとしています。(キャンバスは描画領域のオブジェクトであることを思い出して下さい。)

REALbasic の強力な描画メソッドの全ては graphics オブジェクトの一部です。Paint イベントはオブジェクトが再描画されなければならないとき(ウィンドウが他のウィンドウで覆われたときなど)にいつも呼び出され、引数として graphics オブジェクト g が与えられます。RB は組み込みの drawNoteIcon メソッドを持っています。我々はそれを描画座標を 0 と 0(水平、垂直方向)に指定して利用します。

  g.drawNoteIcon 0,0

これだけです。簡単でしょう?今後の RBU プロジェクトではもっと複雑なグラフィックスを取り扱うでしょう。今回のところは、次に EditField1 に移って、その TextChange イベントを見つけて下さい。

renameDialog.EditField1.TextChange のコード

  if len(me.text) = 0 then
    pushButtonOkay.enabled = false
  else
    pushButtonOkay.enabled = true
  end if

ここでは文字入力欄のテキストの長さをチェックするのに len() 関数を使って、EditField1何かを含んでいるかを確認しています。そして、もしそれが空であれば okay ボタンを選択不能にします。このコードはテキストが変更されるたび(このためにこれは TextChange イベントと呼ばれます)に実行されますので、最後の文字が削除された瞬間に、okay ボタンは確実に選択不能になります。

改善点: 理想的に言えば、ここではさらにもっとすべきことがあります。我々はユーザが既に使用されているファイルタイプ名を入力していないことを確かめるべきでしょう。我々が先週に書いた returnItemNumber メソッドを憶えていますか?そのルーチンはそれぞれの名前がただ1つだと仮定しています。もし、2つのファイルタイプが同じ名前を持っていれば、最初のものだけが選択されます。ですから、我々はここでユーザが同じファイルタイプ名を入力できないようにすべきなのです。しかし、このことはあなたが行なう GenderChanger の改良として取っておきます。

我々は renameDialog に関してまだ完了したわけではありませんが、殆ど終わっています。追加しなければならない2箇所のコードを残すのみです。ユーザが Cancel か Okay ボタンのどちらかをクリックしたとき、我々はそれをどうにかして記憶しておかねばなりません、それからダイアログボックスを閉じねばなりません。ですから、以下のコードを Cancel および Okay ボタンの Action イベントに追加します。

renameDialog.PushButtonOkay.Action のコード

  gDialogReturn = editField1.text
  self.close

renameDialog.pushButtonCancel.Action のコード

  gDialogReturn = ""
  self.close

ここで我々のしたことは、ユーザが Okay ボタンをクリックしたときには、 editField1 の内容 -- 新しい名前 -- を gDialogReturn に保存することです。もし、ユーザが Cancel ボタンをクリックした場合には、我々は gDialogReturn を空("")に設定します。これにより、renameDialog を呼びだしたルーチンは gDialogReturn をテストして、ユーザがキャンセルしたかどうかを知ることができます。

self 関数はオブジェクトが乗っている親のウィンドウを指し示します。それは renameDialog ですので、self.closerenameDialog にクローズコマンドを送る1つの方法です(renameDialog.close でもいいのですが、汎用性にかけます。)

Edit Types ダイアログ

これは GenderChanger のなかで最も複雑なところです。我々は随分と手の込んだユーザインターフェイスを作ろうとしていることを思い出して下さい。我々はユーザが新たにファイルタイプを追加するためにそれらのファイルをダイアログにドロップする、また既存のファイルタイプを削除する、そしてファイルタイプの名前を変更することができるようにしたいのです。我々はまたユーザがコードを直接タイプすることにより Type や Creator のコードを編集できるようにしようとしているのです。我々は新たな REALbasic の素晴らしい機能について学びましょう、準備はいいですか!

まず、簡単なものから始めましょう。editDialog のコードエディタを開きましょう(editDialog をプロジェクトウィンドウで選択した状態で、option-Tab をおします)。Controls のセクションを広げて、PushButtonDone をダブルクリックします(これによりボタンの Action イベントに移るでしょう)。そこに次のコードを書きます。

editDialog.PushButtonDone.Action のコード

  listBox1.headingIndex = 0
  saveData
  self.close

このボタンはファイルタイプの編集が終了したときにユーザによりクリックされます。ですから、次の3つのことを行なう必要があります:リストをソートすること、データ(どのような変更も含めて)が保存すること、そしてダイアログボックスを閉じることです。

まず最初に、リストをアルファベット順に並べるようにしましょう。リストボックスの最初の列(0番目のコラム)はファイルタイプ名ですので、我々は最初の列でソートしてリストをアルファベット順に並べています。リストボックスはユーザがそれらのボタンのどれかをクリックしたときに、そのコラムによって自動的にソートをおこなう見出し(ヘッダ)ボタンを持っています。我々は listBox1の headingIndex 属性をプログラムでゼロに設定することにより、ユーザが最初の列をクリックするのを真似ることができます。

次に、我々は saveData を呼んでいます。このメソッドはまだ書いてはいませんが、今のところはそれはダイアログボックスでなされた全ての変化を保存すると仮定しておきましょう。

最後に、我々は self.close コマンドでダイアログを閉じています。

では、saveData メソッドを作成しましょう。Edit メニューに行って、"New Method" を選択し、名前を "saveData" としましょう。

まず、saveData の全体のコードを示して、それからそれが何をしているのかを説明します。

editDialog.saveData のコード

  dim i, n as integer
  
  n = listBox1.listCount
  redim gTheFileList(n)
  for i = 1 to n
    gTheFileList(i) = new fileTypeClass
    gTheFileList(i).name = listBox1.cell(i - 1, 0)
    gTheFileList(i).macCreator = listBox1.cell(i - 1, 1)
    gTheFileList(i).macType = listBox1.cell(i - 1, 2)
  next

もし、あなたが今までの GenderChanger を見てきていれば、最初の数行は見慣れているでしょう。我々は基本的にはループを設定しているのです:ループを廻って、毎回、我々はデータ(ファイルタイプの情報)の個々のレコードを保存しています。

我々は n にリストボックスの項目数を設定しています。それから、配列の領域を redim(再確保)しています。ここでは配列の項目数を n に設定します(使用しない0番目の配列要素は数えていません)。このようにしてユーザがリストボックスに要目を追加すれば、それらは組み込まれます。逆に、ユーザが幾つかの項目を削除したときには、それらは新しい配列には含まれなくなります。全体のデータ構造を1から再構成するのはいつでも最適な方法という訳ではありません(それは時間を無駄にします)、しかし我々の簡単な目的にはこれでもいいでしょう。

ここでは、我々は listBox1 内の項目を巡回するために for-next ループを使っています。それぞれのレコードについて、我々は fileTypeClass オブジェクトを初期化(new)して、それからリストボックスの行にあるデータをその内容に代入しています。これはおそらく目で見た方がより判りやすいでしょう。幾つかの項目が追加されたときの listBox1 を次に示します:

ここには3つのコラム(列)、Name、Creator、および Type があり、4つのファイルタイプが追加されています。最初の行は name が"FreeHand"、 Creator が "FH80"、そして Type が "AGD3" です。(もし、ファイルにこのファイルタイプを与えると、それは Macromedia の FreeHand 8 のファイルとして現れるでしょう。)この 3 x 4 の格子は表計算(spreadsheet)と非常によく似ています:そこでは12のセルがあり、それぞれのセルは重要なデータを(文字列、あるいはテキスト形式で)保持しています。

REALbasic ではリストボックスの cell メソッドを使ってそれぞれのセルを独立にアクセスすることができます。この cell メソッドは2つの情報を必要とします:それはあなたがアクセスしたい行と列です。これは容易に得られる情報です:ループ変数 i は現在の行を現しています(それぞれのレコードは別々の行にあるので)、そして我々はどのコラムがどの情報を持っているかを知っています。

しかし、リストボックスの行はいつもゼロから数えられ、そして i は1から始まっていますので、我々は cell メソッドに引き渡すまえに i から1を引く必要があります。列もまたゼロから数えられますので、Name = 0、Creator = 1、そして Type = 2 ということが判るでしょう。すなわち、listBox1.cell(0, 0) は "FreeHand" を、そしてlistBox1.cell(2, 2) は "SIT5"(StuffIt 5 のタイプコード)を返すでしょう。

Tipcell メソッドは、我々がちょうど望んでいるように、データを文字列として返しますので、どのような変換も必要としません:我々はただそのままセルの内容をデータオブジェクトに代入することができます。(もし、我々が数値欄を持っていたとすると、我々は返された文字列を val 関数を使って数値に変化しなければなりません。)

このように、ループを巡るごとに、我々は新しいデータオブジェクトを生成し、それに listBox1 のそれぞれの行の内容を代入します。ループが終了したときには、すべてが終わっています。我々は gTheFileList をグローバルな配列として作りましたので、editDialog は自由にそれにアクセスすることが可能です、そして我々は新しいデータ構造をメインアプリケーションに送り返すというようなことを心配する必要はありません:データはグローバルなのです。

これで、saveData の説明は終わりです。次に、数箇所にコードが必要な listBox1 に進みましょう。最初に、Open イベントに行きましょう。ここは listBox1 を初期化するところです。これは重要なところです。何故ならば、ここはファイルタイプのデータを追加して、ユーザがダイアログボックスを開いたときに、listBox1 が現在のファイルタイプのリストで満たされているようにするところです。

まず Open イベントの完全なコードを示します。説明はその後にあります。

editDialog.ListBox1.Open のコード

  dim i, n as integer
  
  me.heading(0) = "Name"
  me.heading(1) = "Creator"
  me.heading(2) = "Type"
  
  me.columnType(1) = 3
  me.columnType(2) = 3
  
  me.acceptFileDrop("anyfile")
  
  n = uBound(gTheFileList)
  for i = 1 to n
    me.addRow gTheFileList(i).name
    me.cell(me.lastIndex, 1) = gTheFileList(i).macCreator
    me.cell(me.lastIndex, 2) = gTheFileList(i).macType
  next

コードの最初の部分は単純です。我々は必要とする変数を宣言しています、そして列の見出しボタンを適切に設定しています。それから、面白そうなコマンドが並んでいます:"me.columnType(1) = 3"。これは何なのでしょうか?

さて、REALbasic はリストボックスに異なる種類のインターフェイスをサポートしています。リストボックスの内容を表計算とどのように比較したかを憶えていますか?表計算の異なるセルがテキスト以外のものを含むことができると想像してみましょう。例えば、チェックボックスはどうでしょうか?(例えば、私は「税金」欄の含む/含まないを選択するためにチェックボックスを使っている請求書を作成するプログラムを作りました。)

チェックボックスは選択肢の2です。"me.columnType(1) = 3" を "me.columnType(1) = 2" に変えると、2番目の列のセルはテキスト欄のかわりにチェックボックスになります。ここに2番目の列がチェックボックスに設定されたときの Edit File Types ダイアログがどのようになるかを示します:

明らかに、これは我々がこのアプリケーションに望むものではありません。しかし、RB でそのようなことができるのは素晴らしいではありませんか。我々の場合には、別の選択肢3を選んでいます。この3の設定はそのセルを編集可能にしたいということを REALbasic に伝えています。これはユーザがセル内で入力するのを可能にするということの RB 流のいい方です。そうです:あなたは、表計算のセルのように、セル内で直接に編集することが可能なのです!

2番目と3番目の列を編集可能にすることによって、ユーザはファイルのクリエータとタイプを手入力することが可能になるでしょう。これはタイプとクリエータコードを知っている熟練したユーザのためのクールなオプションで、そして平均的なユーザを混乱させることもありません。

簡単なクイズ:聡明な読者は我々は列1と2を編集可能にしましたが、列0はそうしなかったことに気が付いたでしょう。列0はファイルタイプ名ですので、それを編集可能にするのは自然であるように思われます。では、なぜそれを編集可能にしないのでしょう?答えは経験によるものです。 セル内の編集は、便利ですが混乱しやすいものです。例えば、ユーザがある行のセルをクリックしたとすると、何処をどのようにクリックするかに依存して、全体の行が選択されるかも知れませんし、あるいはそのセルが編集可能かも知れません。これではユーザにとって全体の行を選択したいときにどのようにすればいいのかを理解するのが非常に困難です。我々の場合には、行を選択して delete キーを押すことによって行を削除する機能をユーザに与えたいので、行の選択は重要です。もし、すべての3つのセルが編集可能であれば、ユーザは選択しようとして行をクリックしても、プログラムはそのセルに編集カーソルを置いたままになるでしょう。name 欄を編集不可にすることにより、それをクリックして行を選択できます。Type または Creator セルのクリックはセルを編集可能にします。ユーザにとってその違いを理解するのは容易です。別の名前変更のダイアログボックスを使うことにより、ユーザにとって物事を複雑にすることなしに、行を選択するときの問題を回避しています。

この Open イベントの次の行のコードは listBox1 がドロップされたどのような種類のファイルでも受け付けるようにしています。何故そのようにするのでしょうか?そうですね、我々はユーザにファイルタイプをリストに追加する簡単な方法を与えたいのです。このようにすれば、このダイアログが表示されているときには、どのようなタイプのファイルでもリストボックスにドロップして追加することが可能です。Quark XPress の書類タイプをファイルタイプのリストに追加するのはどうすればいいのでしょう?どれかの Quark ファイルを単に listBox1 にドロップすれば、それは追加されます!

コードの最後の部分は別のループです。我々はまず配列の大きさを知るために uBound を使っています、それからその配列をループします。それぞれのレコードについて、まず保存されているファイルタイプの名前を0番目のコラム(列)に設定しながら新しい行を listBox1 追加します。それから、その同じ行に Creator と Type のコードをそれぞれ1番目と2番目の行に設定します。

ところで、セルの中に入力する上のダイアログでは丁度4文字を入力していることに気が付いたでしょう。Type と Creator コードは正確に4文字でなければならないことを思い出して下さい。もしユーザが4文字以上あるいはそれ以下の入力をしたときにはどうなるでしょうか?

そうですね、その問題に対して解決しておくのが良いででしょうかね? listBox1cellAction イベントに行きましょう。このイベントはユーザがセルの編集を終わったとき(return か enter を押したとき、あるいは別のセルをクリックしたとき)にいつも起ります。その時にはユーザが編集したセルのが与えられますので、その情報を利用してそのセルの内容を取得することができます。

内容が取得できれば(文字列変数 s に代入して)、文字列の長さを len 関数を用いて調べることが可能です。もし、文字数が多すぎれば、left を用いて4文字に整形します。

left 関数には文字列と数値を渡します。すると、文字列の左から始まる指定された文字数の文字列を返します。例えば、left("hello", 4) は"hello" の左側の4文字である "hell" が返ってくるでしょう。

その結果をセルに戻すことによって、ユーザが入力したものを短くすることができます。

しかし、もしユーザが十分な長さの文字を入力しなかったらどうなるでしょう?簡単です:文字列に空白を詰め込みます。以下にそのコードを示します。

editDialog.ListBox1.CellAction のコード

  dim s as string
  
  s = me.cell(row, column)
  if len(s) > 4 then
    me.cell(row, column) = left(s, 4)
  elseif len(s) < 4 then
    me.cell(row, column) = left(s + "    ", 4)
  end if

後者の場合に何をしたか判りましたか?我々は4文字であること確実にするために left 関数をそこでも使っています。しかし、我々は left 関数に少なくとも4文字を渡すように、もとのセルの内容(s)が何であれ4つの空白を追加しています。このようにして、もし s が "t" であったとすると、それは "t   " になります、また s が "the" であれば "the " になります。(もし、s が完全に空欄であれば、それは "    " となります。)

では、KeyDown イベントに移りましょう:ここで入力するコードは、listBox1 が "フォーカス(focus)" を持っている(すなわち、それがアクティブなコントロールである)ときに、ユーザがキー入力をするたびに実行されます。ここで我々の行ないたいことのすべては、ユーザが delete キーを押したかを知ることです。そして、もしそうであれば、現在の行を削除することです。

Tip:delete キーは chr(8)、あるいは ASCII コード番号 8 です。これを私はどのようにして知ったのでしょうか?そうですね、長い経験からです。しかし、もし私を信じられない場合は、このプロジェクト を REALbasic に取り込んで、実行してみて下さい。それはあなたの入力するキーに対応する ASCII 番号を表示します。

editDialog.ListBox1.KeyDown のコード

  if key = chr(8) then
    me.removeRow me.listIndex
  end if

クイズ:上のコードには重大な欠陥があります。何が問題なのかが判りますか?その答えは次週に示します。誤りだけでなく、その解決方法をもお知らせいただいた最初の方には Z-Write無料で差し上げます!

では、DoubleClick イベントに進みましょう。ここはユーザが項目名の変更をできるようにするためのコードを置くところです。

2週間前に作った renameDialog を覚えていますか?このルーチンはユーザが名前を変更するためのダイアログボックスを開きます。

我々は現在の名前(現在の行の名前のセルから得られた)を大局的変数 gDialogReturn を介して renameDialog に渡します。それから、showModal メソッドでダイアログを表示します。このダイアログが モーダル modal であるというのは、そのダイアログが消えるまで GenderChanger が処理を中断するということです。(REALbasic ウィンドウはまた show メソッドを持っています。この場合にはウィンドウを表示しますが、他の動作を止めることはありません。)

ユーザがダイアログの処理を終了し、OK または Cancel をクリックしたときに、制御は showModal メソッドの直後のコードに戻ります。我々が最初にすることは gDialogReturn が空かどうかを調べることです:もし空であれば、ユーザが Cancel をクリックしたことが判りますので、名前を変化させません。もし、gDialogReturn が何かテキストを持っていれば、それは新しい名前ですので、gDialogReturn の内容を名前のセルに設定します。

editDialog.ListBox1.DoubleClick のコード

  dim i as integer
  
  i  = me.listIndex
  gDialogReturn = me.cell(i, 0)
  renameDialog.showModal
  if gDialogReturn <> "" then
    me.cell(i, 0) = gDialogReturn
  end if

Note:以前に話したことがありますが、これには、もしユーザが2つのファイルタイプに同じ名前を与えたときにどうするかという潜在的な問題があります。新しい名前が現存する名前のどれかに一致するかを renameDialog ダイアログを終了するまえに調べるべきでしょう。もしあなたが非常に熱心であるならば、GenderChanger を改善するためにご自分でそれをやってみて下さい。

いいですか、あなたが信じようと信じまいともうほとんど終わりです!我々はドロップされたファイルを処理するコードを追加する必要があります。では、DropObject イベントに行きましょう。

ここでは dragItem クラスの変数である obj が渡されます。DragItem はいろんな種類のデータを現すことのできる REALbasic の特別なオブジェクトです。それは種々のタイプのデータをアクセスするメソッドを持っています。我々の場合には、ドロップされたファイル(テキストや画像ではなく)にのみ興味をもっていますので、我々は folderItem が利用可能であるかを調べることになるでしょう。

NotedragItem データを使うときには、オブジェクトがあなたの期待するデータを含んでいないこともありますので、ますデータが利用可能かをいつも調べる必要があります。例えば、我々はユーザがリストボックスにファイルをドロップすることを期待しています。しかし、ユーザがワープロからリストボックスに画像をドロップしたとしても、DropObject イベントは起って我々のコードは実行されます。そうではないのに folderItem が使えるとのんきに仮定すると、プログラムは Nil Object Exception エラー(あなたが存在しない folderitem オブジェクトを使おうとしていることを意味しています)で終了してしまうでしょう。

正しい folderItem があることが判れば、それを自由に使えます。我々はそれがどのような種類のファイルであるかを知りませんので(「Quark XPress 文書」というような文字表現では)、我々はファイルタイプの名前としてドロップされたファイルの名前をそのまま使います。ユーザはその名前を後で変更することが可能です。

それでは、行を追加して、そこに folderItem の名前を設定します。それから、我々の追加した行を使って folderItem の Creator と Type コードを対応するセルに設定します。

editDialog.ListBox1.DropObject のコード

  if obj.folderItemAvailable then
    do
      listBox1.addRow obj.folderItem.name
      listBox1.cell(listBox1.lastIndex, 1) = obj.folderItem.macCreator
      listBox1.cell(listBox1.lastIndex, 2) = obj.folderItem.macType
    loop until not obj.nextItem
  end if

それを do loop until ループ内に置いていることに気付きましたか?これはユーザが1つ以上のファイルをドロップした場合に適応できます。obj.nextItemまたはであることを思い出して下さい:他の処理されるファイルがあればです。obj.nextItem をチェックすることによって、obj.folderItem はドロップされた次の folderitem に自動的に設定されます。

GenderChanger の実行

さて、お次は何でしょうか? GenderChanger はほとんど実行できる状態です!もし、あなたが既に試されたならば、それは1つのことを除いて、ほとんど機能することが判ったと思います:まだ我々はメインのリストボックスにファイルをドラッグすることができません。

REALbasic のプログラムでファイルがドラッグ&ドロップできるためには、以下の3つのことを行なわねばなりません:

始めの2つは既に済んでいます。DropObject イベントはドロップされたファイルに対して何をするかを知っています、そして我々は Window1.listBox1 の Open イベントに次のコードを置きました:

  me.acceptFileDrop("anyfile")

このラインは listBox1 にそこにドロップされた"anyfile" というタイプのファイルを受け付けるように指示しています。でも、どのような種類のファイルがタイプ "anyfile" なのでしょうか?我々はまだそれを示していませんので、REALbasic はそれを知るよしもありません。

Edit メニューに行って、最後の方の "File Types" を選びましょう。そして、"Add" ボタンをクリックします。現れるダイアログで、次のように、名前として "anyfile" を、そして Creator と Type の両方の欄に "????" を入力します:

そして、OK をクリックしてダイアログを閉じて、そしてプロジェクトを保存しましょう。もしここで GenderChanger を実行すれば(Debug メニューから "Run" を選択します)、メインダイアログにファイルをドラッグすることができて、プログラムは完全に動作するはずです。

もちろん、データ構造にファイルタイプを追加するまでは、GenderChanger はあまり使い物にはなりません:File Type ポップアップメニューは空の状態です。ですから、GenderChanger を起動して、Edit File Types ダイアログを開くために Command-E を押しましょう。そして、リストボックスに種々のタイプのファイルをドラッグしましょう。

これは動作している GenderChanger のアニメーションです:

1つかそれ以上のファイルタイプを定義すれば、Edit File Types ダイアログを閉じて、幾つかのテストファイルを変更してみましょう。(このことを強いて強調したいと思います:プログラムが正しく機能していると確信が持てるまでは、 取り返しのつかない実際のファイルではなく、練習用のファイルでプログラムをいつでもテストするようにしましょう!)

これは GenderChanger が BBEdit のファイルを Acrobat Reader の PDF のファイルタイプに変換するところのアニメーションです:

Finder はすぐにファイルを更新し、新しいファイルタイプに対応するアイコンが付くのが判るでしょう。

Note:GenderChanger は ファイルタイプ(Mac OS がファイルを見る見方)だけを変更しているのであって、ファイルの中身を変えてはいないということを覚えておきましょう。もし、PDF タイプに変更した BBEdit のファイルをダブルクリックすれば、Acrobat Reader が起動されますが、文書を開けないと苦情を言ってくるでしょう。もちろん、もしこれが BBEdit のテキストファイルとして誤って保存されている本当の PDF ファイルであるならば、タイプの変更によりそのファイルは Acrobat Reader で開くことができるようになるでしょう。

GenderChanger の完全なプロジェクト

次週は GenderChanger で学んだことを要約します。それまでのところは、読者の提案により、完成した GenderChanger のREALbasic プロジェクトファイルをお渡ししようと思います。(それは REALbasic 2.1 のフォーマットですので、RB の現在および古いバージョンの両方のユーザがそれを使うことができます。解凍するためには StuffIt Expander が必要になります。)

もしあなたがこのレッスンの全ステップをたどっていない場合には、この完全なプロジェクトにより、このプログラムをつくるために私のしたことを正確に知ることが可能になるでしょう。プロジェクトを研究し、実行し、そしていろいろ機能を拡張してみて楽しんで下さい!

次週

これで、我々は GenderChanger を完成しました。次回は、他の人に配布可能なプログラムをコンパイルする方法、起りうる問題点とあなたが解決できる改良点について議論します。また、クイズの受賞者とその解答を公表します。

Letters

今週の手紙は Ernie Peacock さんからの次のような質問です:

Marc,

これはおそらくばかげた質問でしょう -- 以前の SuperCard のスクリプトの数年の経験を別にすれば、私はほとんど全くの初心者です。

私はあなたが(例えば)save メソッドのほとんどをエラートラップの中に入れているのに気付きました。ただ簡単に f=nil をテストして、エラーメッセージを与えて、それからメソッドを実行するというようにはできないのでしょうか?

同時に働いている複数の条件文があるときには、私の古い頭はそれについていくのに苦労します。もし、それが単にスタイルの問題であるならば、私は「一度に1つ」の簡単な方法の方が判りやすいと思います。しかし、あなたのようにするのが良いという理由が多分あるのでしょう...

あなたのコラムに感謝しています -- あなたはプログラムを勉強しようという私の決心を再燃させてくれました。

追伸:このレッスンのプリンタ用のバージョンがあれば小さな iMac モニターを使っているものにとっては福音となるでしょう。

Ernie さん、手紙を有り難うございます。この RBU では、我々はどのような質問もばかげているとは思いません!

あなたの考えは正しくて、どちらの方法でもうまくいきます。私は私の使っているスタイルに慣れていますが、私も非常に長いコードが if-end if に包まれているときには混乱することもあります。あなたはルーチンの最初に次のものを置くことも可能です:

  if f = nil then
    msgBox "Error! Couldn't open file!"
    return
  end if

この場合には、あなたは return コマンドを必ず含めなければなりません。そうしないと、メッセージが表示されたあとも実行が続きます。return はエラーメッセージの後のルーチンの処理を中止し、そのルーチンを呼び出したプログラムの部分に戻します。

プログラミングには多くの方法とスタイルがあります;RBU で私がしたいことの1つは同じこと行なう異なる方法を示すことです。ですから、それが上手くゆくことを示すために、今後のプロジェクトであなたの方法を使うこともあるでしょう。異なるコーディング方法では多くの場合に性能的な違いはありません。しかし、時々、ある方法は他のものに較べてデバッグがしやすい、あるいはあるスタイルがあなたの頭脳に合っているということもあるでしょう。

プリンタ用のフォーマットに関しては、別の人もそれぞれのコラムの PDF ファイルを含めることを提案されていますので、今そのための方法を調べているところです。

RBU のための今後のプロジェクトに関するアイデアはありませんか?REALbasic に関する質問はありませんか?あなたの質問とコメントを送って下さい!

RBUの通知への申し込み!

別のお知らせ:Applelinksは要望の大きかったREALbasic Universityへのメーリングリストを開設しました。今日申し込みをすれば、コラムが発表されるたびにお知らせの emailがあなたに届きます!これはRBUに遅れを取らないための便利なお知らせです。

RBU-Jの通知サービス!コラムが発表されるたびに日本語版REALbasic Universityのお知らせの emailがあなたに届きます。登録・削除は ここ から。

INDEXに戻る