RealBasic University

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

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

OOP University:パート 25

今回は、前回のレッスンで制作した一般的な進行状況表示ダイアログをどのように使用するかを示します。

ProgressDialogの取り扱い

プロジェクトを仕上げるのはとてもよいことなのですが、進行状況表示ダイアログを使用する方法を考え出さずに、実際にはテストすることはできません。よって、私はテスト・アプリケーションを作成しました。

progressDialog使用のための基本ステップは、次のようになります。

  1. initルーチンを呼び出し、我々が必要なウィンドウの種類を決定する。
  2. startProgressルーチン(二重バーのウィンドウであれば、startSubProgressルーチンも)を呼び出す。
  3. タスクを開始する。
  4. タスクの間は、何が行われているかをユーザに知らせるため、定期的にupdateProgressupdateSubProgressを呼び出す。
  5. タスクの間は、定期的にgPleaseStopProgresstrueであるかを確認し、もしそうであれば処理を停止する。
  6. 処理が完了したか、ユーザがキャンセルしたときは、stopProgressを呼び出す。

はじめてこれを見るときは厄介に感じるかもしれませんが、進行状況表示ダイアログを自分で書くよりは、はるかに簡単です。一般的に、それぞれは1行のコードですので、ライブラリーはとても簡単に利用できます。

たとえば、次は一本の状況表示ダイアログをテストするためのコードです。

  
dim i as integer
dim s as string

const bigNum = 1000000

// progressDialogの初期化
progressDialog.init("Single bar count", true, cancelCheck.value)
progressDialog.startProgress("Counting...", bigNum \ 1000)

for i = 1 to bigNum
// 平等に1000で割られた場合
if i / 1000 = i \ 1000 then
s = "Item " + str(i) + " out of " + str(bigNum)
progressDialog.updateProgress(s, 1)
end if
if cancelCheck.value and gPleaseStopProgress then
progressDialog.updateProgress("User aborted...", bigNum \ 1000)
exit
end if
next // i

// すべて完了したので、ダイアログから出る
progressDialog.stopProgress

これは単に百万まで数え上げるタスクで、それに従って進行状況を表示します。数値を1000で割っているので、我々はプログレス・バーを時々に更新するだけであることに注意してください――もしプログレス・バーを百万回まで毎回更新していたら、永遠に時間がかかってしまいます(プログレス・バーは実行速度を大幅に低下させます)。

この例では、ダイアログがキャンセル可能であるかどうかを設定するため、checkBoxコントロール(cancelCheckコントロール)を使用します。キャンセル可能であれば、ユーザが動作をキャンセルしたかを確認するため、グローバル・プロパティのgPleaseStopProgressをチェックします。キャンセル・イベントの実際の検知はダイアログ内でなされますが、実際にはダイアログは動作を停止できませんので、それが動作がキャンセルされたことを通知された場合には、タスク内で動作を停止するためのチェックをしなければなりません。

お分かりのように、再利用可能なプログレス・バーのダイアログのルーチンの呼び出しは、シンプルかつ効率的で、とてもよく機能します。このルーチンを二重のループに簡単に修正して、二重のプログレス・バーのダイアログをテストすることができます。

  
dim i, j as integer
dim s as string

const outerNum = 10
const innerNum = 100000

// progressDialogの初期化
progressDialog.init("Dual bar count", false, cancelCheck.value)
progressDialog.startProgress("Counting...", outerNum)

for i = 1 to outerNum
s = "Item " + str(i) + " out of " + str(outerNum)
progressDialog.updateProgress(s, 1)

progressDialog.startSubProgress("Counting inside", innerNum \ 1000)
for j = 1 to innerNum
// 平等に1000で割られた場合
if j / 1000 = j \ 1000 then
s = "Item " + str(j) + " out of " + str(innerNum)
progressDialog.updateSubProgress(s, 1)
end if
if cancelCheck.value and gPleaseStopProgress then
progressDialog.updateSubProgress("User aborted...", innerNum \ 1000)
progressDialog.updateProgress("User aborted...", outerNum)
exit
end if
next // j

if cancelCheck.value and gPleaseStopProgress then
exit
end if
next // i

// すべて完了したので、ダイアログから出る
progressDialog.stopProgress

これは一目瞭然でしょう。ループが2つである以外は、先ほどのものと同じです。

ところで、このプログレス・バーのシステムがうまく機能しない場合に遭遇するかもしれません。しかし、これはプログレス・バーを導入するひとつの方法に過ぎません。次回のチュートリアルで、私はスレッドを含んだいくつか別のアプローチを取り上げましょう!

今週のチュートリアルの完全なREALbasicプロジェクト(リソースを含む)を手に入れたい場合は、こちらからダウンロードしてください。

次週

プログレス・バーのダイアログの別のアプローチをご紹介します。

News

REALbasic Developer 2.1 2003年8/9月号発行

