管理フォームの詳細 (1Cv8)。メインフォームの詳細管理フォームのクライアント部分とサーバー部分の間でのデータ転送

以下に、マネージドフォームを操作するときに使用される主な 1C オブジェクトを示します。 1C 構成を作成する際のこれらのオブジェクトの従来の使用法を示す簡単なコード例が示されています。

この形

フォームモジュール、プロシージャ内で使用されますクライアント上およびサーバー上&&。

フォーム要素と詳細の両方にアクセスできます。

フォーム要素にはオブジェクトを通じてアクセスします。要素は次のようになります。

ThisForm.Elements.VersionNumber.Header = "v."+ProgramVersion;

フォーム上に存在する属性へのアクセスは次のように行われます。

ThisForm.Advertising Text="こんにちは、同志!";

フォーム要素と詳細への簡単なアクセス

原則として、フォームモジュールにキーワードを指定する必要はありませんこの形。簡素化された方法でフォーム要素と詳細にアクセスできます。

// フォーム要素

Elements.VersionNumber.Title = "v."+ProgramVersion;

// フォームの詳細

広告テキスト = "こんにちは、同志!";

フォームの詳細を取得する機能 (重要!)

フォーム属性が単純型の場合 -文字列、数値、日付 ...その後、名前だけで属性の値を取得 (設定) できます。

テキスト=製品名; // 製品名はフォーム属性です

ただし、この方法では「複雑な」タイプの詳細を取得することは不可能です。値の表、価値観のツリー。このタイプの属性を名前で取得しようとすると、そのタイプのオブジェクトが返されます。データフォームコレクション.

「複合」タイプの属性の値を取得するには、関数を使用する必要があります。FormAttributesValue():

CurrentTable=FormAttributesValue("SelectedConstructionObjects");

「複合」属性の値を設定するには、次の関数を使用できます。ValueInFormAttributes(<Значение>, <ИмяРеквизита>) 、両方のパラメータが必要です。

機能 FormAttributesValue()そして ValueInFormAttributes()サーバー上でのみ利用可能です。

オブジェクト

厳密に言えば、フォーム内にそのようなキーワードはありません。単純に、フォーム (要素フォームなど) が作成されると、1C はフォーム上に次の名前の属性を自動的に作成します。オブジェクト。この属性を通じて、フォーム上で編集されている現在のオブジェクトのプロパティを利用できます。

または、より完全な表記:

このオブジェクト

オブジェクト自体が含まれます。オブジェクトモジュールまたはフォームモジュール内のオブジェクトを取得することを目的としています。

使用法: 読み取り専用。

可用性: サーバー、シッククライアント、外部接続。

データ転送オブジェクトは 1C 8.2 環境でコード構造化され、形式が制御されます。

導入

「マネージドフォーム」の概念と 1C プラットフォームの関連概念について簡単に説明することから始めましょう。プラットフォームに詳しい方は、このセクションを飛ばした方がよいかもしれません。

2008 年に、1C プラットフォームの新しいバージョンである Enterprise 8.2 (以下、マネージドアプリケーションと呼びます) が利用可能になり、インターフェイスの作業層全体が完全に変わりました。これには、コマンドインターフェイス、フォーム、ウィンドウシステムが含まれます。同時に、構成におけるユーザーインターフェイスの開発モデルが変更されるだけでなく、クライアントアプリケーションとサーバーの間で機能を分離するための新しいアーキテクチャも提案されます。
マネージドアプリケーションは、次の種類のクライアントをサポートします。

シッククライアント (通常および管理された起動モード)
シン・クライアント
ウェブクライアント

マネージドアプリケーションは、新しいテクノロジーに基づいて構築されたフォームを使用します。彼らは呼ばれています 管理フォーム。移行を容易にするために、以前のフォーム (いわゆる通常フォーム) もサポートされていますが、その機能は開発されておらず、シッククライアント起動モードでのみ使用できます。
開発者にとってのマネージドフォームの主な違いは次のとおりです。

