JA/translation/Base/New features in 3 1

From Apache OpenOffice Wiki
< JA‎ | translation
Revision as of 12:25, 2 March 2009 by Toshibo (Talk | contribs)

Jump to: navigation, search

このページは、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:

ユーザーがこのメニューの項目を選択すると、ウィザードがマイグレーションを通じてユーザーをガイドすることになり、それは効率的に次のような四つの段階からなっています。(飯高敏和)

  1. close all sub components of the database document, namely forms, reports, and any open designers
  2. backup the database document
  3. migrate the scripts and macros while displaying a progress bar
  4. show a summary

For a detailed description of the feature, you're encouraged to read the specification:

  1. データベースドキュメントの全てのサブコンポーネント、つまりフォームとレポート、そして開いているどのデザイナーも閉じられます。
  2. データベースドキュメントがバックアップされます。
  3. 進捗状況バーが表示されている間は、スクリプトとマクロがマイグレーションされます。
  4. 概要が表示されます。

機能の詳細にわたる説明については、次の仕様書を読むことが推奨されています。(飯高敏和)

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"


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.


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.


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.

"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.


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.

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.


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.

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.


Navigation Toolbar: new item "Refresh Control"

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.


http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation#Report_Navigator_-.3E_Report_-.3E_Functions_-.3E_Function_-.3E_Properties_of_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

Personal tools