REALbasic Developerマガジンの最新号が発行されました!8/9月号は、数多くのすばらしい記事を特集しています。

はじめに、次期バージョンのREALbasicは、Linuxへのコンパイルをサポートするというびっくりするようなニュースをご存じでしたでしょうか?RBDはREAL Software社の仲間へ独占インタビューすることに成功し、特ダネを手に入れました。

REAL Software社について言うと、おそらく多くの人はDavid Grogono氏の名前を聞いたことがあるか、彼とEメールを交わしたことがあると思います。しかし、彼は一体誰なのでしょうか?REALbasicプロダクト・マネージャーであるDavid Grogono氏へのインタビューが、そのすべてを明らかにします。彼はREALbasicを指揮するため、船長としてどのような人生を過ごしてきたをみてください。

3Dの達人、Joe Strout氏が今回非常におもしろいリアルタイムのメッシュ・デフォーメーションを携えて戻ってきました。例題プロジェクトでは、風にはためいている布をどのようにシミュレーションするかをお見せします。感動的です。

それから、Charles Yeomans氏から二本立ての記事が届いています。はじめに、REALbasic 5の新しい拡張とキーワードの割り当てについて知る必要のあることを説明し、それから、きちんとした「最近の項目」メニューをプログラムに追加する方法について、すばらしい記事を提供してくれました。

そしてもちろん、これらの記事に加えて、ニュース、レビュー、そしてすべての定期コラムの記事も掲載しています!

定期購読者は、今週にも今号が届くでしょう。もし定期購読していない場合は、定期購読しましょう!既刊号を見逃したくない場合は、すべてのバックナンバーを注文することもできます。

Letters

今回はRichard DavisさんからWindowsでのコンパイルについての質問を頂きました。

こんにちは

私はRB5.2 for OS Xの試用版をつい最近ダウンロードしました。私はまったくプログラムの経験がなく、早く習得したいと思っています。私の目的は、自分自身とWindowsを使っている私の友人のためのプリケーションの開発です。私はRBのWindowsの出力は決して完全ではないというコメントをいくつか読みました。私は、RBがWindows用のアプリケーション作成にどれほどよいのか先入観のない意見を伺いたいと思います。私はVisual Basic 6 for Windowsを持っているので、Macの開発環境用にRBのstandard版を購入して、WindowsではVBを学習することもできます。

よろしくお願いします

Richard Davis

Richardさん、これは難しい質問です。私はWindows向けの開発経験はあまりありませんが、私なりの意見を述べようと思います。あなたの状況はことなるかもしれません。

簡単なアプリはとてもうまくいくようです。コンパイルを選択すると、Windows上で動く.exeファイルができあがります。しかし、さらに複雑なプロジェクトでは、いくらかの余分な仕事をしなければならないでしょう。ある時は、この余分な仕事はファイルが処理される方法のような単純なプラットフォームの違いであり、ちょっとした工夫でマルチ・プラットフォームのアプリケーションを作成することができます。

またある時には、コントロールの反応の仕方にイベントが処理される順番や方法などの微妙な違いがあることに気がつくでしょう。この問題に対処するにはいくらか微調整をして、どちらのプラットホームでもまったく同じように機能するようにします。

難しさの度合は、あなたの遭遇する特有のバグ/問題や、あなたが何を望んでいるかといった多くの要因に依存します。(走るだけのアプリを開発するのと、それぞれのプラットホームのユーザー・インターフェースのガイドラインに完全に沿った洗練されたアプリを開発するのとでは大きな違いがあります)

一般的には、設計が重要です。クロス・プラットフォームのアプリケーションを開発するために一から仕事を始めるならば、それぞれのルーチンを書くときは両方のシステムで機能することを確認して、プラットホーム特有の仮定(対象となるプラットホームになれていない場合はついやりがちです)をしないように細心の注意を払えば、あなたのアプリは両方のプラットホームでもうまく走るでしょう。

たとえば、長年のMacユーザとして、私はそれに気がつかないうちにMac特有の解決策を考える傾向にあります。私が問題を解決しようとすると、私は「おい、AppleScriptでそれができるじゃないか!」と考えるかもしれません。残念なことに、もちろんAppleScriptはWindows環境では動作しないので、クロス・プラットホームのアプリではよい解決策ではないでしょう。逆もまた真です。ActiveXコントロールは、Mac環境では使えません。

私のMac中心的な考えの別の例を挙げます。私が始めて「本物」のクロス・プラットホームのアプリであるRBU Pyramidを作成したときに遡ると、私はMac特有のグラフィック・フォーマットを使用していました。それはMacではうまく機能しましたが、PCでは画像はうまく表示できませんでした。私はそれらをWindowsで使えるように.bmpファイルで保存しなければなりませんでした。たいした問題ではありませんが、考えなければならないことの内の1つです。