構造の「ピクセルごと」の説明ではなく、宣言的なもの。要素の特定の配置は、フォームが表示されるときにシステムによって自動的に実行されます。
フォームのすべての機能は次のように説明されます。詳細そして チーム。詳細はフォームが処理するデータであり、コマンドは実行されるアクションです。
フォームはサーバーとクライアントの両方で実行されます。
クライアントのコンテキストでは、ほとんどすべてのアプリケーションタイプが使用できないため、インフォベース内のデータを変更することはできません。
メソッドまたはフォーム変数ごとに指定する必要があります コンパイルディレクティブ、実行場所 (クライアントまたはサーバー) とフォームコンテキストへのアクセスを定義します。

フォームメソッドをコンパイルするためのディレクティブをリストしてみましょう。

&OnClient
サーバー上(&O)
コンテキストなしでサーバー上(&O)
コンテキストなしの&OnClientOnServer

上記を説明してみましょう。このスクリーンショットは、開発モードのマネージドフォームとそのモジュールの例を示しています。宣言的な説明、小道具、コンパイルディレクティブなどを見つけます。

これ以降の説明はすべて、図の右側、モジュールコードを構造化する方法、および効果的なクライアント/サーバーインタラクションの実装を可能にする原則について説明します。

問題を定義しましょう

1C プラットフォームの新しいバージョンが積極的に使用されてから数年が経過し、1C とその多くのパートナーの両方から多くのソリューション (構成) がリリースされました。
この間、開発者はフォーム作成時のクライアントとサーバーの対話の原則について共通の理解を深めましたか?また、新しいアーキテクチャの現実においてソフトウェアモジュールを実装するアプローチは変わりましたか?

同じ標準構成のいくつかの形式のコード構造 (フォームモジュール) を見て、パターンを見つけてみましょう。
構造とは、メソッドをグループ化するために開発者によって割り当てられたコードのセクション (ほとんどの場合、コメントブロック)、およびこれらのメソッドのコンパイルディレクティブを意味します。
例 1:
イベントハンドラーのセクションメソッド - クライアント上メソッド - サーバー上メソッド - クライアント上サービスプロシージャと関数のセクション補助入力制御関数
例 2:
サービス手順と機能支払書類値イベントハンドラー
例 3:
サーバー上のサービスプロシージャクライアント上のサービスプロシージャコンテキストのないサーバー上のサービスプロシージャヘッダーイベントハンドラーコマンドイベントハンドラー
例 4:
汎用プロシージャフォームイベントハンドラ「連絡先情報」サブシステムのプロシージャ
基本的に、コード構造が欠落しています。控えめに言っても、Forms 8.1 にあったものと似ています。

有益ではない単語「一般、サービス、補助」。
臆病な試みは、クライアントメソッドとサーバーメソッドを分離しようとします。
多くの場合、メソッドは「表形式部分の操作、製品、連絡先情報」というインターフェイス要素によってグループ化されます。
メソッドとコードグループの任意の配置。たとえば、イベントハンドラーは、あるフォームでは上部にあり、別のフォームでは下部にあり、3 番目のフォームではまったく強調表示されない場合があります。
そして、これはすべて 1 つの構成内にあることを忘れないでください。
はい、「General、Service、Auxiliary」という単語が常に同じ場所にある構成もありますが...

なぜコード構造が必要なのでしょうか?

メンテナンスの簡素化。
学習を簡素化します。
一般的/重要/成功の原則を記録します。
...あなたのオプション

1C からの既存の開発標準が役に立たないのはなぜですか?

ITS ディスクやさまざまな「開発者ガイド」で公開されている、マネージドフォームを作成する際に推奨される原則を見てみましょう。

サーバー呼び出しの数を最小限に抑えます。
サーバー上での最大のコンピューティング。
非コンテキストのサーバー呼び出しは、コンテキストのサーバー呼び出しよりも高速です。
クライアントとサーバーの通信を念頭に置いたプログラム。
等々。

これらは絶対に正しいスローガンですが、どのように実行すればよいでしょうか? 呼び出しの数を最小限に抑える方法、クライアント/サーバーモードでプログラミングすることの意味は何ですか?

デザインパターンまたは世代の知恵

クライアントとサーバーの対話は、何十年にもわたってさまざまなソフトウェアテクノロジで使用されてきました。前のセクションで概説した質問に対する答えは古くから知られており、2 つの基本原則に要約されています。

