집 » 스포츠 » 스위치, 일반 애플리케이션, 관리형 양식. 스위치, 일반 애플리케이션, 관리되는 양식 1c 관리되는 양식의 문제

스위치, 일반 애플리케이션, 관리형 양식. 스위치, 일반 애플리케이션, 관리되는 양식 1c 관리되는 양식의 문제

1C:Enterprise 플랫폼을 사용하면 관리되는 양식의 요소를 프로그래밍 방식으로 추가하고 변경할 수 있습니다. 이것이 왜 필요한지 알아 보겠습니다.

여러 경우에 양식의 소프트웨어 수정이 필요할 수 있습니다.

후속 업데이트 절차를 용이하게 하기 위해 표준 구성을 마무리할 때. 이 경우 양식 모듈만 변경됩니다. 모듈은 양식보다 업데이트하기가 훨씬 쉽습니다.
몇 가지 일반적인 알고리즘을 구현할 때. 예를 들어, "객체 세부 정보 편집 금지" 하위 시스템에서는 하위 시스템에 연결된 모든 객체에 대해 프로그래밍 방식으로 버튼을 생성하여 세부 정보 편집 기능을 활성화할 수 있습니다.
특정 알고리즘을 구현할 때. 예를 들어 명명법 디렉터리에는 추가 세부정보를 편집하기 위한 필드가 생성됩니다.

관리되는 양식에서는 프로그래밍 방식으로 다음을 추가, 변경 및 삭제할 수 있습니다.

필수품;
지역 팀;
강요.

이 모든 작업은 서버에서만 가능합니다.

프로그래밍 방식으로 모양을 변경하면 다음과 같은 제한 사항이 있습니다.

프로그래밍 방식으로 추가된 세부 정보/명령/요소만 삭제할 수 있습니다. 구성자에서 생성된 개체를 프로그래밍 방식으로 삭제할 수 없습니다.
속성을 기본 속성으로 할당할 수 없습니다.

양식 명령 변경

개체에 대한 명령 구성을 관리하려면 관리형 양식컬렉션이 있습니다 팀

추가하다 (< ИмяКоманды >)

수량 ()

찾다 (< ИмяКоманды >)

삭제 (< Команда >)

Teams 컬렉션은 클라이언트와 서버 모두에서 사용할 수 있습니다. 서버에서만 컬렉션(Add() 및 Delete() 메서드)을 변경할 수 있습니다. 클라이언트와 서버 모두에서 요소 수(Find() 및 Count() 메서드)를 검색하고 가져올 수 있습니다.

양식 명령 작업의 예로 "ChangeHistory..."라는 제목이 있는 새 ChangeHistory 명령을 생성해 보겠습니다. 이 명령은 핸들러를 호출합니다. 디스플레이 히스토리(). 양식이 열릴 때 생성이 발생합니다.

&서버에서
절차 WhenCreatingOnServer(실패, 표준처리)
팀 = 팀. 추가하다( "변화의 역사");
팀 . 동작 = ;
팀 . 제목 = "변화의 역사...";
절차 종료
&클라이언트에서
절차 Connectable_DisplayHistory(명령)
// 명령 동작
절차 종료

명령 처리기는 양식에 있어야 하며 &OnClient 컴파일 지시문이 있어야 합니다.

양식 세부정보 변경

양식 세부사항의 구성을 읽는 기능은 다음과 같습니다. 세부 정보 얻기(< Путь >) FormAttributes 유형의 배열을 반환합니다. 함수 매개변수는 상위 속성에 대한 경로를 문자열로 지정합니다. 매개변수가 생략되거나 빈 문자열이 지정되면 최상위 세부 정보가 반환됩니다.

세부 사항 변경은 다음 메소드를 사용하여 수행됩니다. 세부정보 변경(<세부정보를 추가했습니다.>, <이동식 세부 사항>) 물체 관리형 양식. 매개변수에 세부정보를 추가했습니다.그리고 이동식 세부 사항양식 속성 유형의 요소가 포함된 배열이 전송됩니다.

주목!

세부 구성을 변경하는 과정은 리소스 집약적입니다. 실제로 양식이 다시 만들어지고 있습니다. 이와 관련하여 양식 세부 정보 작업은 일괄 모드에서 수행됩니다.

Buyer라는 이름의 새 양식 속성을 만들어 보겠습니다.

AddedDetails = 새 어레이;
세부정보를 추가했습니다. 추가(새 양식 속성(“구매자”, 새 유형 설명(“DirectoryLink. 상대방”), “클라이언트”));

