JA/translation/Base/New features in 3 1
このページは、http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1の日本語訳を行うページです。
現在の進捗段階は以下のとおりです。
STEP1（本文コピー） → STEP2（文書調整） → STEP3（アカウント作成） → STEP4（既存翻訳の移動） → STEP5（翻訳） → STEP6（最終調整）
New database features in OOo 3.1
Compiled from features dba openoffice org mailing list mails, and referenced specifications.
Base General
Macros in database documents
Database documents (.odb) now allow to embed macros and scripts, in exactly the same way the other OOo document types already allow.
データベースドキュメントのマクロ
データベースドキュメント（.odb）は現在、他の種類のOOoドキュメントが既にそうしているのと全く同じやり方で、マクロとスクリプトを埋め込んでいます。（飯高敏和）
Up to now, macros can be embedded into sub documents of a database document, that is, into forms and reports (which technically are Text documents), it will change to one place, database document.
これまでのところ、マクロはデータベースドキュメントの複数のサブドキュメントに埋め込むことができます。つまり、フォームとレポート（技術的なことを述べると、これらはテキスト形式の複数のドキュメントです）に埋め込むことができます。しかしそれは、データベースドキュメント一箇所に変わることになります。（飯高敏和）
This means, all macros from forms moved into main part of database, assigning macros to elements in a form document will be possible with macros from the database document only, not with macros from the form document. Macros can be run from either the document itself, or any of its sub components: forms, reports, table design, query design, relation design, table data view. Customization of macro can be done into a toolbar, or a menu, of any sub component. When recording a macro in a form or report, the final dialog which lets you decide where to store the macro will not list the form/report anymore, but the database document.
これが意味するのは、マクロが全てフォームからデータベースの主要部分に移動したということであり、フォームドキュメントの要素へのマクロの割り当てが、フォームドキュメントのマクロではなく、データベースドキュメントのマクロつきで可能になることなのです。ドキュメントそのものからも、フォーム、レポート、テーブルデザイン、クエリーデザイン、リレーションデザイン、テーブルデータビューなどのドキュメントの任意のサブコンポーネントからも、マクロを実行することができます。任意のサブコンポーネントのツールバーやメニューのなかにマクロをカスタマイズすることができます。マクロをフォームかレポートに記録するとき、マクロの格納先をたずねる最終ダイアログは、データベースドキュメントをのぞき、もはやフォームやレポートはリストに表示しません。（飯高敏和、久保田貴也）
Migration
Database documents created with version prior to OpenOffice.org 3.1 might contain forms or reports with embedded macros or scripts. Since this is prohibited, a migration path is necessary.
The goal is to transform documents so that all the macros and scripts are in the database document, this cannot be done automatically.
マイグレーション
OpenOffice.org 3.1より前のバージョンで作成されたデータベースドキュメントは、マクロやスクリプトの 埋め込まれたフォームやレポートを含んでいるかもしれません。これが禁じられているために、マイグレーション手続きが不可欠になっています。
全てのマクロとスクリプトがデータベース・ドキュメントの中にあるようにするために、ドキュメントを改変するのが目標なのですが、これを自動的にすることはできません。（飯高敏和、久保田貴也）
Compatibility Warning
When the user simply opens an "old" document containing macros and/or scripts in the sub documents, nothing except compatibility warning box came up, when first time opened that file. Until the user migrated the macros, the database document, and all sub documents, will behave as if the feature which this spec is about were never implemented. In particular, the user is free to create additional or modify existing macros in her forms and reports, to customize macros from sub documents into her toolbar/menu, to bind those macros to events in the sub documents, and so on.
互換性警告
ユーザーがサブドキュメントの中にマクロかスクリプト (もしくは両方) を含んでいる「古い」ドキュメントを単純に開いてしまうと、最初にそのファイルを開いた際に互換性警告ボックスがでる他はなにもありません。ユーザーがマクロを マイグレーションするまでは、データベースドキュメントと全てのサブドキュメントは、あたかもこの仕様書が問題にしている機能を実装していないかのように動作するでしょう。特に、フォームやレポートの既存マクロを変更したり、またはあらたに追加したり、サブドキュメントのマクロをツールバーやメニューにカスタマイズしたり、サブドキュメントのなかでこれらのマクロをイベントとバインドしたり、などなど自由にできてしまいます。（飯高敏和、久保田貴也）
Migration Wizard
Introduced new menu item, called "Migrate Macros ...", located in the top-level menu "Tools", immediately below the existing "SQL ..." item.
マイグレーション ウィザード
新しいメニューの項目を導入し、名前を「マクロのマイグレーション・・・」とし、最上位のメニュー「ツール」の既存の項目である「SQL・・・」のすぐ下におきます。（飯高敏和、久保田貴也）
When the user selects this menu item, a wizard will guide her through the migration, which effectively consists of the following steps:
ユーザーがこのメニューの項目を選択すると、ウィザードがマイグレーションを通じてユーザーをガイドすることになり、それは効率的に次のような四つの段階からなっています。（飯高敏和）
- close all sub components of the database document, namely forms, reports, and any open designers
- backup the database document
- migrate the scripts and macros while displaying a progress bar
- show a summary
For a detailed description of the feature, you're encouraged to read the specification:
- データベースドキュメントの全てのサブコンポーネント、つまりフォームとレポート、そして開いているどのデザイナーも閉じられます。
- データベースドキュメントがバックアップされます。
- 進捗状況バーが表示されている間は、スクリプトとマクロがマイグレーションされます。
- 概要が表示されます。
機能の詳細にわたる説明については、次の仕様書を読むことが推奨されています。（飯高敏和）
http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents
Easier programmatic access to form/report documents
Programmatic access to forms/reports contained in database documents is easier than ever before:
ThisDatabaseDocument.FormComponents.getByName( "form name" ).open
will open the form "form name" in the very same way a double-click onto the form in the document UI would do, i.e. doing all the proper knittings to the document UI.
フォームやレポートのドキュメントへのプログラムからのより簡単なアクセス
データベースのドキュメントに含まれているフォームやレポートへのプログラムからのアクセスは、これまでになく簡単になっています。つまり、
ThisDatabaseDocument.FormComponents.getByName( "フォーム名" ).open
は、ドキュメントのUIのフォームをダブルクリックするのと全く同じ仕方で、「フォーム名」というフォームを開くことになります。すなわち、ドキュメントのUIに結びつくプログラムが、適切かつ完全にできるのです。（飯高敏和、久保田貴也 ）
New configuration setting for pre-specifying per-driver classpaths
There's a new setting in the org.openoffice.Office.DataAccess configuration module which allows to specify, on a per-driver basis, a classpath to use when searching for a JDBC driver.
An administrator of a shared OOo installation can use this setting to pre-configure the installation, without all users having the need to add the respective .JAR file to their own Java options.
The complete path of the new configuration node is
/org.openoffice.Office.DataAccess/JDBC/DriverClassPaths.
An exemplary configuration fragment:
<node oor:name="JDBC">
<node oor:name="DriverClassPaths">
<node oor:name="com.mysql.jdbc.Driver" oor:op="replace">
<prop oor:name="Path">
<value>url_to_jar_file</value>
</prop>
</node>
</node>
</node>
ドライバーごとのクラスパスを事前に明示するための新たな構成設定
org.openoffice.Office.DataAccess構成モジュールには新たな設定があります。それにより、ドライバーごとをベースに、JDBCドライバーを探す際に用いるクラスパスを明示することができます。
共有されたOOoインストールの管理者は、インストールの事前構成のためのこの設定を用いることができ、それによりユーザーは、各々の.JARファイルを、各自のJAVAオプションに加える必要がなくなります。
新たな構成のノードの完全パスは、
/org.openoffice.Office.DataAccess/JDBC/DriverClassPaths
となります。
典型的な構成を断片的に抜き出すと、以下のようになります。
<node oor:name="JDBC">
<node oor:name="DriverClassPaths">
<node oor:name="com.mysql.jdbc.Driver" oor:op="replace">
<prop oor:name="Path">
<value>url_to_jar_file</value>
</prop>
</node>
</node>
</node> （飯高敏和）
Relation design get notified when database structure changed
The relation design now detects when a new table will be added and also when new columns will be added. The "Add Table" dialog also gets notified when a new table was added.
データベース構造が変更されれば、リレーションデザインに通知されます
新しいテーブルが追加される際、そして新しい行が追加される際にもまた、目下のところではリレーションデザインが検出するようになっています。「テーブル追加」ダイアログもまた、新しいテーブルが追加された場合には、通知されます。(飯高敏和、久保田貴也)
Relation design now supports self referencing table relations
The relation design now supports the creation of relations which allows that the referencing table is also the referenced table.
リレーションデザインは現在、自己参照のテーブルリレーションをサポートしています
リレーションデザインは現在、参照しているテーブルが同時にまた参照されているテーブルであることができるようにするリレーションの作成をサポートしています。（飯高敏和）
Table
Relative path for file based databases
At the moment, when you create a file-based database (such as dBase or Spreadsheet), the URL to the files (let's call it the "data URL") is stored in an absolute manner - that is, something like "[../../../foo/bar file:///c:/foo/bar]".
ファイルベースのデータベースのための相対パス
現在は、ファイルベースのデータベース（dBaseや表計算ドキュメントのような）を作成する場合には、ファイルのURL（「データURL」と呼ぶことにしましょう）は完全な仕方、つまり「[../../../foo/bar file:///c:/foo/bar]」というような形で、保管されます。（飯高敏和）
As a result, when you move the database document (the .odb file), together with the underlying data, to another machine, you need to either duplicate the file structure on this target machine, or to adjust the settings for the database.
結果として、データベースドキュメント（.odbファイル）を、下地になっているデータと一緒に、他のマシーンに移す場合には、この移植先のマシーンにファイル構造を複製するか、データベースのための設定を調整する必要がでてきます。（飯高敏和）
Now it is possible that the path is stored relatively when the option "Save URLs relative to file system" setting in the "Tools->Options->Load/Save" dialog is checked.
現在では、「ツール->オプション->読み込み/保存」ダイアログの「ファイルシステムに関連したURLを保存」オプションをチェックすれば、パスを相対パスで保存することができるようになっています。（飯高敏和）
Table design handles primary key differently for hsqldb
This is specific for hsqldb only.
When the user adds a auto increment column this one gets automatically the primary key of the table. When the user after wards removes the primary key flag, then the autoincrement flag will also be removed.
Hsqldb only supports one auto increment column which then must also be the only primary key column.
PS: A primary key consists of more than one column which isn't the fact for hsqldb when an auto increment column is used.
Hsqldb向けには、主キーを別様に取り扱うテーブルデザインになっています
これは、hsqldbのためだけのものです。
Auto increment属性の列が追加されると、この列には自動的に、テーブルの主キー属性がつきます。その後で主キーフラグを取り除くと、auto incrementフラグも取り除かれることになります。
Hsqldb はひとつの auto increment属性の列をサポートしているだけで、しかもその列は単独の主キー属性の列でなければなりません。
PS:Auto increment属性の列が用いられている場合に、主キーが一つより多くの列からなっているということは、hsqldbではありえません。（飯高敏和、久保田貴也）
Views opened for editing are automatically put into "Run SQL Directly" mode
When you open an table view for editing its constituting SQL command (which is a feature currently supported for embedded HSQLDB only), then the query editor is automatically put into the "Run SQL command directly" mode.
編集のために開かれたビューは、自動的に「SQLを直接実行」モードにされます
ビューを構成するSQLコマンドを編集するためのビューテーブル（現在のところでは、埋め込まれたHSQLDBだけのためにサポートにされた機能です）を開けば、クエリーエディターは自動的に「SQLを直接実行」モードにされます。（飯高敏和）
Query
Parameters recognized in function argument lists
OOo's parser has the ability to recognize parameters in function argument lists. That is, a query like
SELECT CONCAT( :C, "name" ) FROM "name" will now, when executed, properly present the dialog asking the user for parameter value input.
関数の引数リストにおいて認識されるパラメーター
OOoのパーサーは、関数の引数リストにおけるパラメーターを認識することができます。それはつまり、いまやSELECT CONCAT( :C, "name" ) FROM "name"のようなクエリーが、実行されたならば、パラメーターの値の入力をユーザーに求めるダイアログを、適切に表示することになるということです。（飯高敏和）
Query design: SQL syntax extended
The SQL parser now recognize the TRIM command correctly.
It now also supports
TRIM( FROM <COLUMN_NAME> )
as an abbreviated form of
TRIM( BOTH FROM <COLUMN_NAME> )
This functions, remove leading and trailing blanks from a string.
クエリーデザイン：SQLシンタクスが広がりました
SQLパーサーは今では、TRIMコマンドを正しく認識するようになっています。
TRIM( FROM <COLUMN_NAME> )
が今では、
TRIM( BOTH FROM <COLUMN_NAME> )
の省略された形式としてサポートされています。
これらの関数は、文字列の冒頭と末尾の空白を取り除きます。（飯高敏和、久保田貴也）
SQL syntax highlighting
Added support for SQL syntax highlighting for the Base SQL view as well as Tools-SQL...
The used font for the SQL view will respect the same settings as HTML and BASIC IDE, all used colors can be configured
Specification:
http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting
SQLシンタクスハイライト
Base向の「SQLビュー」にも、「ツール-SQL…」と同様、SQLシンタクスハイライトのサポートが追加されました。
「SQLビュー」に使用されるフォントでは、HTMLとBASIC IDEと同じ設定であることが重視されることになります。そして、使用される色の全てを設定することができます。
仕様書は以下になります：
http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting（飯高敏和、久保田貴也）
Form
Form controls: new property: "Text direction"
All form controls support a new property "Text direction", which controls, well, the text direction of the control. In languages where people uses right-to-left directed text like in Arab, Hebrew, Hindi etc., forms will look strange if they need to use left-to-right layout control forms.
New property can be found on Properties, General tab below “Label field”, when CTL support enabled in language settings.
See the specification for details:
http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw
フォームコントロール：新しい属性：テキストの向き
フォームコントロールは全て、新しい属性である「テキストの向き」をサポートしています。これは、コントロールのテキストの向きをうまく制御してくれます。アラビア語やヘブライ語やヒンディー語のような、右から左へと向かうテキストを使う人々の言語では、左から右へのレイアウトの操作フォームを使う必要があるとなると、フォームの見た目が変になってしまいます。
CTLサポートが、言語設定において有効にされたならば、「ラベルフィールド」の下の一般タブの属性に、新しい属性が見つかります。
詳細については、次の仕様書を見てください。
http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw（飯高敏和）
Form controls: new property "Input Required"
All form controls which can be bound to a database column (i.e. have the "Data field" property) now have a new property called "Input required". New property can be found on Properties, Data tab, below the "Empty string is NULL"
フォームコントロール：新しい属性「入力必須」
データベースの列に接続することができる（つまり、「データフィールド」属性を持つ）フォームコントロールは今では全て、「入力必須」と呼ばれる新たな属性を持っています。新しい属性は、プロパティー、データタブ上の「空の文字列はNULL」の下にあります。（飯高敏和）
This property controls whether or not the input of this field is checked against being empty (NULL). It is evaluated for controls which are bound to a database field which is defined as required (i.e. Which is not allowed to contain the special NULL value), immediately before the current record of the form is to be written into the database.
この属性は、はそのフィールドの入力が空 (NULL) とならないようにチェックするかどうか制御します。(フォームの現在のレコードがデータベースに書き込まれる直前に、必須なものとして定義されている（つまり、特別な値であるNULL値を含むことができない）データベースのフィールドに関連するコントロールのために、この属性は評価されます。（飯高敏和、久保田貴也）
If the property is set to "Yes", and the field contains no input when the current record is to be written to the database, then an error message will be shown to the user, and the respective control will be focused afterwards. Note that this is the known behaviour so far – the property defaults to "Yes" so that newly created controls behave as they would do in previous OOo versions.
もし属性が「はい」に設定されていて、現在のレコードがデータベースに書き込まれる際にフィールドに入力がない場合には、ユーザーにエラーメッセージが表示されることになります。それぞれのコントロールは、その後でフォーカスされることになります。属性は「はい」がデフォルトになっていて、新たに作成されたコントロールは、以前のOOoのバージョンと同じように動作するということが、今のところ知られていることに注意してください。（飯高敏和）
If the property is set to "No", and the field contains no input when the current record is to be written to the database, then this is ignored. It's up to the underlying database to either reject the update, or fill the respective column with a server-side default value.
もし属性が「いいえ」に設定されていて、現在のレコードがデータベースに書き込まれる際にフィールドに入力がない場合には、これは無視されます。更新を拒絶するのか、サーバーサイドのデフォルトの値で各々の列を埋めるのかは、下地になっているデータベースによります。（飯高敏和）
If the "Form data input checks for required fields" option in the advanced settings of the database document (Edit / Database / Advanced Settings ...) is *not* checked, then the "Input required" property for all controls in all forms in this database document does not have any effect, since the document-wide setting overrules the per-control settings.
データベースドキュメントの拡張設定（編集/データベース/拡張設定）における「必須フィールドのためのフォームデータ入力チェック」がチェックされていない場合には、このデータベースドキュメントのフォームの全てで、いかなるコントロールに向けた「入力必須」属性も、ドキュメント全体をカバーする設定がコントロールごとの設定を無効にするので、何ら効果を持ちません。（飯高敏和）
If the "Data field" is not set (i.e. empty), then "Input required" is disabled, since it would be evaluated for bound controls only, anyway.
もし「データフィールド」が設定されていなければ（空であれば）、それはとにかく関連するコントロールのためだけに評価されるので、「入力必須」は無効にされます。（飯高敏和）
If the "Empty string is NULL" is set to "No", then "Input required" is also disabled, since "Empty string is NULL" being "no" implies that when the user does not enter any value in the control, then an empty string, instead of the dedicated value NULL, is written, so there's always a non-NULL value no matter the user's action.
もし「空の文字列はNULL」が「いいえ」に設定されていれば、「入力必須」もまた無効にされます。なぜなら、「空の文字列はNULL」が「いいえ」に設定されているということは、ユーザーがコントロールに何も値を入力しない場合には、専用の値であるNULLの代わりに空の文字列が書き込まれ、ユーザーがどんなことをしようが、NULLでない値が書き込まれるからです。（飯高敏和）
"Empty string is NULL" behavior refined
The behavior of form controls whose "Empty string is NULL" property is set to "Yes" has been refined. This change might make existing forms behave slightly different than before, but certainly more expectation-conformant now.
「空の文字列はNULL」の動作が改良されました
「空の文字列はNULL」属性が「はい」に設定してあるフォームコントロールの動作は改良されました。この変更は、既存のフォームに、以前とは少し異なる動作をさせるかもしれません。ですが今では、もっと直観にかなったものになっています。（飯高敏和、久保田貴也）
First, the property is now also respected when you never touched the respective control before saving the record. That is, imagine a control which has this property set to "Yes", this way declaring that if the control contains an empty string, then this should be propagated to the database as (the dedicated) NULL value.
第一に、それぞれのコントロールに触れずにレコードを保存する場合に、その属性が今はまた重要になってきます。それはつまり、この属性が「はい」に設定されているコントロールを考えてみると、このような宣言は、コントロールが空の文字列を含んでいれば、これがデータベースには（特別な値である）NULL値として伝えられるということを宣言していることになります。（飯高敏和）
Formerly, when you moved to the insertion row of the form, so the control was initially empty, entered some data into other controls of the current record, and saved the record without actually touching the first control, then it actually updated an empty string. Now, with the change, it updates NULL, as this is what "Empty String is NULL" = "Yes" requests.
ところが以前は、フォームの行挿入に移行すると、コントロールの初期値は空ですが、現在のレコードの他のコントロールにデータを入力し、もとのコントロールに実際には触れずにデータを保存すると、実際には空の文字列に更新していたのです。ですが今では、変更に伴って、NULLに更新しています。「空の文字列はNULL」＝「はい」が求めている動作とは、これなのです。（飯高敏和）
Second, when a control was bound to a database column which was declared as NOT NULL, then the control *always* updated an empty string instead of NULL, no matter what its "Empty string is NULL" property requested. Effectively, this killed server-side defaults of database fields, as such defaults are only applied when the field is NULL. Now, with the change, controls always update NULL in such a setup, this way enabling server-side defaults.
第二に、コントロールがNOT NULLとして宣言されているデータベースの列と関連している場合には、コントロールは常に、「空の文字列はNULL」が何を要求していようが、NULLの代わりに空の文字列に更新していました。事実上、これはデータベースのフィールドのサーバー側のデフォルトを無効にしてしまっていました。というのは、フィールドがNULLである場合にのみ、そのようなデフォルトが適用されるからです。今では、変更に伴って、コントロールはそのような設定ではNULLに更新するようになっています。このようにして、サーバー側のデフォルトが有効になります。（飯高敏和）
Check box: modified property
Check box columns in grid controls now have the "Tristate" property, which controls whether or not the "indetermined" state is allowed for the check box, as known from ordinary check box form controls.
チェックボックス：修正された属性
グリッドコントロールにおけるチェックボックス列は今では、「トライステート」属性を持っています。この属性は、通常のチェックボックスフォームコントロールから分かるように、チェックボックスが「未決定」の状態であることを許すかどうかを制御します。（飯高敏和）
Image controls: scaling the image by keeping the ratio
Image form controls in documents got an additional mode for scaling the image they display.
イメージコントロール：比率を保持しつつのイメージの倍率変更
ドキュメントのイメージフォームコントロールには、表示するイメージの倍率を変えるためのモードが追加されました。（飯高敏和）
Previously, you could control the scaling by setting the "Scale" property to "Yes" or "No" only, where "Yes" implied an anisotropic scaling, i.e. one which distorted the image's dimensions.
以前は、「スケール」属性を「はい」か「いいえ」に設定することでのみ、倍率を制御することができました。そこでは、「はい」というのは縦横で異なる倍率変更を意味しています。つまり、イメージの寸法を歪めてしまうことを意味しているのです。（飯高敏和、久保田貴也）
Now, the "Scale" property allows the values "No" (same as before), "Keep Ratio" and "Fit to Size" (equivalent to the old "Yes"). When "Keep Ratio" is selected, the image is still scaled up or down to match the control dimensions, but it's ratio is aspect kept constant.
現在では、「スケール」属性では、「いいえ」（以前と同じ機能）と「比率を保持」と「サイズに合わせる」（昔の「はい」と同じ）が許容されています。「比率を保持」が選択されると、イメージはなおもコントロールの寸法にマッチするように拡大もしくは縮小されますが、その比率は一定に保たれた概観になっています。（飯高敏和）
This is especially useful for controls where the designer of the document does not know, at time of designing the document/control, the dimensions of the to-be-displayed images. In particular, this is useful for image controls in database forms, displaying images obtained from the database.
ドキュメントのデザイナーがドキュメントやコントロールをデザインする時点では、表示されるイメージの大きさが分からないコントロールに対して特に有用です。。特にこれは、データベースから得られたイメージを表示するデータベースにおけるイメージコントロールに対して有用です。 （飯高敏和、久保田貴也）
Image controls: support for document-embedded images
Image controls can now be bound to images which are embedded in the document where the control lives in.
イメージコントロール：ドキュメントに埋め込まれたイメージのサポート
イメージコントロールを今では、コントロールが有効になっているドキュメントが埋め込まれたイメージに関連付けることができます。（飯高敏和）
More precise, when you select an image to be displayed at an image control, the "Link" option in the file picker is not disabled anymore.
もっと正確に述べると、イメージコントロールに表示されるイメージを選択すると、ファイルピッカーにおける「リンク」オプションは、もはや無効にはなっていません。（飯高敏和）
When you uncheck the option (the default is "checked", to mimic the legacy behavior), then the image is displayed in the control, and upon saving the document, it's embedded in the document itself.
オプションのチェックをはずせば（従来のバージョンをまねて、デフォルトではチェックが入っています）、イメージがコントロールに表示され、ドキュメントを保存するに際しては、イメージはドキュメントそのものに埋め込まれます。（飯高敏和）
This way, you can create documents with image controls which are exchangeable with other people/installations/platforms, which formerly was much more difficult due to the need to also copy the images, and place them in exactly the same location as on the originating machine (which often is simply impossible).
このようにして、他の人や他のインストールや他のプラットフォームと交換できるイメージコントロールをそなえたドキュメントを作成することができるのです。こういうことは以前は、イメージをコピーする必要もまたあったために、はるかに難しい作業でした。また、そのドキュメントを、もとのマシーンの中で置いてあった場所と全く同じ場所に置くことができるのです（こういうことは多くの場合、単に不可能なのですが）。 （飯高敏和）
Image controls: can be bound to text database columns, interpreting their content as relative link to the image
Image controls in database forms can now be bound to text columns. Formerly, you could only bind them to columns whose content could reasonably be interpreted as binary (BLOB etc.). Now, when you select a text database column as source for the image control, then it will interpret the content of the respective column's content as URL, and load and display the image pointed to by this URL. Also, the URL might be relative to the document which the image control is embedded into.
イメージコントロール：テキスト型のデータベースの列と関連付け、そのコンテンツをイメージへの相対リンクとして解釈することができます
データベースフォームのイメージコントロールを、テキスト型の列に関連付けることができます。以前は、イメージコントロールと関連付けることができるのは、バイナリーと合理的に解釈できる（BLOB型など）コンテンツを有する列だけでした。今では、テキスト型のデータベースの列をイメージコントロールのソースとして選択すると、それぞれの列のコンテンツはURLとして解釈され、このURLによって指し示されているイメージを読み込んで表示します。また、イメージコントロールの埋め込まれているドキュメントに相対的なURLも許可されています。（飯高敏和）
In the Form Navigation Toolbar (the one used as soon as you have an alive form filled from a database), there's a new item, called "Refresh Control", located right after the "Refresh" item.
This new item is enabled if and only if a list or combo box control has the focus. When pressed, the item list of the control is refreshed.
This is particular interesting for lists based on the content of a table (or query) of the database, when some instance outside the form did changes to this table/query's data. In this case, you can reflect those changes in the control's item list by using the "Refresh Control" function.
ナビゲーションツールバー：新しいアイテム「コントロールを更新」
フォームのナビゲーションツールバー（これはデータベースから得られたデータで埋められた活動中のフォームを持つとすぐに使われるものです）には、「コントロールを更新」と呼ばれ、「更新」アイテムのすぐ後に位置する新しいアイテムがあります。
この新しいアイテムが有効になるのは、唯一リストかコンボボックスコントロールにフォーカスが当てられている場合のみです。それが押されると、コントロールのアイテムリストは更新されます。
フォームの外部にあるインスタンスのいくつかが、テーブル/クエリーのデータを変化させる際に、データベースのテーブル（もしくはクエリー）のコンテンツに基づいたリストにとっては、これは特に面白いものになります。この場合には、「コントロールを更新」の機能を使うことで、これらの変化をコントロールのアイテムリストに反映させることができます。（飯高敏和）
Report
New short cuts for Sun Report Builder
The Edit menu now contains a "Select All" entry.
Which contains:
Edit>Select All -> Select All (CTRL+A)
Select all Labels
Select all Formatted Fields
Select Report
Automatic binding of first table when opening a new Report
When creating a new report in a database, the report will be bound to the first table from the database. Additionally the Add Field dialog will open with all available fields.
Report output format now also available in the property browser
The property browser now shows the selected output format for a report on the Data page, last item under Filter, when it is selected in the SRB.
Currently available formats are:
- ODF Text Document
- ODF Spreadsheet
Add Field dialog supports sorting and insert toolbar
The Add Field dialog now has a toolbar above the listbox for the fields. The toolbar allows to sort the fields ascending and descending as well to remove the sort order and restore origin order from the source (table,query). Additional the toolbar contains an "Insert" entry which allows to insert the selected fields into a report section. Multi selection of fields is also supported.
Function Autopilot from inside the SRB
The Function Autopilot which is used in the spreadsheet can now be used inside the Sun Report Builder.
The Autopilot can be started from:
- the data field ( formatted field and image control)
- the conditional print expression, on general tab.
- the formula
- the initial value
The Autopilot shows all functions which are supported by the report engine.
The documentation for the SRB can be found here:
http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation
The functions description can be found here:
http://wiki.services.openoffice.org/wiki/Base/Reports/Functions