リモートファサード（以下、リモートアクセスインターフェースといいます）
データ転送オブジェクト(以下、データ転送オブジェクトといいます)

Martin Fowler の言葉、これらの原則についての説明:

… リモートアクセスを目的とする可能性のある各オブジェクトには、 粒度の低いインターフェースこれにより、特定の手順を実行するために必要な呼び出しの数が最小限に抑えられます。 ...請求書とそのすべての項目を個別にリクエストするのではなく、1 回のリクエストですべての請求書項目を読み取り、更新する必要があります。これはオブジェクトの構造全体に影響します...覚えておいてください: リモートアクセスインターフェイス ドメインロジックは含まれていません.
...私が思いやりのある母親だったら、間違いなく自分の子供にこう言います。「データ転送オブジェクトは絶対に書かないでください!」ほとんどの場合、データ転送オブジェクトは単なるものです。 肥大化したフィールドセット... この忌まわしい怪物の価値は、可能性のみにある 1 回の通話でネットワーク経由で複数の情報を送信する- 分散システムにとって非常に重要な技術です。

1C プラットフォームのテンプレートの例

マネージドフォームを開発するときに開発者が利用できるアプリケーションプログラミングインターフェイスには、これらの原則の例が多数含まれています。
たとえば、典型的な「大まかな」インターフェイスである OpenForm() メソッドです。
オープニングパラメータ = 新しい構造("パラメータ 1, パラメータ 2, パラメータ 3", 値 1, 値 2, 値 3); フォーム = OpenForm(フォーム名, オープニングパラメータ);
v8.1で採用されたスタイルと比較してください。
フォーム = GetForm(フォーム名); フォーム.パラメータ1 = 値1; フォーム.パラメータ2 = 値2; Form.Open();

管理フォームのコンテキストでは、多くの「データ転送オブジェクト」が存在します。選択できます 全身的なそして 開発者定義.
システムオブジェクトは、1 つ以上のフォームデータ要素の形式で、クライアント上のアプリケーションオブジェクトをモデル化します。フォームの詳細を参照せずに作成することはできません。

データフォーム構造
データフォームコレクション
データフォーム構造とコレクション
データシェイプツリー

システムデータ転送オブジェクトからアプリケーションタイプへの変換、またはその逆の変換は、次のメソッドを使用して実行されます。

ValueInFormData()
FormDataValue()
CopyFormData()
ValueInFormAttributes()
FormAttributesValue()

多くの場合、既存のソリューションを適応させる場合には、明示的な変換が使用されます。メソッドは、FormDataCollection ではなく ValueTable などの入力パラメータを予期している (機能を使用している) 場合があります。あるいは、メソッドがアプリケーションオブジェクトのコンテキストで定義されており、フォームから直接呼び出すことができなくなっています。
例 1C v8.1:
// クライアント上でフォーム FillUserCache(DepartmentLink) のコンテキストで
例 1C v8.2:
// サーバー上のフォームのコンテキストで ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); Value→FormAttributes(ProcessingObject, "Object");

データ転送オブジェクト (その構造は開発者によって決定されます) は、クライアントとサーバーの両方で使用できるタイプの小さなサブセットです。ほとんどの場合、以下は「粗化された」インターフェイスのメソッドのパラメータおよび結果として使用されます。

プリミティブ型 (文字列、数値、ブール値)
構造
対応
配列
アプリケーションオブジェクトへのリンク (一意の識別子とテキスト表現)

例: このメソッドはステータスを変更するオーダーのリストを受け取り、エラーの説明をクライアントに返します。
&OnServerWithoutContext 関数 ServerChangeOrderStatus(Orders, NewStatus) エラー = New Match(); // [オーダー][エラーの説明] オーダーサイクル StartTransaction() からのオーダーごとに; DocOb = Order.GetObject(); を試してください。 …。注文だけでなく他のアクションも可能です... Exception CancelTransaction(); Errors.Insert(Order, ErrorDescription()); 試行の終了; エンドサイクル; エラーを返します。 EndFunction // ServerChangeOrderStatus()

コードの構造化