Windows環境で動作するREALbasicのIDEがあることは、クロス・プラットホームの開発者にとって大きな恩恵です。以前は、我々はMacでコンパイルして、テストのために.exeをWindowsに移動しなければなりませんでした。迅速な開発のためには整備されていませんでした。現在は、どちらのプラットホームのアプリも、両プラットホームで開発でき、開発が見違えるほど簡単になりました。あなたの選択したプラットホームで大雑把な開発をして、それから微調整のためにプロジェクト・ファイルを別のプラットホームに持って行くことができます。

実践も助けになります。あなたがクロス・プラットホームのアプリを制作すればするほど、潜在的な落とし穴により多く気がつくようになり、それを避けることができます。

REALbasicのクロス・プラットホームのサポートには、本質的に何も悪いところはないと理解してください。いくつかのバグや問題はありますが、これらの大部分はとるに足らない問題や操作上の違いに分類されます。ほとんどの状況でそれらは問題ではありませんが、あなたが何か複雑なことをしているならば、それぞれのプラットホームでタスクを行う最善の方法を見つけ出すための時間が必要となるでしょう。

私は、プロフェッショナル級のクロス・プラットホームのアプリを公開してきた開発者と話をしてきました。彼らは例外なくREALbasicのクロス・プラットホームの能力を称賛しています。もちろん、彼らは問題もあるといいますが、それらは一般的に大したことでなく、解決策を見つけるためにちょっとした仕事が必要になるだけです。

一方では、Macのみ対応のアプリケーションをWindows用にコンパイルしようとして、それがうまく動かないときに泣き言を言うきまぐれな多くのユーザを私は知っています。いくつかの簡単なアプリは、何も変更を加えないで別のプラットホームにコンパイルできますが、それは希です。ほとんどのプロジェクトは、うまく機能するには簡単な微調整が必要です。私はそれを恐れはしませんし、REALbasicが魔法のようで、あなたのためにすべてのプラットホームの違いを自動で解決するとは私は考えません。クロス・プラットホームのアプリを作成するには、労力が必要です。アマチュアの人にとっては、それは苛立たしいことです。ところがプロフェッショナルの人は、C++のような伝統的な言語でクロス・プラットホームのアプリを書くことに比べると、REALbasicfははるかに簡単にすむので夢のように感じます。

クロス・プラットホームのウェブ開発の状況を比較したいと思います。あなたが今までに何かウェブの仕事に携わったことがあるならば、プラットホーム間での微妙で面倒な違いがあることをご存じでしょう。私は今朝、REALbasic Developerのウェブサイトで2つの問題を発見しました。たとえば、私は「#FFFF00」でなく「#FF0」をテーブルセットの背景色にしていました――うまく行くはずの簡略表現です。Macではこれはうまく機能しますが、Windows環境ではこの黄色は黒になります。私はそれを長い色の表現に変更して、Windows環境でのIEでもうまく表示されました。

これはあなたがクロス・プラットホームの開発をREALbasicで行うときに突き当たるタイプの問題に似ています。その内のいくつかはREAL Software社が修正するバグですが、他のものはOS間の違いです。面倒な部分は、あなたがそれらについて知るまでは、クロス・プラットホームの開発は必要以上に手間のかかることです。よい知らせは新しいREALbasicが公開されるたびにこの点についてより良くなっていることです。

あなたへの最後のアドバイスは、それを試してみるようお薦めすることです。あなたは他のプラットホーム用にREALbasicの30日間の試用版をダウンロードして、アプリがどのように動くかを確認することができます。それが機能しなければ、その理由を考えてみて、しばらく地道な努力をしてみてください。多くの場合、アプリがクラッシュするような恐ろしい誤りも、ある一行のコードが原因であったり、修正が自明であることにり引き起こされることがわかります。プログラムをステップ毎に追跡してみて、それが何をしているのか注意してください。そうすればエラーが見つかるでしょう。

たとえば、かつてWindowsで動作しないプログラムがありました。ヘルプがプログラムのリソース・フォーク(Windows環境では利用不可)からファイルを読み出そうとしていることを忘れていたのに気がつきました。しかし、ヘルプ・システムはバックグラウンドでロードされるもので、プログラムのタスクの主要部分とは密接には関連していないので、それが問題の部分であると気がつくのに時間がかかりました。私はWindowsで実行しているときはヘルプ・ファイルをディスクから取り出すようにする数行を追加しました。これで、プログラムはうまく動きました!

始めに述べたように、私はクロス・プラットホームのコンパイルに精通していません。しかし、私はちょうどWindowsコンピュータを購入して、学習の準備を整えました。RBUのレッスンの多くは、クロスプラットフォームでなく、私はそれをいつか改めたいと思っています。将来のレッスンでは、両方のプラットホーム(そしていずれはLinuxも)でテストができるでしょう。私がクロス・プラットホームの問題について勉強するにつれて、私は必ずREALbasic Universityの読者の方々とそれを共有することでしょう。


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

INDEXに戻る