// 디테일 구성의 변화
);

양식 요소 변경

객체 요소의 구성을 제어하려면 관리형 양식컬렉션이 있습니다 강요. 컬렉션에는 여러 가지 메서드가 있습니다.

끼워 넣다 (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

추가하다 (< Имя>, < ТипЭлемента>, < Родитель >)

수량 ()

찾다 (< Имя >)

이동하다(< Элемент>, < Родитель>, < МестоРасположения >)

삭제 (< Элемент >)

Items 컬렉션은 클라이언트와 서버 모두에서 사용할 수 있습니다. 컬렉션 수정(삽입 메소드 () , 추가() , 이동() 및 삭제() )는 서버에서만 사용할 수 있습니다. 클라이언트와 서버 모두에서 요소 수(Find() 및 Count() 메서드)를 검색하고 가져올 수 있습니다. 수집 요소는 다음과 같습니다.

양식그룹;
FormTable;
양식필드;
양식 버튼.

프로그래밍 방식으로 이벤트 핸들러를 양식 요소에 할당할 수 있습니다. 이 방법은 이러한 목적을 위해 고안되었습니다. 설정작업(< ИмяСобытия>, < Действие >) .

명령, 세부 정보 및 양식 요소 작업에 대한 가장 일반적인 예를 살펴보겠습니다.

명령 및 관련 버튼 추가:

// 명령 생성
팀 = 팀. 추가하다( "변화의 역사");
팀 . 행동 = "플러그인_DisplayHistory"; // 양식에는 지정된 이름의 프로시저가 포함되어야 합니다.
팀 . 표제 = "변화의 역사...";
// 버튼을 생성하고 명령과 연결
요소 = 아이템. 추가하다( "변화의 역사", Type("양식버튼" ));
요소.명령이름 = "변화의 역사";

속성 및 관련 입력 필드 추가:

// 추가된 내용에 대한 설명
AddedDetails = 새 어레이;
세부정보를 추가했습니다. 추가하다(새 양식 소품("구매자", 새 유형 설명( "DirectoryLink. 상대방"), "고객" ));
// 디테일 구성 변경
ChangeDetails(추가된 세부정보);
// 입력 필드를 생성하고 속성과 연결
요소 = 아이템. Add("구매자" , Type("양식 필드" ));
요소 . 보기 = FormFieldView. 입력 필드;
요소 . 데이터 경로= "구매자" ;

양식 요소에 이벤트 핸들러 할당:

품목고객. SetAction("변화할 때" , "Connected_BuyerOnChange");

&클라이언트에서
절차 Connected_BuyerOnChange(요소)
// 이벤트 액션
절차 종료

주목!

메서드를 사용하여 코드에서 이벤트 핸들러로 설정된 프로시저 설정액션(), 접두사 Connectable_을 설정하는 것이 좋습니다.

주목!

관리되는 양식의 세부 사항, 명령 및 요소를 프로그래밍 방식으로 검색하고 변경하는 예제를 통해 처리 내용을 다운로드할 수 있습니다.

그리고 1C 8.2 환경에서 코드 구조화, 제어 형식에 대한 데이터 전송 개체입니다.

소개

1C 플랫폼의 "관리되는 양식" 개념과 관련 개념에 대한 간단한 설명부터 시작하겠습니다. 플랫폼 전문가라면 이 섹션을 건너뛰어도 됩니다.

2008년에는 1C 플랫폼의 새 버전인 Enterprise 8.2(이하 관리 애플리케이션이라고 함)가 출시되어 인터페이스로 전체 작업 계층을 완전히 변경했습니다. 여기에는 명령 인터페이스, 양식 및 창 시스템이 포함됩니다. 동시에 구성 변경에서 사용자 인터페이스 개발 모델을 변경할 뿐만 아니라 클라이언트 애플리케이션과 서버 간의 기능을 분리하기 위한 새로운 아키텍처도 제안됩니다.
관리되는 애플리케이션은 다음 유형의 클라이언트를 지원합니다.

Thick 클라이언트(일반 및 관리형 시작 모드)
씬 클라이언트
웹 클라이언트

관리되는 응용 프로그램은 새로운 기술을 기반으로 구축된 양식을 사용합니다. 그들은 호출됩니다 관리되는 양식. 전환을 쉽게 하기 위해 이전 양식(소위 일반 양식)도 지원되지만 해당 기능은 개발되지 않았으며 씩 클라이언트 시작 모드에서만 사용할 수 있습니다.
개발자를 위한 관리 양식의 주요 차이점은 다음과 같습니다.

구조에 대한 "픽셀별" 설명이 아닌 선언적 설명입니다. 요소의 특정 배치는 양식이 표시될 때 시스템에 의해 자동으로 수행됩니다.
양식의 모든 기능은 다음과 같이 설명됩니다. 세부그리고 팀. 세부 사항은 양식이 작동하는 데이터이고 명령은 수행할 작업입니다.
양식은 서버와 클라이언트 모두에서 실행됩니다.
클라이언트 컨텍스트에서는 거의 모든 애플리케이션 유형을 사용할 수 없으므로 정보베이스의 데이터를 변경하는 것이 불가능합니다.
각 메소드 또는 양식 변수에 대해 이를 지정해야 합니다. 컴파일 지시문, 실행 위치(클라이언트 또는 서버) 및 양식 컨텍스트에 대한 액세스를 정의합니다.

양식 메소드 컴파일을 위한 지시문을 나열해 보겠습니다.

&클라이언트에서
&서버에서
&컨텍스트 없이서버에서
&OnClientOnServer컨텍스트 없음

위의 내용을 설명해 보겠습니다. 스크린샷은 개발 모드의 관리되는 양식과 해당 모듈의 예를 보여줍니다. 선언적 설명, 소품, 컴파일 지시문 등을 찾으세요.

모든 추가 논의는 그림의 오른쪽 부분, 모듈 코드를 구성하는 방법 및 효과적인 클라이언트-서버 상호 작용을 구현하는 데 사용할 수 있는 원칙에 대해 설명합니다.

문제를 정의해보자

1C 플랫폼의 새 버전이 활발히 사용되고 1C와 많은 파트너가 많은 솔루션(구성)을 출시한 지 몇 년이 지났습니다.
이 기간 동안 개발자는 양식을 작성할 때 클라이언트-서버 상호 작용 원칙에 대한 공통된 이해를 발전시켰으며 새로운 아키텍처 현실에서 소프트웨어 모듈 구현에 대한 접근 방식이 변경되었습니까?

동일한 표준 구성의 여러 형태의 코드 구조(폼 모듈)를 살펴보고 패턴을 찾아보겠습니다.
구조란 개발자가 그룹 메서드 및 이러한 메서드에 대한 컴파일 지시문에 할당한 코드 섹션(주로 주석 블록)을 의미합니다.
예시 1:
이벤트 핸들러 섹션 메소드 - 클라이언트 메소드 - 서버 메소드 - 클라이언트 서비스 프로시저 및 기능 섹션 보조 입력 제어 기능
예 2:
서비스 절차 및 기능 결제 문서 값 이벤트 핸들러
예시 3:
서버의 서비스 프로시저 클라이언트의 서비스 프로시저 컨텍스트가 없는 서버의 서비스 프로시저 헤더 이벤트 핸들러 명령 이벤트 핸들러
예시 4:
범용 프로시저 양식 이벤트 핸들러 "연락처 정보" 하위 시스템의 프로시저
본질적으로 코드 구조가 누락되었거나 가볍게 말하면 Forms 8.1에 있었던 것과 유사합니다.

정보가 없는 단어 "일반, 서비스, 보조".
Timid는 클라이언트와 서버 방법을 분리하려고 시도합니다.
메소드는 종종 "제품, 연락처 정보 표 형식 부분 작업" 인터페이스 요소로 그룹화됩니다.
메소드 및 코드 그룹의 임의 배열. 예를 들어, 이벤트 처리기는 한 형식에서는 맨 위에 있고 다른 형식에서는 맨 아래에 있을 수 있으며 세 번째 형식에서는 전혀 강조 표시되지 않을 수 있습니다.
그리고 이 모든 것이 하나의 구성 내에 있다는 사실을 잊지 마십시오.
예, "일반, 서비스, 보조"라는 단어가 항상 같은 위치에 있는 구성이 있지만...

왜 코드 구조가 필요한가요?

유지관리 단순화.
학습을 단순화하세요.
일반적인/중요한/성공적인 원칙을 기록합니다.
...귀하의 선택

1C의 기존 개발 표준이 도움이 되지 않는 이유는 무엇입니까?

관리되는 양식을 작성할 때 권장되는 ITS 디스크 및 다양한 "개발자 가이드..."에 게시된 원칙을 살펴보겠습니다.

서버 호출 수를 최소화하십시오.
서버에서의 최대 컴퓨팅.
비상황별 서버 호출은 상황별 서버 호출보다 빠릅니다.
클라이언트-서버 통신을 염두에 두고 프로그램하세요.
등등.

이는 절대적으로 사실인 슬로건이지만 이를 구현하는 방법은 무엇입니까? 호출 수를 최소화하는 방법, 클라이언트-서버 모드에서 프로그래밍한다는 것은 무엇을 의미합니까?

디자인 패턴 또는 세대의 지혜

클라이언트-서버 상호 작용은 수십 년 동안 다양한 소프트웨어 기술에서 사용되었습니다. 이전 섹션에 설명된 질문에 대한 답은 오랫동안 알려져 왔으며 두 가지 기본 원칙으로 요약됩니다.

원격 파사드(이하 원격 액세스 인터페이스라고 함)
데이터 전송 객체(이하 데이터 전송 객체라고 함)

마틴 파울러(Martin Fowler)는 이러한 원칙에 대해 다음과 같이 설명합니다.

… 잠재적으로 원격 액세스용으로 의도된 각 개체에는 다음이 있어야 합니다. 낮은 세분성 인터페이스, 이는 특정 절차를 수행하는 데 필요한 호출 수를 최소화합니다. ... 송장과 모든 항목을 별도로 요청하는 대신 한 번의 요청으로 모든 송장 항목을 읽고 업데이트해야 합니다. 이는 객체의 전체 구조에 영향을 미칩니다...기억하세요: 원격 액세스 인터페이스 도메인 논리를 포함하지 않습니다..
...내가 돌보는 엄마라면 분명히 내 아이에게 이렇게 말할 것입니다. "데이터 전송 객체를 절대 작성하지 마세요!" 대부분의 경우 데이터 전송 개체는 다음과 같습니다. 부풀어 오른 필드 세트... 이 역겨운 괴물의 가치는 오로지 가능성에 달려 있다 한 번의 호출로 네트워크를 통해 여러 정보를 전송합니다.- 분산 시스템에 매우 중요한 기술입니다.

1C 플랫폼의 템플릿 예

관리되는 양식을 개발할 때 개발자가 사용할 수 있는 응용 프로그램 프로그래밍 인터페이스에는 이러한 원칙에 대한 많은 예가 포함되어 있습니다.
예를 들어, 일반적인 "거친" 인터페이스인 OpenForm() 메서드가 있습니다.
openingParameters = 새 구조("매개변수1, 매개변수2, 매개변수3", 값1, 값2, 값3); Form = OpenForm(FormName, openingParameters);
v8.1에서 채택된 스타일과 비교해 보세요.
양식 = GetForm(양식이름); Form.Parameter1 = 값1; Form.Parameter2 = 값2; 양식.열기();

관리되는 양식의 컨텍스트에는 많은 "데이터 전송 개체"가 있습니다. 당신은 선택할 수 있습니다 전신의그리고 개발자 정의.
시스템은 하나 이상의 양식 데이터 요소 형태로 클라이언트의 애플리케이션 객체를 모델링합니다. 양식 세부정보를 참조하지 않으면 생성이 불가능합니다.

데이터양식구조
DataForms컬렉션
DataFormStructureWithCollection
데이터셰이프트리

시스템 데이터 전송 개체를 애플리케이션 유형으로 또는 그 반대로 변환하는 작업은 다음 방법을 사용하여 수행됩니다.

ValueInFormData()
양식데이터값()
CopyFormData()
ValueInForm속성()
양식속성값()

기존 솔루션을 조정할 때 명시적 변환이 사용되는 경우가 많습니다. 메소드는 FormDataCollection이 아닌 ValueTable과 같은 입력 매개변수를 예상(기능 사용)할 수 있습니다. 또는 메소드가 애플리케이션 객체의 컨텍스트에서 정의되어 양식에서 직접 호출할 수 없게 되었습니다.
예제 1C v8.1:
// 클라이언트에서 FillUserCache(DepartmentLink) 양식의 컨텍스트로
예제 1C v8.2:
// 서버에서 양식의 컨텍스트에서 ProcessObject = Form AttributesValue("Object"); ProcessObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "개체");

개발자가 구조를 결정하는 데이터 전송 개체는 클라이언트와 서버 모두에서 사용할 수 있는 유형의 작은 하위 집합입니다. 대부분 다음은 "대략화된" 인터페이스 메서드의 매개변수 및 결과로 사용됩니다.

기본 유형(문자열, 숫자, 부울)
구조
일치
정렬
애플리케이션 객체에 대한 링크(고유 식별자 및 텍스트 표현)

예: 이 메서드는 상태 변경 주문 목록을 수락하고 오류에 대한 설명을 클라이언트에 반환합니다.
&OnServerWithoutContext 함수 ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [주문][오류 설명] 주문 주기의 각 주문에 대해 StartTransaction(); DocOb = Order.GetObject();를 시도해 보세요. …. 주문뿐만 아니라 다른 작업도 가능합니다... Exception CancelTransaction(); Errors.Insert(주문, ErrorDescription()); 시도 종료; 엔드사이클; 반환 오류; EndFunction // ServerChangeOrderStatus()

코드 구조화

관리형 양식 모듈이 반영해야 할 주요 목표와 솔루션에 대한 접근 방식입니다.

클라이언트와 서버 코드의 명확한 분리.실행 시에는 두 개의 상호 작용 프로세스가 있으며, 각 프로세스에는 사용 가능한 기능이 상당히 다르다는 점을 잊지 마십시오.
원격 액세스 인터페이스의 명확한 식별, 클라이언트에서 호출할 수 있는 서버 메서드와 호출할 수 없는 서버 메서드는 무엇입니까? 원격 인터페이스 메소드의 이름은 접두사 "Server"로 시작됩니다. 이를 통해 코드를 읽는 동안 서버로 제어권이 이전되는 것을 즉시 확인할 수 있으며 상황별 도움말 사용이 단순화됩니다. 공식 권장 사항(ITS)에서는 ChangeOrderStatusOnServer()와 같이 접미사가 포함된 명명 방법을 제안합니다. 그러나 클라이언트에서 모든 서버 메서드를 호출할 수 있는 것은 아니므로 컴파일 위치보다는 논리적 접근성이 더 중요하다는 점을 반복합니다. 따라서 접두사 "Server"를 사용하여 클라이언트에서 사용할 수 있는 메서드만 표시합니다. 예제 메서드 ServerChangeOrderStatus()를 호출해 보겠습니다.
가독성.취향의 문제로, 서버에서 양식을 생성하는 절차와 원격 액세스 방법으로 모듈이 시작될 때 순서를 수락합니다.
유지 관리성.새 코드를 추가하려면 명확한 위치가 있어야 합니다. 중요한 점은 구성자에 의해 자동으로 생성된 메소드 템플릿이 모듈 끝에 추가된다는 것입니다. 양식 요소에 대한 이벤트 핸들러는 자동으로 생성되는 경우가 가장 많기 때문에 각 핸들러를 모듈의 다른 위치로 드래그하지 않도록 해당 블록은 마지막에 위치합니다.

다음은 나열된 목표를 구현하는 모듈의 기본 구조입니다.

그래픽 옵션 – 주요 실행 흐름을 명확하게 보여줍니다.
텍스트 옵션은 새 양식 모듈에 구조를 빠르게 삽입하기 위한 템플릿 디자인의 예입니다.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""날짜=""/> // <Описание> // // /////////////////////////////////////////////// // ////////////////////////// // 모듈 변수 ///////////////// // ///////////////////////////////////////////// //// ////////// // 서버에서 //********* 서버에서 이벤트 ******* &서버에서 서버에 생성된 프로시저(실패, 표준처리) / /핸들러의 내용 삽입 절차 끝 //********* 원격 액세스 인터페이스 ******* //********* 서버의 비즈니스 로직 ******* ///////// //////////////////////////////////////// /////// /////////////////// // 클라이언트와 서버의 일반적인 방법 /////////////// /////// ////////////////////////////////////////// ///// //////// // 클라이언트 //******** 클라이언트 비즈니스 로직 ******* //********* 팀 * ****** //******** 클라이언트 이벤트 ******* ///////////////////////// ///// //////////////////////////////////////////// // / / 주요 프로그램 연산자

기본 형태

각 구성 개체를 사용하여 일부 표준 작업을 수행할 수 있습니다. 예를 들어, 모든 디렉토리에 대해 해당 요소 목록을 표시하고, 디렉토리의 개별 요소를 표시하고, 디렉토리 그룹을 표시하고, 디렉토리에서 요소 및 요소 그룹을 선택해야 할 수 있습니다. 모든 문서에 대해 이러한 작업 목록은 문서 목록 보기, 문서 목록에서 선택, 별도 문서 보기 등 훨씬 더 작습니다.

이러한 표준 작업이 애플리케이션 솔루션 개체의 데이터로 수행되도록 하기 위해 각 작업에 대해 해당 작업을 수행할 때 사용되는 기본 양식 세트가 있습니다. 이 개체에 종속된 양식은 모두 기본 개체로 할당될 수 있습니다. 예를 들어, 디렉토리에서 명명법다음과 같은 기본 형식이 있을 수 있습니다.

그리고 문서 상품 및 서비스 수령기본 양식의 구성은 다릅니다.

따라서 사용자가 디렉토리 목록을 보려는 경우 명명법또는 문서 목록 상품 및 서비스 수령, 시스템은 이러한 개체에 대한 목록 양식으로 지정된 해당 양식을 엽니다.

자동 생성된 양식

1C:Enterprise 8 시스템의 중요한 기능은 자동 생성된 양식의 메커니즘입니다. 이 메커니즘을 사용하면 개발자가 각 구성 개체에 대해 가능한 모든 양식을 만들 필요가 없습니다. 개발자는 새로운 구성 개체를 추가하기만 하면 시스템 자체가 사용자 작업의 적절한 순간에 이 개체에 포함된 정보를 표시하는 데 필요한 양식을 생성합니다.

따라서 개발자는 시스템에서 자동으로 생성된 양식과 차이점(다른 디자인 또는 특정 동작)이 있어야 하는 경우에만 자신의 형태의 응용 프로그램 솔루션 개체를 생성하면 됩니다.

양식을 데이터에 연결

양식이 특정 구성 개체에 속하는지 여부는 양식에 표시되는 데이터의 구성을 결정하지 않습니다. 예를 들어 양식이 디렉토리에 속한다는 사실 명명법를 사용하면 이를 이 디렉터리의 기본 양식 중 하나로 할당할 수 있지만 이 양식이 표시할 데이터와 해당 동작이 어떤 방식으로 결정되는지는 결정되지 않습니다.

양식을 데이터와 연결하기 위해 양식에 표시되는 데이터 목록을 나타내는 양식 세부 정보가 사용됩니다. 모든 양식 자체는 표시되는 데이터에 관계없이 동일한 동작을 갖습니다. 그러나 양식 속성 중 하나를 해당 기본 속성으로 지정할 수 있습니다(굵게 강조 표시됨). 이 경우 기본 양식 속성의 유형에 따라 양식의 표준 동작과 해당 속성이 보완됩니다.

예를 들어 문서가 기본 양식 속성으로 할당된 경우 상품 및 서비스 수령, 양식을 닫으면 시스템에서 이 문서의 기록 및 게시 확인을 요청합니다. 예를 들어 디렉토리를 양식의 기본 속성으로 할당하면 명명법, 양식을 닫을 때 이러한 확인 요청이 나타나지 않습니다.

양식 구조

양식의 주요 특징은 개발자가 "픽셀 단위"로 자세히 그리지 않는다는 것입니다. 구성의 양식은 양식 구성에 대한 논리적 설명입니다. 그리고 양식이 표시될 때 요소의 특정 배치가 시스템에 의해 자동으로 수행됩니다.

양식의 표시된 부분(사용자에게 표시됨)은 양식 요소를 포함하는 트리로 설명됩니다.

요소는 입력 필드, 확인란, 라디오 버튼, 버튼 등이 될 수 있습니다. 또한 요소는 다른 요소를 포함하는 그룹일 수도 있습니다. 그룹은 프레임이 있는 패널, 페이지(책갈피)가 있는 패널, 페이지 자체 또는 명령 패널로 표시될 수 있습니다. 또한 요소는 요소(열)도 포함하는 테이블일 수 있습니다. 요소 구조는 양식이 어떻게 보이는지 설명합니다.

양식의 모든 기능은 세부사항과 명령의 형태로 설명됩니다. 세부 사항은 양식이 작동하는 데이터이고 명령은 수행할 작업입니다. 따라서 양식 편집기의 개발자는 필요한 세부 정보와 명령을 양식에 포함하고, 이를 표시하는 양식 요소를 만들고, 필요한 경우 요소를 그룹으로 정렬해야 합니다.

이 논리적 설명을 기반으로 시스템은 사용자에게 표시할 양식의 모양을 자동으로 생성합니다. 이 경우 시스템은 사용자에게 최대한 편리하게 양식 요소를 배열하기 위해 표시된 데이터의 다양한 속성(예: 유형)을 고려합니다.

개발자는 다양한 설정으로 요소 배열에 영향을 미칠 수 있습니다. 요소의 순서를 결정하고 원하는 너비와 높이를 지정할 수 있습니다. 그러나 이는 시스템이 양식을 표시하는 데 도움이 되는 몇 가지 추가 정보일 뿐입니다.

폼에서 개발자는 폼 자체의 명령뿐만 아니라 전체 구성의 명령 인터페이스에서 사용되는 전역 명령도 사용할 수 있습니다. 또한 현재 양식의 특정 데이터를 고려하여 다른 양식을 여는 매개변수화 가능한 명령을 생성할 수도 있습니다. 예를 들어 현재 송장 양식에서 선택된 창고의 잔액에 대한 보고서를 호출할 수 있습니다.

우리 모두는 1C 회사에 1C 플랫폼의 다양한 버전이 있다는 것을 알고 있습니다. 이제 이 기사를 작성할 당시 최신 버전 중 하나인 1C 8.2 및 1C 8.3 버전에 관심이 있을 것입니다. 이 두 버전 모두에서 작업해야 한다면 아마도 이 버전의 인터페이스에서 차이점을 발견했습니다., 사용자의 경우 모양만 다릅니다. 본질적으로 선택 일반 또는 관리형 애플리케이션실행하기 위해 표시할 양식을 시스템에 알려줍니다. 정규 또는 통제, 기본적으로 사용되는 애플리케이션 클라이언트(씩 또는 씬)도 표시됩니다. 클라이언트에 대한 자세한 내용은 "1C의 두꺼운 클라이언트와 씬 클라이언트는 무엇이며 차이점은 무엇입니까?" 기사를 읽어보십시오.

일반 1C 애플리케이션(정규 형식, 일반 인터페이스, 버전 1C 8.2)

1C 8.2에서는 작업만 가능합니다. 일반 양식의 경우, 일반 응용 프로그램 모드의 경우. 아래 이미지는 "일반 1C 애플리케이션"작동 모드(정규 형식)의 데이터베이스를 보여줍니다.

관리되는 1C 애플리케이션(관리되는 양식, 관리되는 인터페이스, 버전 1C 8.3)

1C 8.3 플랫폼에서는 일반 형식(호환 모드)과 관리형 형식을 모두 사용할 수 있습니다. 게다가 관리형 양식에는 표준 및 택시라는 두 가지 유형의 표시가 있습니다.. 표준 관리 양식을 사용한 1C 8.3 구성의 예가 아래에 나와 있으며 그 뒤에 "택시"인터페이스가 표시됩니다.

일반 1C 애플리케이션과 관리형 1C 애플리케이션의 차이점은 무엇인가요?

우리는 이미 알아냈듯이 일반 응용 프로그램과 관리 응용 프로그램은 이러한 유형의 1C 프로그램 실행입니다.. 또한 1C 출시 유형의 값에 따라 ( 일반 또는 관리형 애플리케이션), 특정 인터페이스가 기본적으로 로드됩니다( 일반 또는 관리형 양식) 따라서 이 개념에는 동의어가 너무 많습니다. 인터페이스의 차이가 매우 크다는 점에 주목하고 싶습니다. 관리되는 인터페이스가 완전히 재설계되었습니다. 원칙적으로 이는 1C 프로그램의 일반 사용자가 보는 모든 차이점입니다. 프로그래머의 경우 관리되는 인터페이스에는 수정된 코드 작성이 필요합니다. 개발이 이미 1C 8.2가 아닌 1C 8.3에서 수행되어 그에 따른 모든 결과가 발생하기 때문입니다. 또한 코드는 클라이언트와 서버로 구분되어야 하며 이는 구성자에서 적절한 지시문을 사용하여 표시됩니다.

Klyuev V.V.

http://prof1c.kklab.ru

스위치로 작업하기

사이트 서비스의 모든 사용자를 고려하십시오. 초보자 섹션에 자료를 게시합니다!!!

8.2 관리되는 양식

관리되는 양식의 동작을 연구하는 동안 프로그래머나 인터페이스 개발자는 스위치가 관리되는 양식의 어디에 있는지, 스위치를 양식에 추가하는 방법에 대한 질문에 직면하게 됩니다. 작은 일이지만, 이런 사소한 일에 많은 시간을 소비한다는 것은 불쾌합니다. 이 시간은 형태를 디자인하는 것보다 알고리즘을 개발하고 최적화하는 데 소비될 수 있습니다.

따라서 질문을 이해하기 위해 빈 구성을 만들거나 일반적인 구성을 선택해 보겠습니다.
디렉터리가 포함된 그룹으로 이동하여 실험할 새 디렉터리를 추가합니다. 구성에는 기본 시작 모드인 관리형 애플리케이션이 있어야 합니다.

이제 새 디렉토리를 생성하고 "Boolean" 유형의 "Property1" 속성을 추가해 보겠습니다.

이제 양식 탭으로 이동하여 새 양식을 추가해 보겠습니다.

이제 제어되는 양식이 생성되었습니다. 이제 양식을 사용하여 스위치가 있는 위치를 찾아보겠습니다.
여기에 우리의 형태가 있고 그 위에 소품이 보이지만 깃발 형태입니다.

그럼 우리가 뭘 잘못한 걸까요?
컨트롤 유형에 대한 스위치가 있는지 알아보기 위해 소품의 속성을 살펴보겠습니다.
그리고 Switch 필드가 여기에 없다는 것을 알 수 있습니다!(어디서 잘못 되었나요?

분명히 양식의 컨트롤 유형은 데이터 유형에 따라 다릅니다. 양식 속성, 즉 세부 정보 탭으로 돌아가서 속성의 속성, 즉 "Boolean" 유형을 "Number" 유형으로 변경해 보겠습니다.

이제 컨트롤의 속성으로 돌아가서 컨트롤의 보기가 해당 속성에 추가되었는지 확인하겠습니다. - - 그리고 만세, 거기에 보기가 표시됩니다 - 스위치 필드.

이제 우리가 보는 양식을 살펴보십시오.

3개의 기본값, 3개의 스위치가 표시되지만 그 중 2개가 필요합니다. 속성 속성으로 다시 이동하여 "열 수" 속성을 살펴보세요.

2의 경우 열 수를 2로 설정합니다.

이것은 피곤한 프로그래머를 조금 멈출 수도 있습니다.)) 그러나 이제 그와 우리 모두 그것을 알고 있습니다!