マネージドフォームモジュールが反映すべき主な目標と、ソリューションへのアプローチ。

クライアントコードとサーバーコードを明確に分離します。実行時には、これらは 2 つの相互作用するプロセスであり、それぞれが利用可能な機能が大幅に異なることを忘れないでください。
リモートアクセスインターフェイスの明確な識別、どのサーバーメソッドをクライアントから呼び出すことができ、どのサーバーメソッドを呼び出すことができないか? リモートインターフェイスメソッドの名前は、接頭辞「Server」で始まります。これにより、コードの読み取り中にサーバーへの制御の移行をすぐに確認できるようになり、コンテキストヘルプの使用が簡素化されます。公式推奨 (ITS) では、ChangeOrderStatusOnServer() などのように、接尾辞を付けてメソッドに名前を付けることが推奨されていることに注意してください。ただし、繰り返しますが、すべてのサーバーメソッドをクライアントから呼び出すことができるわけではないため、コンパイル場所よりも論理的なアクセス可能性の方が重要です。したがって、接頭辞「Server」を使用して、クライアントが使用できるメソッドのみをマークします。例のメソッド ServerChangeOrderStatus() を呼び出します。
読みやすさ。好みの問題ですが、モジュールがサーバー上にフォームを作成する手順とリモートアクセス方法を開始する時点で注文を受け付けます。
保守性。新しいコードを追加するための明確な場所が必要です。重要な点は、コンフィギュレーターによって自動的に作成されたメソッドテンプレートがモジュールの最後に追加されることです。フォーム要素のイベントハンドラーはほとんどの場合自動的に作成されるため、各ハンドラーがモジュール内の別の場所にドラッグされないように、対応するブロックは最後に配置されます。

以下は、リストされた目標を実装するモジュールの基本構造です。

グラフィカルオプション – 実行の主なフローを明確に示します。
テキストオプションは、新しいフォームモジュールに構造をすばやく挿入するためのテンプレートデザインの一例です。

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="「日付=」"/> // <Описание> // // //////////////////////////////////////////////// /////////////////////////// // モジュール変数 ///////////////// // //////////////////////////////////////////////// ////////// // サーバー上 //******* サーバー上のイベント ******* &サーバー上サーバー上作成時の手順 (失敗、標準処理) / /ハンドラーの内容を挿入します手順の終了 //******* リモートアクセスインターフェイス ******* //******* サーバー上のビジネスロジック ******* ///////// //////////////////////////////////////// /////// //////////////////// // クライアントとサーバーの共通メソッド /////////////// /////// ////////////////////////////////////////// ///// //////// // クライアント上 //******* クライアント上のビジネスロジック ******* //******* チーム * ****** //******* クライアントイベント ******* ////////////////////////// ///// /////////////////////////////////////////// // // メインプログラムオペレーター

基本的な形式

各構成オブジェクトを使用して、いくつかの標準アクションを実行できます。たとえば、任意のディレクトリについて、その要素のリストを表示したり、ディレクトリの個々の要素を表示したり、ディレクトリのグループを表示したり、ディレクトリから要素や要素のグループを選択したりする必要がある場合があります。どのドキュメントでも、そのようなアクションのリストははるかに小さくなります。ドキュメントのリストを表示する、ドキュメントのリストから選択する、別のドキュメントを表示するなどです。

このような標準アクションがアプリケーションソリューションオブジェクトのデータを使用して確実に実行されるようにするために、対応するアクションを実行するときに使用される基本フォームのセットがオブジェクトごとに存在します。このオブジェクトに従属するフォームはどれもメインとして割り当てることができます。たとえば、ディレクトリ内で 命名法次の基本的な形式が存在する可能性があります。

そしてその書類は 商品およびサービスの受け取り主要なフォームの構成は異なります。

したがって、ユーザーがディレクトリリストを表示したい場合は、 命名法または文書のリスト 商品およびサービスの受け取りを選択すると、システムはこれらのオブジェクトのリストフォームとして指定された対応するフォームを開きます。

自動生成されたフォーム

