Difference between revisions of "JA/translation/Base/New features in 3 1"

From Apache OpenOffice Wiki
Jump to: navigation, search
 
(39 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
このページは、[http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1 http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1]の日本語訳を行うページです。
+
[[en:Base/New_features_in_3_1]]
 +
[[fr:FR/Documentation/Base/Nouvelles_Fonctions_3_1]]
 +
このページは、[http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1 http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1]の日本語訳です。
  
−
現在の進捗段階は以下のとおりです。
+
翻訳：飯高敏和、査読：久保田貴也
  
−
STEP1（本文コピー） →　STEP2（文書調整） →　STEP3（アカウント作成） →　STEP4（既存翻訳の移動） →　'''STEP5（翻訳）''' →　STEP6（最終調整）
+
=Ooo 3.1におけるデータベースの新機能=
−
= New database features in OOo 3.1 =
 
−
Compiled from features dba openoffice org mailing list mails, and referenced specifications.
 
  
−
= Base General =
+
dba openoffice orgのメーリングリストと参照された仕様書に載っている機能から、編集しました。
−
== 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.
 
  
−
'''データベースドキュメントのマクロ'''
+
= Base全般 =
 +
== データベースドキュメントのマクロ ==
  
−
データベースドキュメント（.odb）は現在、他の種類のOOoドキュメントが既にそうしているのと全く同じやり方で、マクロとスクリプトを埋め込んでいます。（飯高敏和）
+
データベースドキュメント（.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より前のバージョンで作成されたデータベースドキュメントは、マクロやスクリプトの
 
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
+
新しいメニューの項目を導入し、名前を「マクロのマイグレーション・・・」とし、最上位のメニュー「ツール」の既存の項目である「SQL・・・」のすぐ下におきます。
−
# 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:
+
ユーザーがこのメニューの項目を選択すると、ウィザードがマイグレーションを通じてユーザーをガイドすることになり、それは効率的に次のような四つの段階からなっています。
  
 
# データベースドキュメントの全てのサブコンポーネント、つまりフォームとレポート、そして開いているどのデザイナーも閉じられます。
 
# データベースドキュメントの全てのサブコンポーネント、つまりフォームとレポート、そして開いているどのデザイナーも閉じられます。
Line 67: Line 41:
 
# 概要が表示されます。
 
# 概要が表示されます。
  
−
機能の詳細にわたる説明については、次の仕様書を読むことが推奨されています。（飯高敏和）
+
機能の詳細にわたる説明については、次の仕様書を読むことが推奨されています。
  
 
[http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents]
 
[http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents 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.
 
−
 
 
−
'''フォームやレポートのドキュメントへのプログラムからのより簡単なアクセス'''
 
  
 
データベースのドキュメントに含まれているフォームやレポートへのプログラムからのアクセスは、これまでになく簡単になっています。つまり、
 
データベースのドキュメントに含まれているフォームやレポートへのプログラムからのアクセスは、これまでになく簡単になっています。つまり、
Line 84: Line 51:
 
ThisDatabaseDocument.FormComponents.getByName( "フォーム名" ).open
 
ThisDatabaseDocument.FormComponents.getByName( "フォーム名" ).open
  
−
は、ドキュメントのUIのフォームをダブルクリックするのと全く同じ仕方で、「フォーム名」というフォームを開くことになります。すなわち、ドキュメントのUIに結びつくプログラムが、適切かつ完全にできるのです。（飯高敏和、久保田貴也
+
は、ドキュメントの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:
 
−
 
 
−
<nowiki><node oor:name="JDBC"></nowiki>
 
−
 
 
−
<nowiki><node oor:name="DriverClassPaths"></nowiki>
 
−
 
 
−
<nowiki><node oor:name="com.mysql.jdbc.Driver" oor:op="replace"></nowiki>
 
−
 
 
−
<nowiki><prop oor:name="Path"></nowiki>
 
−
 
 
−
<nowiki><value>url_to_jar_file</value></nowiki>
 
−
 
 
−
<nowiki></prop></nowiki>
 
−
 
 
−
<nowiki></node></nowiki>
 
−
 
 
−
<nowiki></node></nowiki>
 
−
 
 
−
<nowiki></node></nowiki>
 
  
−
'''ドライバーごとのクラスパスを事前に明示するための新たな構成設定'''
+
==ドライバーごとのクラスパスを事前に明示するための新たな構成設定==
  
 
org.openoffice.Office.DataAccess構成モジュールには新たな設定があります。それにより、ドライバーごとをベースに、JDBCドライバーを探す際に用いるクラスパスを明示することができます。
 
org.openoffice.Office.DataAccess構成モジュールには新たな設定があります。それにより、ドライバーごとをベースに、JDBCドライバーを探す際に用いるクラスパスを明示することができます。
Line 149: Line 84:
  
 
<nowiki></node></nowiki>
 
<nowiki></node></nowiki>
−
（飯高敏和）
 
−
 
−
== 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.
+
ファイルベースのデータベース(dBase や表計算ドキュメントのようなもの)を作成するまさにその際には、そのファイルに対応する URL (「data URL」と呼ぶことにしましょう) は絶対パス(つまり"file:///c:/foo/bar" のような形式)で格納されます。
  
−
Hsqldb only supports one auto increment column which then must also be the only primary key column.  
+
結果として、そのデータベースドキュメント(.odb ファイル) を、配下にあるデータといっしょに、他のマシンに移す場合には、移動先のマシン上に同じファイル構造を複製するか 、データベースの設定を調整する必要がでてきます。
  
−
PS: A primary key consists of more than one column which isn't the fact for hsqldb when an auto increment column is used.
+
現在では「ツール -> オプション ->読み込み / 保存」ダイアログにあるオプション "ファイルシステムに対して相対的な URL で保存" をチェックすると、(data URL の) パスを相対パスで格納することができるようになっています。
  
−
 
+
== Hsqldb向けには、主キーを別様に取り扱うテーブルデザインになっています ==
−
'''Hsqldb向けには、主キーを別様に取り扱うテーブルデザインになっています'''
 
  
 
これは、hsqldbのためだけのものです。
 
これは、hsqldbのためだけのものです。
Line 199: Line 111:
 
Hsqldb はひとつの auto increment属性の列をサポートしているだけで、しかもその列は単独の主キー属性の列でなければなりません。
 
Hsqldb はひとつの auto increment属性の列をサポートしているだけで、しかもその列は単独の主キー属性の列でなければなりません。
  
−
PS:Auto increment属性の列が用いられている場合に、主キーが一つより多くの列からなっているということは、hsqldbではありえません。（飯高敏和、久保田貴也）
+
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
+
== 編集のために開かれたビューは、自動的に「SQLを直接実行」モードにされます ==
−
 
 
−
<nowiki>TRIM( FROM <COLUMN_NAME> ) </nowiki>
 
  
−
as an abbreviated form of
+
ビューを構成するSQLコマンドを編集するためのビューテーブル（現在のところでは、埋め込まれたHSQLDBだけのためにサポートにされた機能です）を開けば、クエリーエディターは自動的に「SQLを直接実行」モードにされます。
  
−
<nowiki>TRIM( BOTH FROM <COLUMN_NAME> )</nowiki>
+
= クエリー =
 +
== 関数の引数リストにおいて認識されるパラメーター ==
  
−
This functions, remove leading and trailing blanks from a string.
+
OOoのパーサーは、関数の引数リストにおけるパラメーターを認識することができます。それはつまり、いまやSELECT CONCAT( :C, "name" ) FROM "name"のようなクエリーが、実行されたならば、パラメーターの値の入力をユーザーに求めるダイアログを、適切に表示することになるということです。
  
−
'''クエリーデザイン：SQLシンタクスが広がりました'''
+
== クエリーデザイン：SQLシンタクスが広がりました ==
  
 
SQLパーサーは今では、TRIMコマンドを正しく認識するようになっています。
 
SQLパーサーは今では、TRIMコマンドを正しく認識するようになっています。
Line 243: Line 134:
 
の省略された形式としてサポートされています。
 
の省略された形式としてサポートされています。
  
−
この関数は、文字列の冒頭と末尾の空白を取り除きます。（飯高敏和）
+
これらの関数は、文字列の冒頭と末尾の空白を取り除きます。
−
 
 
−
== 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 http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting]
 
  
−
'''SQLシンタクスの強調表示'''
+
== SQLシンタクスハイライト ==
  
−
Base向けには、「ツール-SQL…」と同様に「SQLビュー」にも、SQLシンタクスの強調表示のサポートが追加されました。
+
Base向の「SQLビュー」にも、「ツール-SQL…」と同様、SQLシンタクスハイライトのサポートが追加されました。
  
 
「SQLビュー」に使用されるフォントでは、HTMLとBASIC IDEと同じ設定であることが重視されることになります。そして、使用される色の全てを設定することができます。
 
「SQLビュー」に使用されるフォントでは、HTMLとBASIC IDEと同じ設定であることが重視されることになります。そして、使用される色の全てを設定することができます。
Line 262: Line 144:
 
仕様書は以下になります：
 
仕様書は以下になります：
  
−
[http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting]（飯高敏和）
+
[http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting 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 http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw]
 
  
−
'''フォームコントロール：新しい属性：テキストの向き'''
+
= フォーム =
 +
== フォームコントロール：新しい属性：テキストの向き ==
  
 
フォームコントロールは全て、新しい属性である「テキストの向き」をサポートしています。これは、コントロールのテキストの向きをうまく制御してくれます。アラビア語やヘブライ語やヒンディー語のような、右から左へと向かうテキストを使う人々の言語では、左から右へのレイアウトの操作フォームを使う必要があるとなると、フォームの見た目が変になってしまいます。
 
フォームコントロールは全て、新しい属性である「テキストの向き」をサポートしています。これは、コントロールのテキストの向きをうまく制御してくれます。アラビア語やヘブライ語やヒンディー語のような、右から左へと向かうテキストを使う人々の言語では、左から右へのレイアウトの操作フォームを使う必要があるとなると、フォームの見た目が変になってしまいます。
Line 283: Line 155:
 
詳細については、次の仕様書を見てください。
 
詳細については、次の仕様書を見てください。
  
−
[http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw]（飯高敏和）
+
[http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw 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.
 
  
−
'''チェックボックス：修正された属性'''
+
データベースの列に接続することができる（つまり、「データフィールド」属性を持つ）フォームコントロールは今では全て、「入力必須」と呼ばれる新たな属性を持っています。新しい属性は、プロパティー、データタブ上の「空の文字列はNULL」の下にあります。
  
−
グリッドコントロールにおけるチェックボックス列は今では、「トライステート」属性を持っています。この属性は、通常のチェックボックスフォームコントロールから分かるように、チェックボックスが「未決定」の状態であることを許すかどうかを制御します。（飯高敏和）
+
この属性は、はそのフィールドの入力が空 (NULL) とならないようにチェックするかどうか制御します。(フォームの現在のレコードがデータベースに書き込まれる直前に、必須なものとして定義されている（つまり、特別な値であるNULL値を含むことができない）データベースのフィールドに関連するコントロールのために、この属性は評価されます。
  
−
== Image controls: scaling the image by keeping the ratio ==
+
もし属性が「はい」に設定されていて、現在のレコードがデータベースに書き込まれる際にフィールドに入力がない場合には、ユーザーにエラーメッセージが表示されることになります。それぞれのコントロールは、その後でフォーカスされることになります。属性は「はい」がデフォルトになっていて、新たに作成されたコントロールは、以前のOOoのバージョンと同じように動作するということが、今のところ知られていることに注意してください。
−
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.
+
もし「データフィールド」が設定されていなければ（空であれば）、それはとにかく関連するコントロールのためだけに評価されるので、「入力必須」は無効にされます。
  
−
以前は、「スケール」属性を「はい」か「いいえ」に設定することでのみ、倍率を制御することができました。そこでは、「はい」というのは異方性の倍率変更を意味しています。つまり、イメージの寸法を歪めてしまうことを意味しているのです。（飯高敏和）
+
もし「空の文字列はNULL」が「いいえ」に設定されていれば、「入力必須」もまた無効にされます。なぜなら、「空の文字列はNULL」が「いいえ」に設定されているということは、ユーザーがコントロールに何も値を入力しない場合には、専用の値であるNULLの代わりに空の文字列が書き込まれ、ユーザーがどんなことをしようが、NULLでない値が書き込まれるからです。
  
−
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.
+
== 「空の文字列はNULL」の動作が改良されました ==
  
−
現在では、「スケール」属性では、「いいえ」（以前と同じ機能）と「比率を保持」と「サイズに合わせる」（昔の「はい」と同じ）が許容されています。「比率を保持」が選択されると、イメージはなおもコントロールの寸法にマッチするように拡大もしくは縮小されますが、その比率は一定に保たれた角度になっています。（飯高敏和）
+
「空の文字列はNULL」属性が「はい」に設定してあるフォームコントロールの動作は改良されました。この変更は、既存のフォームに、以前とは少し異なる動作をさせるかもしれません。ですが今では、もっと直観にかなったものになっています。
  
−
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.
+
第一に、それぞれのコントロールに触れずにレコードを保存する場合に、その属性が今はまた重要になってきます。それはつまり、この属性が「はい」に設定されているコントロールを考えてみると、このような宣言は、コントロールが空の文字列を含んでいれば、これがデータベースには（特別な値である）NULL値として伝えられるということを宣言していることになります。
  
−
これが特別に有用であるのは、ドキュメントのデザイナーが、ドキュメントやコントロールのデザインをする際に、表示されるべきイメージの寸法を知らないような場合のコントロールに対してです。特にこれは、データベースから得られたイメージを表示するデータベースにおけるイメージコントロールに対して有用です。
+
ところが以前は、フォームの行挿入に移行すると、コントロールの初期値は空ですが、現在のレコードの他のコントロールにデータを入力し、もとのコントロールに実際には触れずにデータを保存すると、実際には空の文字列に更新していたのです。ですが今では、変更に伴って、NULLに更新しています。「空の文字列はNULL」＝「はい」が求めている動作とは、これなのです。
−
（飯高敏和）
 
  
−
== Image controls: support for document-embedded images ==
+
第二に、コントロールがNOT NULLとして宣言されているデータベースの列と関連している場合には、コントロールは''常に''、「空の文字列はNULL」が何を要求していようが、NULLの代わりに空の文字列に更新していました。事実上、これはデータベースのフィールドのサーバー側のデフォルトを無効にしてしまっていました。というのは、フィールドがNULLである場合にのみ、そのようなデフォルトが適用されるからです。今では、変更に伴って、コントロールはそのような設定ではNULLに更新するようになっています。このようにして、サーバー側のデフォルトが有効になります。
−
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も許可されています。（飯高敏和）
+
オプションのチェックをはずせば（従来のバージョンをまねて、デフォルトではチェックが入っています）、イメージがコントロールに表示され、ドキュメントを保存するに際しては、イメージはドキュメントそのものに埋め込まれます。
  
−
== 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.
+
データベースフォームのイメージコントロールを、テキスト型の列に関連付けることができます。以前は、イメージコントロールと関連付けることができるのは、バイナリーと合理的に解釈できる（BLOB型など）コンテンツを有する列だけでした。今では、テキスト型のデータベースの列をイメージコントロールのソースとして選択すると、それぞれの列のコンテンツはURLとして解釈され、このURLによって指し示されているイメージを読み込んで表示します。また、イメージコントロールの埋め込まれているドキュメントに相対的なURLも許可されています。
  
 +
== ナビゲーションツールバー：新しいアイテム「コントロールを更新」==
  
−
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.
+
フォームのナビゲーションツールバー（これはデータベースから得られたデータで埋められた活動中のフォームを持つとすぐに使われるものです）には、「コントロールを更新」と呼ばれ、「更新」アイテムのすぐ後に位置する新しいアイテムがあります。
  
 +
この新しいアイテムが有効になるのは、唯一リストかコンボボックスコントロールにフォーカスがある場合のみです。押されると、コントロールのアイテムリストは更新されます。
  
 +
フォームの外部のあるインスタンスが、テーブル/クエリーのデータを変更すると、データベースのテーブル（もしくはクエリー）のコンテンツに基づいたリストにとっては、これは特に面白いものになります。この場合には、「コントロールを更新」の機能を使うことで、これらの変更をコントロールのアイテムリストに反映させることができます。
  
 +
= レポート =
 +
== Sun Report Builderに向けた新たなショートカット ==
  
−
= 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)
+
編集->全て選択->全て選択(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:
+
プロパティブラウザは現在では、SRBにおいて選択される際には、フィルターの下の最後の項目である、データページ上のレポート向けに選択された出力フォーマットを表示します。
  
−
- ODF Text Document
+
現在のところ利用可能なフォーマットは以下になります。
  
−
- ODF Spreadsheet
+
-ODFテキストドキュメント
  
 +
-ODFスプレッドシート
  
−
== 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 ==
+
== SRB内部からの関数ウィザード ==
−
The Function Autopilot which is used in the spreadsheet can now be used inside the Sun Report Builder.
 
  
 +
スプレッドシートで使用される関数を現在、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 http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation#Report_Navigator_-.3E_Report_-.3E_Functions_-.3E_Function_-.3E_Properties_of_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:
+
SRC向けのドキュメントは、以下で見つかります。
  
 
[http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation]
 
[http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation 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 http://wiki.services.openoffice.org/wiki/Base/Reports/Functions]
 
[http://wiki.services.openoffice.org/wiki/Base/Reports/Functions http://wiki.services.openoffice.org/wiki/Base/Reports/Functions]
 +
[[Category:Japanese Native Language Project]]

Latest revision as of 05:47, 9 November 2009

このページは、http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1の日本語訳です。

翻訳：飯高敏和、査読：久保田貴也

Ooo 3.1におけるデータベースの新機能

dba openoffice orgのメーリングリストと参照された仕様書に載っている機能から、編集しました。

Base全般

データベースドキュメントのマクロ

データベースドキュメント（.odb）は現在、他の種類のOOoドキュメントが既にそうしているのと全く同じやり方で、マクロとスクリプトを埋め込んでいます。

これまでのところでは、マクロはデータベースドキュメントの複数のサブドキュメントに埋め込むことができます。つまり、フォームとレポート（技術的なことを述べると、これらはテキスト形式の複数のドキュメントです）に埋め込むことができます。しかしそれは、データベースドキュメント一箇所に変わることになります。

これが意味するのは、マクロが全てフォームからデータベースの主要部分に移動したということであり、フォームドキュメントの要素へのマクロの割り当てが、フォームドキュメントのマクロではなく、データベースドキュメントのマクロつきで可能になることなのです。ドキュメントそのものからも、フォーム、レポート、テーブルデザイン、クエリーデザイン、リレーションデザイン、テーブルデータビューなどのドキュメントの任意のサブコンポーネントからも、マクロを実行することができます。任意のサブコンポーネントのツールバーやメニューのなかにマクロをカスタマイズすることができます。マクロをフォームかレポートに記録するとき、マクロの格納先をたずねる最終ダイアログは、データベースドキュメントをのぞき、もはやフォームやレポートはリストに表示しません。

マイグレーション

OpenOffice.org 3.1より前のバージョンで作成されたデータベースドキュメントは、マクロやスクリプトの 埋め込まれたフォームやレポートを含んでいるかもしれません。これが禁じられているために、マイグレーション手続きが不可欠になっています。

全てのマクロとスクリプトがデータベース・ドキュメントの中にあるようにするために、ドキュメントを改変するのが目標なのですが、これを自動的にすることはできません。

互換性警告

ユーザーがサブドキュメントの中にマクロかスクリプト (もしくは両方) を含んでいる「古い」ドキュメントを単純に開いてしまうと、最初にそのファイルを開いた際に互換性警告ボックスがでる他はなにもありません。ユーザーがマクロを マイグレーションするまでは、データベースドキュメントと全てのサブドキュメントは、あたかもこの仕様書が問題にしている機能を実装していないかのように動作するでしょう。特に、フォームやレポートの既存マクロを変更したり、またはあらたに追加したり、サブドキュメントのマクロをツールバーやメニューにカスタマイズしたり、サブドキュメントのなかでこれらのマクロをイベントとバインドしたり、などなど自由にできてしまいます。

マイグレーション　ウィザード

新しいメニューの項目を導入し、名前を「マクロのマイグレーション・・・」とし、最上位のメニュー「ツール」の既存の項目である「SQL・・・」のすぐ下におきます。

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

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

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

http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents

フォームやレポートのドキュメントへのプログラムからのより簡単なアクセス

データベースのドキュメントに含まれているフォームやレポートへのプログラムからのアクセスは、これまでになく簡単になっています。つまり、

ThisDatabaseDocument.FormComponents.getByName( "フォーム名" ).open

は、ドキュメントのUIのフォームをダブルクリックするのと全く同じ仕方で、「フォーム名」というフォームを開くことになります。すなわち、ドキュメントのUIに結びつくプログラムが、適切かつ完全にできるのです。

ドライバーごとのクラスパスを事前に明示するための新たな構成設定

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>

データベース構造が変更されれば、リレーションデザインに通知されます

新しいテーブルが追加される際、そして新しい行が追加される際にもまた、目下のところではリレーションデザインが検出するようになっています。「テーブル追加」ダイアログもまた、新しいテーブルが追加された場合には、通知されます。

リレーションデザインは現在、自己参照のテーブルリレーションをサポートしています

リレーションデザインは現在、参照しているテーブルが同時にまた参照されているテーブルであることができるようにするリレーションの作成をサポートしています。

テーブル

ファイルベースのデータベースのための相対パス

ファイルベースのデータベース(dBase や表計算ドキュメントのようなもの)を作成するまさにその際には、そのファイルに対応する URL (「data URL」と呼ぶことにしましょう) は絶対パス(つまり"file:///c:/foo/bar" のような形式)で格納されます。

結果として、そのデータベースドキュメント(.odb ファイル) を、配下にあるデータといっしょに、他のマシンに移す場合には、移動先のマシン上に同じファイル構造を複製するか 、データベースの設定を調整する必要がでてきます。

現在では「ツール -> オプション ->読み込み / 保存」ダイアログにあるオプション "ファイルシステムに対して相対的な URL で保存" をチェックすると、(data URL の) パスを相対パスで格納することができるようになっています。

Hsqldb向けには、主キーを別様に取り扱うテーブルデザインになっています

これは、hsqldbのためだけのものです。

Auto increment属性の列が追加されると、この列には自動的に、テーブルの主キー属性がつきます。その後で主キーフラグを取り除くと、auto incrementフラグも取り除かれることになります。

Hsqldb はひとつの auto increment属性の列をサポートしているだけで、しかもその列は単独の主キー属性の列でなければなりません。

PS:Auto increment属性の列が用いられている場合に、主キーが一つより多くの列からなっているということは、hsqldbではありえません。

編集のために開かれたビューは、自動的に「SQLを直接実行」モードにされます

ビューを構成するSQLコマンドを編集するためのビューテーブル（現在のところでは、埋め込まれたHSQLDBだけのためにサポートにされた機能です）を開けば、クエリーエディターは自動的に「SQLを直接実行」モードにされます。

クエリー

関数の引数リストにおいて認識されるパラメーター

OOoのパーサーは、関数の引数リストにおけるパラメーターを認識することができます。それはつまり、いまやSELECT CONCAT( :C, "name" ) FROM "name"のようなクエリーが、実行されたならば、パラメーターの値の入力をユーザーに求めるダイアログを、適切に表示することになるということです。

クエリーデザイン：SQLシンタクスが広がりました

SQLパーサーは今では、TRIMコマンドを正しく認識するようになっています。

TRIM( FROM <COLUMN_NAME> )

が今では、

TRIM( BOTH FROM <COLUMN_NAME> )

の省略された形式としてサポートされています。

これらの関数は、文字列の冒頭と末尾の空白を取り除きます。

SQLシンタクスハイライト

Base向の「SQLビュー」にも、「ツール-SQL…」と同様、SQLシンタクスハイライトのサポートが追加されました。

「SQLビュー」に使用されるフォントでは、HTMLとBASIC IDEと同じ設定であることが重視されることになります。そして、使用される色の全てを設定することができます。

仕様書は以下になります：

http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting

フォーム

フォームコントロール：新しい属性：テキストの向き

フォームコントロールは全て、新しい属性である「テキストの向き」をサポートしています。これは、コントロールのテキストの向きをうまく制御してくれます。アラビア語やヘブライ語やヒンディー語のような、右から左へと向かうテキストを使う人々の言語では、左から右へのレイアウトの操作フォームを使う必要があるとなると、フォームの見た目が変になってしまいます。

CTLサポートが、言語設定において有効にされたならば、「ラベルフィールド」の下の一般タブの属性に、新しい属性が見つかります。

詳細については、次の仕様書を見てください。

http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw

フォームコントロール：新しい属性「入力必須」

データベースの列に接続することができる（つまり、「データフィールド」属性を持つ）フォームコントロールは今では全て、「入力必須」と呼ばれる新たな属性を持っています。新しい属性は、プロパティー、データタブ上の「空の文字列はNULL」の下にあります。

この属性は、はそのフィールドの入力が空 (NULL) とならないようにチェックするかどうか制御します。(フォームの現在のレコードがデータベースに書き込まれる直前に、必須なものとして定義されている（つまり、特別な値であるNULL値を含むことができない）データベースのフィールドに関連するコントロールのために、この属性は評価されます。

もし属性が「はい」に設定されていて、現在のレコードがデータベースに書き込まれる際にフィールドに入力がない場合には、ユーザーにエラーメッセージが表示されることになります。それぞれのコントロールは、その後でフォーカスされることになります。属性は「はい」がデフォルトになっていて、新たに作成されたコントロールは、以前のOOoのバージョンと同じように動作するということが、今のところ知られていることに注意してください。

もし属性が「いいえ」に設定されていて、現在のレコードがデータベースに書き込まれる際にフィールドに入力がない場合には、これは無視されます。更新を拒絶するのか、サーバーサイドのデフォルトの値で各々の列を埋めるのかは、下地になっているデータベースによります。

データベースドキュメントの拡張設定（編集/データベース/拡張設定）における「必須フィールドのためのフォームデータ入力チェック」がチェックされていない場合には、このデータベースドキュメントのフォームの全てで、いかなるコントロールに向けた「入力必須」属性も、ドキュメント全体をカバーする設定がコントロールごとの設定を無効にするので、何ら効果を持ちません。

もし「データフィールド」が設定されていなければ（空であれば）、それはとにかく関連するコントロールのためだけに評価されるので、「入力必須」は無効にされます。

もし「空の文字列はNULL」が「いいえ」に設定されていれば、「入力必須」もまた無効にされます。なぜなら、「空の文字列はNULL」が「いいえ」に設定されているということは、ユーザーがコントロールに何も値を入力しない場合には、専用の値であるNULLの代わりに空の文字列が書き込まれ、ユーザーがどんなことをしようが、NULLでない値が書き込まれるからです。

「空の文字列はNULL」の動作が改良されました

「空の文字列はNULL」属性が「はい」に設定してあるフォームコントロールの動作は改良されました。この変更は、既存のフォームに、以前とは少し異なる動作をさせるかもしれません。ですが今では、もっと直観にかなったものになっています。

第一に、それぞれのコントロールに触れずにレコードを保存する場合に、その属性が今はまた重要になってきます。それはつまり、この属性が「はい」に設定されているコントロールを考えてみると、このような宣言は、コントロールが空の文字列を含んでいれば、これがデータベースには（特別な値である）NULL値として伝えられるということを宣言していることになります。

ところが以前は、フォームの行挿入に移行すると、コントロールの初期値は空ですが、現在のレコードの他のコントロールにデータを入力し、もとのコントロールに実際には触れずにデータを保存すると、実際には空の文字列に更新していたのです。ですが今では、変更に伴って、NULLに更新しています。「空の文字列はNULL」＝「はい」が求めている動作とは、これなのです。

第二に、コントロールがNOT NULLとして宣言されているデータベースの列と関連している場合には、コントロールは常に、「空の文字列はNULL」が何を要求していようが、NULLの代わりに空の文字列に更新していました。事実上、これはデータベースのフィールドのサーバー側のデフォルトを無効にしてしまっていました。というのは、フィールドがNULLである場合にのみ、そのようなデフォルトが適用されるからです。今では、変更に伴って、コントロールはそのような設定ではNULLに更新するようになっています。このようにして、サーバー側のデフォルトが有効になります。

チェックボックス：修正された属性

グリッドコントロールにおけるチェックボックス列は今では、「トライステート」属性を持っています。この属性は、通常のチェックボックスフォームコントロールから分かるように、チェックボックスが「未決定」の状態であることを許すかどうかを制御します。

イメージコントロール：比率を保持しつつのイメージの倍率変更

ドキュメントのイメージフォームコントロールには、表示するイメージの倍率を変えるためのモードが追加されました。

以前は、「スケール」属性を「はい」か「いいえ」に設定することでのみ、倍率を制御することができました。そこでは、「はい」というのは縦横で異なる倍率変更を意味しています。つまり、イメージの寸法を歪めてしまうことを意味しているのです。

現在では、「スケール」属性では、「いいえ」（以前と同じ機能）と「比率を保持」と「サイズに合わせる」（昔の「はい」と同じ）が許容されています。「比率を保持」が選択されると、イメージはなおもコントロールの寸法にマッチするように拡大もしくは縮小されますが、その比率は一定に保たれた概観になっています。

ドキュメントのデザイナーがドキュメントやコントロールをデザインする時点では、表示されるイメージの大きさが分からないコントロールに対して特に有用です。。特にこれは、データベースから得られたイメージを表示するデータベースにおけるイメージコントロールに対して有用です。

イメージコントロール：ドキュメントに埋め込まれたイメージのサポート

イメージコントロールを今では、コントロールが置いてあるドキュメントに埋め込まれたイメージに関連付けることができます。

もっと正確に述べると、イメージコントロールに表示されるイメージを選択すると、ファイルピッカーにおける「リンク」オプションは、もはや無効にはなっていません。

オプションのチェックをはずせば（従来のバージョンをまねて、デフォルトではチェックが入っています）、イメージがコントロールに表示され、ドキュメントを保存するに際しては、イメージはドキュメントそのものに埋め込まれます。

このようにして、他の人や他のインストールや他のプラットフォームと交換できるイメージコントロールをそなえたドキュメントを作成することができるのです。こういうことは以前は、イメージをコピーしたり、そのイメージをもとのマシーンとまったく同じように配置したりする (これはあきらかに無理なときがしばしばある)必要があるため、はるかに困難でした。

イメージコントロール：テキスト型のデータベースの列と関連付け、そのコンテンツをイメージへの相対リンクとして解釈することができます

データベースフォームのイメージコントロールを、テキスト型の列に関連付けることができます。以前は、イメージコントロールと関連付けることができるのは、バイナリーと合理的に解釈できる（BLOB型など）コンテンツを有する列だけでした。今では、テキスト型のデータベースの列をイメージコントロールのソースとして選択すると、それぞれの列のコンテンツはURLとして解釈され、このURLによって指し示されているイメージを読み込んで表示します。また、イメージコントロールの埋め込まれているドキュメントに相対的なURLも許可されています。

ナビゲーションツールバー：新しいアイテム「コントロールを更新」

フォームのナビゲーションツールバー（これはデータベースから得られたデータで埋められた活動中のフォームを持つとすぐに使われるものです）には、「コントロールを更新」と呼ばれ、「更新」アイテムのすぐ後に位置する新しいアイテムがあります。

この新しいアイテムが有効になるのは、唯一リストかコンボボックスコントロールにフォーカスがある場合のみです。押されると、コントロールのアイテムリストは更新されます。

フォームの外部のあるインスタンスが、テーブル/クエリーのデータを変更すると、データベースのテーブル（もしくはクエリー）のコンテンツに基づいたリストにとっては、これは特に面白いものになります。この場合には、「コントロールを更新」の機能を使うことで、これらの変更をコントロールのアイテムリストに反映させることができます。

レポート

Sun Report Builderに向けた新たなショートカット

編集メニューは現在、「全て選択」項目を含んでいます。

これが含んでいるのは、

編集->全て選択->全て選択(CTRL+A) 

             ラベルを全て選択
               フォーマットされたフィールドを全て選択
               全てのレポートを選択

です。

新たなレポートを開く際に、自動的に最初のテーブルと関連付けます

データベースに新たなレポートを作成するに際しては、データベースから最初のテーブルをとってきてレポートと関連付けることになります。加えて、フィールド追加ダイアログは、全ての利用可能なフィールドをともなって開くことになります。

レポート出力フォーマットもまた現在、プロパティブラウザで利用可能です

プロパティブラウザは現在では、SRBにおいて選択される際には、フィルターの下の最後の項目である、データページ上のレポート向けに選択された出力フォーマットを表示します。

現在のところ利用可能なフォーマットは以下になります。

-ODFテキストドキュメント

-ODFスプレッドシート

フィールド追加ダイアログは、ソーティングと挿入のツールバーをサポートしています

フィールド追加ダイアログには現在、フィールド向けのリストボックスの上にツールバーがあります。ツールバーを使うことで、ソート順序を削除したり、ソース（テーブル、クエリー）から取り出した元の順序を修復したりできるのと同様に、フィールドを昇順にソートしたり降順にソートしたりすることができます。追加されたツールバーは、「挿入」の項目を含んでいて、この項目によって、レポートセクションに選択されたフィールドを挿入することができます。フィールドの複数選択もまた、サポートされています。

SRB内部からの関数ウィザード

スプレッドシートで使用される関数を現在、Sun Report Builderの内部で使うことができます。


-データフィールド（フォーマットされたフィールドとイメージコントロール）

-一般タブ上の条件付で出力を行う式

http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation#Report_Navigator_-.3E_Report_-.3E_Functions_-.3E_Function_-.3E_Properties_of_General_Tab

-数式

-初期値

からウィザードを開始することができます。


ウィザードは、レポートエンジンによりサポートされている全ての関数を表示します。


SRC向けのドキュメントは、以下で見つかります。

http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation


関数の説明は、以下で見つかります。

http://wiki.services.openoffice.org/wiki/Base/Reports/Functions

Retrieved from "https://wiki.openoffice.org/w/index.php?title=JA/translation/Base/New_features_in_3_1&oldid=146192"
Personal tools
In other languages