8.2 일반 양식.

일반적인 형태의 스위치는 지루합니다.
이미 일부 스위치가 있는 기성 양식을 수정해야 하고 이 양식에 다른 스위치를 추가해야 하는 경우가 있으며 실제로 발생합니다. 여기서는 일종의 지루함이 발생하는데, 이는 코드를 프로그래밍하는 데 시간이 아니라 사용자에게 이러한 스위치를 표시하는 데 시간을 낭비하는 데 많은 시간이 걸립니다.

그럼 예를 살펴보겠습니다. 1C UPP에는 영수증 조정을 위한 문서가 있습니다. 확실히 존재합니다. 회계에 대해 약간 다른 항목이 그려지도록 스위치를 추가해야 했던 적이 있습니다. 문제가 무엇입니까? 우리는 반드시 해야 할 것 같습니다. 꼭 해야 합니다. 그렇게 할 것입니다. 하지만 이 양식에는 이미 2개의 라디오 버튼이 있습니다.

스위치를 더 추가해야 하는 형태는 다음과 같습니다.

고급 탭에 라디오 버튼 두 개를 더 배치하고 싶습니다. 그래서 첫 번째 단계는 필요한 곳에 새로운 컨트롤 요소를 과감하게 추가하고 삽입하는 것입니다.

모든 것이 단순한 것 같습니다. "숫자" 유형의 새 속성을 생성하고 2개의 스위치를 삽입합니다. 그 중 하나는 속성에 데이터를 쓸 수 있고 다른 하나는 그렇지 않습니다.

새 제어 요소인 스위치를 추가하고 스위치 수 및 설명과 함께 테이블에 Switch2를 추가한 다음 그룹에서 Switch1을 먼저 설정하고 확인을 누릅니다. 생성된 컨트롤을 폼에 배치합니다. 데이터베이스 구성을 업데이트하고(F7) 디버깅을 위해 실행합니다.

실행할 때(1C:Enterprise 모드에서 새 문서를 생성할 때) Switch2를 아무리 클릭해도 아무 일도 일어나지 않는 것을 볼 수 있습니다. 요소가 제대로 작동하지 않습니다. 여기에는 한 가지 트릭이 있습니다.
구성자로 돌아갑니다. 메뉴 항목 양식 -> 순회 순서 설정...을 선택합니다(양식이 화면에 열려 있는 것이 중요합니다).

스위치가 작동하려면 자동 주문을 중단하고 수동 주문에 동의해야 합니다. 그리고 스위치가 순서대로 차례로 이동하도록 양식에 넣으십시오.