1C:Enterprise 8 システムの重要な機能は、自動生成フォームのメカニズムです。このメカニズムにより、開発者は各構成オブジェクトに対して可能なすべてのフォームを作成する必要がなくなりました。開発者は新しい構成オブジェクトを追加するだけで、システム自体がユーザーの作業の適切なタイミングで必要なフォームを生成し、このオブジェクトに含まれる情報を表示します。

したがって、開発者は、システムによって自動的に生成されたフォームとの違い (異なる設計または特定の動作) が必要な場合にのみ、アプリケーションソリューションオブジェクトの独自のフォームを作成する必要があります。

フォームをデータにリンクする

フォームが特定の構成オブジェクトに属しているかどうかによって、フォームに表示されるデータの構成が決まるわけではありません。フォームがディレクトリなどに属していること 命名法を使用すると、このディレクトリのメインフォームの 1 つとして割り当てることができますが、このフォームがどのようなデータを表示するか、またその動作がどのようなものになるかは決して決まりません。

フォームとデータを関連付けるには、フォームによって表示されるデータのリストを示すフォームの詳細が使用されます。表示されるデータに関係なく、すべてのフォーム自体は同じ動作をします。ただし、フォーム属性の 1 つをそのメイン属性として指定することができます (太字で強調表示されています)。その場合、フォームとそのプロパティの標準動作は、メインのフォーム属性のタイプに応じて補足されます。

たとえば、ドキュメントがメインフォーム属性として割り当てられている場合、 商品およびサービスの受け取り、フォームを閉じると、システムはこの文書の記録と投稿の確認を要求します。たとえば、フォームの主属性としてディレクトリを割り当てると、 命名法そうすると、フォームを閉じるときにそのような確認リクエストは表示されなくなります。

フォーム構造

フォームの主な特徴は、開発者によって「ピクセルごとに」詳細に描画されていないことです。構成内のフォームは、フォームの構成を論理的に記述したものです。要素の特定の配置は、フォームが表示されるときにシステムによって自動的に実行されます。

フォームの表示部分 (ユーザーに表示される) は、フォーム要素を含むツリーとして記述されます。

要素は、入力フィールド、チェックボックス、ラジオボタン、ボタンなどです。また、要素は、他の要素を含むグループにすることもできます。グループは、フレーム付きのパネル、ページ (ブックマーク) 付きのパネル、ページ自体、またはコマンドパネルとして表すことができます。さらに、要素は要素 (列) を含むテーブルにすることもできます。要素構造は、フォームがどのように見えるかを記述します。

フォームのすべての機能は、詳細とコマンドの形式で説明されています。詳細はフォームが処理するデータであり、コマンドは実行されるアクションです。したがって、開発者はフォームエディターで必要な詳細とコマンドをフォームに含め、それらを表示するフォーム要素を作成し、必要に応じて要素をグループに配置する必要があります。

この論理記述に基づいて、システムはユーザーに表示するフォームの外観を自動的に生成します。この場合、システムは、ユーザーにとって可能な限り使いやすいようにフォーム要素を配置するために、表示されるデータのさまざまなプロパティ (タイプなど) を考慮します。

開発者はさまざまな設定を使用して要素の配置に影響を与えることができます。要素の順序を決定し、希望の幅と高さを指定できます。ただし、これはシステムがフォームを表示するのに役立つ追加情報にすぎません。

フォームでは、開発者はフォーム自体のコマンドだけでなく、構成全体のコマンドインターフェイスで使用されるグローバルコマンドも使用できます。さらに、現在のフォームの特定のデータを考慮して他のフォームを開くパラメータ化可能なコマンドを作成することもできます。たとえば、請求書フォームで現在選択されている倉庫の残高レポートを呼び出すことができます。

フォームの詳細により、データとの接続が保証されます。この場合、詳細のうちの 1 つ (そして 1 つだけ) をメインとして指定できます。必ずしもフォームを描画するデータ型であるとは限りません。ただし、フォームの動作はメイン属性のデータ型によって異なります。フォームの動作の変更に加えて、フォームモジュールのコンテキストも変更されます。フォームのメソッドとプロパティに加えて、メイン属性の値であるオブジェクトのメソッドとプロパティもフォーム内で使用できるようになります。フリーフォームタイプのフォームには基本的な詳細が含まれていないことが重要です。この場合、フォームの動作はユーザーの設定によってのみ決まります。基本的な詳細に関する質問を検討してみましょう。

試験 1C の質問 10.05: プラットフォームプロフェッショナル。 メインフォーム属性は何に使用されますか?

フォーム全体のデータソースを定義します
main 属性で指定されたタイプのデータを使用してフォームを操作するためのプラットフォームの標準機能を定義します
ローカルフォームコンテキストからオブジェクトの詳細にプログラムでアクセスする機能を提供するため
フォームダイアログ上でオブジェクトの詳細を視覚化します。
2と3は正解です
1と2は正解です

正解は 6 番です。上記を参照してください。

試験 1C の質問 10.06: プラットフォームプロフェッショナル。 フォームの詳細は何のために必要ですか?

フォームに表示、編集、または保存されるデータの内容を記述するため
フォーム内のデータを表示および編集するには
1と2は正解です

正解は 3 番目、両方です。

試験 1C の質問 10.07: プラットフォームプロフェッショナル。 任意の制御フォームに基本属性を割り当てるには...

フォーム属性のプロパティで「基本詳細」チェックボックスをオンにする必要があります。
必要なフォーム属性を選択して、フォームの「データ」プロパティに入力する必要があります。

正解は 2 番目です。

試験 1C の質問 10.08: プラットフォームプロフェッショナル。 主要な詳細を任意の通常のフォームに割り当てるには...

フォームをメインにする必要があります。主要な詳細は自動的に決定されます
フォーム属性のプロパティで「基本詳細」チェックボックスをオンにする必要があります。
「編集」メニューに移動し、「基本詳細」を選択して、希望の値を選択する必要があります。
必要なフォーム属性を選択して、フォームの「データ」プロパティに入力する必要があります。

4 番目の正解は次のとおりです。

主な詳細は太字で強調表示されています。

試験 1C の質問 10.09: プラットフォームプロフェッショナル。 メインフォーム属性が 1 つある場合、別のメイン属性を追加することはできますか?

不可能だよ
フォーム属性プロパティに適切な値を代入することで可能になります
「Form」オブジェクトにアクセスする場合、プログラムでのみ可能です。
これは、対応するフォームプロパティに別の値を追加することで可能になります。

正しい答えは最初です。主な要件は厳密に 1 つあります。オブジェクトとの関係は明確でなければなりません。

試験 1C の質問 10.113: Platform Professional。 図に示されているフォームの詳細のうち、主要なものはどれですか?

通貨レート一覧
ディレクトリオブジェクト
ディレクトリフォームには基本的な詳細が含まれていません
ディレクトリフォームには基本的な詳細がすべて記載されています

2 番目の正解は太字のものです。

1C Accounting 8.3 (リビジョン 3.0) でディレクトリ要素に詳細を追加する方法

2016-12-07T18:20:33+00:00

1C ですでに利用可能な機能が不足していることが起こります。また、必ずしもプログラマーに連絡する必要はありません。新しい 1C: Accounting 8.3 (エディション 3.0) に関連したケースの 1 つについて説明します。

取引相手に関する情報を入力するのに十分なフィールドがないとしましょう。そして、「ステータス」という名前の新しいフィールドを追加し、「高」、「中」、「低」の 3 つの値のいずれかを持ちます。以下では、コンフィギュレーターを使用せずにそのようなフィールドを追加する方法を段階的に説明します。

1. [管理] セクションに移動し、[一般設定] () を選択します。

2. 「追加の詳細と情報」チェックボックスがまだチェックされていない場合は、チェックを入れます。「追加の詳細」リンクをクリックします。

3. 開いた設定ウィンドウの左側で、「アカウント」を選択します。ツールバーの「新規」ボタンをクリックします。

4. 「Counterparty」ディレクトリの要素の新しい詳細を作成するためのウィンドウが開きます。 [名前]フィールドに「ステータス」と入力します。値のタイプは「追加値」のままにしておきますが、将来的には他の値のタイプ (文字列、数値、日付など) も使用できることに留意してください。しかし、ユーザーに 3 つのオプションの限られた選択肢を提供したいので、今必要なのは付加価値です。