1c wprowadzają obowiązek stosowania elementu formularza. Programowe dodawanie i edycja zarządzanych elementów formularzy

Platforma 1C:Enterprise umożliwia programowe dodawanie i zmianę elementów zarządzanego formularza. Zastanówmy się, dlaczego może to być potrzebne.

Modyfikacja oprogramowania formularza może być wymagana w kilku przypadkach:

• Podczas finalizowania standardowych konfiguracji, aby ułatwić późniejszą procedurę aktualizacji. W takim przypadku zmianie ulegnie jedynie moduł formularza. Moduły są znacznie łatwiejsze w aktualizacji niż formularze.
• Podczas wdrażania niektórych popularnych algorytmów. Przykładowo w podsystemie „Zakaz edycji szczegółów obiektu” można programowo utworzyć dla wszystkich obiektów podłączonych do podsystemu przycisk umożliwiający edycję szczegółów.
• Podczas wdrażania niektórych określonych algorytmów. Przykładowo w katalogu Nomenklatura tworzone są pola umożliwiające edycję dodatkowych szczegółów.

W formularzu zarządzanym możesz programowo dodawać, zmieniać i usuwać:

• przybory;
• zespoły lokalne;
• elementy.

Wszystkie te operacje są możliwe tylko na serwerze.

Programowe przekształcanie ma ograniczenia:

• Możesz usuwać tylko programowo dodane szczegóły/polecenia/elementy. Nie można programowo usuwać obiektów utworzonych w konfiguratorze.
• Nie można przypisać atrybutu jako głównego.

Zmiana poleceń formularza

Aby zarządzać kompozycją poleceń dla obiektu Zarządzany formularz jest kolekcja Zespoły

Dodać (< ИмяКоманды >)

Ilość ()

Znajdować (< ИмяКоманды >)

Usuwać (< Команда >)

Kolekcja Teams jest dostępna zarówno na kliencie, jak i na serwerze. Kolekcję (metody Add() i Delete()) można zmienić tylko na serwerze. Możesz wyszukiwać i pobierać liczbę elementów (metody Find () i Count ()) zarówno na kliencie, jak i na serwerze.

Jako przykład pracy z poleceniami formularzy utwórzmy nowe polecenie ChangeHistory z nagłówkiem „ChangeHistory...”, które wywoła procedurę obsługi Historia wyświetlania(). Utworzenie następuje w momencie otwarcia formularza.

&Na serwerze
Procedura WhenCreatingOnServer (awaria, przetwarzanie standardowe)
Zespół = Zespoły. Dodać( „Historia zmian”);
Zespół . Akcja = ;
Zespół . Tytuł = „Historia zmian…”;
Koniec procedury
&Na kliencie
Procedura Connectable_DisplayHistory (polecenie)
// polecenia akcji
Koniec procedury

Procedura obsługi poleceń musi znajdować się w formularzu i mieć dyrektywę kompilacji &OnClient.

Zmiana szczegółów formularza

Odczytanie składu szczegółów formularza odbywa się za pomocą funkcji Uzyskaj szczegóły(< Путь >) zwracającą tablicę typu FormAttributes. Parametr funkcji określa ścieżkę do atrybutu nadrzędnego (w postaci ciągu znaków). Jeśli parametr zostanie pominięty lub określono pusty ciąg znaków, zwracane są szczegóły najwyższego poziomu.

Zmiana szczegółów odbywa się za pomocą metody Zmień szczegóły(<Dodano szczegóły>, <Usuwalne detale>) obiekt Zarządzany formularz. Do parametrów Dodano szczegóły I Usuwalne detale Przesyłane są tablice z elementami typu Form Attributes.

Uwaga!

Proces zmiany składu detali wymaga dużych zasobów. Formularz jest aktualnie odtwarzany. W związku z tym praca ze szczegółami formularza odbywa się w trybie wsadowym.

Utwórzmy nowy atrybut formularza o nazwie Kupujący:

AddedDetails = Nowa tablica;
Dodano szczegóły. Dodaj (nowe atrybuty formularza(„Kupujący”, Opis Nowego Typu („DirectoryLink. Kontrahenci”), „Klient”);

// Zmiany w kompozycji szczegółów
);

Zmiana elementów formularza

Aby kontrolować skład elementów obiektu Zarządzany formularz jest kolekcja Elementy. Kolekcja ma kilka metod:

Wstawić (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Dodać (< Имя>, < ТипЭлемента>, < Родитель >)

Ilość ()

Znajdować (< Имя >)

Przenosić(< Элемент>, < Родитель>, < МестоРасположения >)

Usuwać (< Элемент >)

Kolekcja Items jest dostępna zarówno na kliencie, jak i na serwerze. Zmodyfikuj kolekcję (Wstaw metody () , Dodaj (), Przenieś () i Usuń ()) są dostępne tylko na serwerze. Możesz wyszukiwać i pobierać liczbę elementów (metody Find () i Count ()) zarówno na kliencie, jak i na serwerze. Elementami kolekcji mogą być:

• Grupa formularzy;
• Tabela formularzy;
• Pole formularza;
• Przycisk formularza.

Można programowo przypisać procedury obsługi zdarzeń do elementów formularza. Do tych celów przeznaczona jest metoda UstawAkcję(< ИмяСобытия>, < Действие >) .

Przyjrzyjmy się niektórym z najczęstszych przykładów pracy z poleceniami, szczegółami i elementami formularzy.

Dodanie polecenia i powiązanego z nim przycisku:

// Utwórz polecenie
Zespół = Zespoły. Dodać( „Historia zmian”);
Zespół . Akcja = „Historia_wyświetlania wtyczki”; // Formularz musi zawierać procedurę o podanej nazwie
Zespół . Nagłówek = „Historia zmian…”;
// Utwórz przycisk i powiąż go z poleceniem
Element = Przedmioty. Dodać( „Historia zmian”, Type("FormButton" ));
Element.Nazwa Polecenia = „Historia zmian”;

Dodanie atrybutu i powiązanego pola wejściowego:

// Opis dodanych szczegółów
AddedDetails = Nowa tablica;
Dodano szczegóły. Dodać(Nowe rekwizyty formularza („Kupujący”, Nowy opis typu ( „DirectoryLink. Kontrahenci”), "Klient" ));
// Zmiana kompozycji szczegółów
Zmień szczegóły (dodano szczegóły);
// Tworzenie pola wejściowego i łączenie z atrybutami
Element = Przedmioty. Add("Kupujący" , Typ("PoleForm" ));
Element . Widok = FormFieldView. Pole wejściowe;
Element . Ścieżka do danych= „Kupujący”;

Przypisywanie obsługi zdarzeń do elementu formularza:

PozycjaKlient. Ustaw akcję(„Kiedy to się zmieni”, „Connected_BuyerOnChange”);

&Na kliencie
Procedura Connected_BuyerOnChange(Element)
// Akcje zdarzenia
Koniec procedury

Uwaga!

Procedury ustawione jako procedury obsługi zdarzeń z kodu przy użyciu metody UstawAkcję(), zaleca się ustawienie przedrostka Connectable_.

Uwaga!

Możesz pobrać obróbkę z przykładami programowego wyszukiwania i zmiany szczegółów, poleceń i elementów zarządzanego formularza.

Oraz obiekt przesyłania danych do struktury kodu, kontrolowana forma w środowisku 1C 8.2.

Wstęp

W 2008 roku udostępniona została nowa wersja platformy 1C: Enterprise 8.2 (zwana dalej Aplikacją Zarządzaną), która całkowicie zmienia całą warstwę pracy z interfejsem. Obejmuje to interfejs poleceń, formularze i system okien. Jednocześnie zmienia się nie tylko model rozbudowy interfejsu użytkownika w konfiguracji, ale zaproponowana jest także nowa architektura rozdzielająca funkcjonalność pomiędzy aplikacją kliencką a serwerem.
Zarządzana aplikacja obsługuje następujące typy klientów:

• Gruby klient (normalny i zarządzany tryb uruchamiania)
• Cienki klient
• Klient sieciowy

• Deklaratywny, a nie „piksel po pikselu” opis struktury. Konkretne rozmieszczenie elementów następuje automatycznie po wyświetleniu formularza.
• Cała funkcjonalność formularza opisana jest jako Detale I zespoły. Szczegóły to dane, z którymi współpracuje formularz, a polecenia to czynności, które należy wykonać.
• Formularz działa zarówno na serwerze, jak i na kliencie.
• W kontekście klienta prawie wszystkie typy aplikacji są niedostępne, w związku z czym niemożliwa jest zmiana danych w bazie danych.
• Dla każdej metody lub zmiennej formularza należy ją określić dyrektywa kompilacji, określenie miejsca wykonania (klient lub serwer) i dostęp do kontekstu formularza.

• &Na kliencie
• &Na serwerze
• &Na serwerzeBez kontekstu
• &OnClientOnServerBez kontekstu

Wszystkie dalsze dyskusje będą dotyczyły prawej strony ilustracji, tego, jak ustrukturyzować kod modułu i jakie zasady pozwolą na wdrożenie efektywnej interakcji klient-serwer.

Zdefiniujmy problem

Przyjrzyjmy się strukturze kodu (modułowi formularza) w kilku postaciach tej samej standardowej konfiguracji i spróbujmy znaleźć wzorce.
Przez strukturę rozumiemy fragmenty kodu (najczęściej są to bloki komentarzy) przydzielane przez programistę metodom grupującym i dyrektywom kompilacji dla tych metod.
Przykład 1:
Sekcja procedur obsługi zdarzeń Metoda - na kliencie Metoda - na serwerze Metoda - na kliencie Sekcja procedur i funkcji serwisowych Funkcje sterujące wejściami pomocniczymi
Przykład 2:
Procedury i funkcje serwisowe Dokumenty płatnicze Wartości Obsługa zdarzeń
Przykład 3:
Procedury serwisowe na serwerze Procedury serwisowe na kliencie Procedury serwisowe na serwerze bez kontekstu Obsługa zdarzeń nagłówkowych Obsługa zdarzeń poleceń
Przykład 4:
Procedury ogólnego przeznaczenia Obsługa zdarzeń formularzy Procedury podsystemu „informacje kontaktowe”.
Zasadniczo brakuje struktury kodu, lub delikatnie mówiąc, jest ona podobna do tej, która była w Forms 8.1:

• Słowa niemające charakteru informacyjnego „Ogólne, służbowe, pomocnicze”.
• Nieśmiałe próby oddzielenia metod klienta i serwera.
• Metody są często pogrupowane według elementów interfejsu „Praca z częścią tabelaryczną Produkty, Informacje kontaktowe”.
• Dowolny układ metod i grup kodów. Na przykład moduły obsługi zdarzeń mogą znajdować się na górze w jednym formularzu, na dole w innym, w ogóle nie podświetlone w trzecim itd.
• I nie zapominajmy, że to wszystko w ramach jednej konfiguracji.
• Tak, istnieją konfiguracje, w których słowa „Ogólne, Służbowe, Pomocnicze” są zawsze w tych samych miejscach, ale…

Dlaczego potrzebujesz struktury kodu?

• Uproszczenie konserwacji.
• Uprość naukę.
• Zapisywanie ogólnych/ważnych/skutecznych zasad.
• ...Twoja opcja

Dlaczego istniejący standard programistyczny od 1C nie pomaga?

• Zminimalizuj liczbę wywołań serwera.
• Maksymalna moc obliczeniowa na serwerze.
• Niekontekstowe wywołania serwera są szybsze niż kontekstowe.
• Program z myślą o komunikacji klient-serwer.
• i tak dalej.

Wzorce projektowe czyli mądrość pokoleniowa

• Zdalna fasada(zwany dalej Interfejsem Zdalnego Dostępu)
• Obiekt przesyłania danych(zwany dalej Obiektem Przekazywania Danych)

• … Każdy obiekt potencjalnie przeznaczony do zdalnego dostępu musi posiadać interfejs o niskiej szczegółowości, co zminimalizuje liczbę połączeń wymaganych do wykonania określonej procedury. ... Zamiast żądać faktury i wszystkich jej pozycji osobno, musisz przeczytać i zaktualizować wszystkie pozycje faktury w jednym żądaniu. Ma to wpływ na całą strukturę obiektu... Pamiętaj: interfejs zdalnego dostępu nie zawiera logiki domeny.
• ...gdybym była troskliwą mamą, zdecydowanie powiedziałabym mojemu dziecku: „Nigdy nie pisz obiektów do przesyłania danych!” W większości przypadków obiekty przesyłania danych to nic innego jak nadęty zestaw pól... Wartość tego obrzydliwego potwora leży wyłącznie w możliwości przesyłać wiele informacji przez sieć podczas jednego połączenia- technika mająca ogromne znaczenie w przypadku systemów rozproszonych.

Przykłady szablonów na platformie 1C

W kontekście zarządzanego formularza istnieje wiele „obiektów przesyłania danych”. Możesz wybrać systemowe I zdefiniowane przez programistę.
Systemowe modelują obiekt aplikacji na kliencie w postaci jednego lub większej liczby elementów danych formularza. Nie da się ich utworzyć bez odniesienia się do szczegółów formularza.

• Struktura formularzy danych
• Kolekcja DataForms
• DataFormStructureWithCollection
• Drzewo kształtów danych

• WartośćWFormieDane()
• WartośćDanychFormularza()
• KopiujDaneFormularza()
• ValueInFormAttributes()
• Atrybuty formularzaWartość()

Obiekty przesyłania danych, których strukturę ustala programista, stanowią niewielki podzbiór typów dostępnych zarówno po stronie klienta, jak i serwera. Najczęściej jako parametry i wyniki metod interfejsu „zgrubnego” wykorzystuje się:

• Typy pierwotne (string, number, boolean)
• Struktura
• Korespondencja
• Szyk
• Linki do obiektów aplikacji (unikalny identyfikator i reprezentacja tekstowa)

Strukturyzacja kodu

• Wyraźne oddzielenie kodu klienta i serwera. Nie zapominajmy, że w momencie realizacji są to dwa oddziałujące na siebie procesy, z których każdy znacząco różni się dostępną funkcjonalnością.
• Czytelna identyfikacja interfejsu zdalnego dostępu, które metody serwera można wywołać od klienta, a które nie? Nazwy metod interfejsu zdalnego zaczynają się od przedrostka „Serwer”. Dzięki temu w trakcie odczytywania kodu od razu widać przekazanie kontroli na serwer, a także ułatwia korzystanie z pomocy kontekstowej. Należy pamiętać, że oficjalna rekomendacja (ITS) sugeruje nazewnictwo metod z przyrostkami, na przykład ChangeOrderStatusOnServer(). Powtarzamy jednak, że nie wszystkie metody serwera można wywołać z klienta, dlatego ważniejsza jest dostępność logiczna, a nie lokalizacja kompilacji. Dlatego przedrostkiem „Serwer” oznaczamy jedynie metody dostępne dla klienta, nazwijmy przykładową metodę ServerChangeOrderStatus().
• Czytelność. Kwestia gustu, zamówienie przyjmujemy gdy moduł zaczyna się od procedur tworzenia formularza na serwerze i metod zdalnego dostępu.
• Łatwość konserwacji. Musi być jasne miejsce na dodanie nowego kodu. Co ważne, na końcu modułu dodawane są szablony metod tworzone automatycznie przez konfigurator. Ponieważ procedury obsługi zdarzeń dla elementów formularza są najczęściej tworzone automatycznie, odpowiedni blok jest umieszczany na końcu, aby nie przeciągać każdej procedury obsługi w inne miejsce w module.

• Opcja graficzna – wyraźnie pokazuje główny przebieg wykonania.
• Opcja tekstowa jest przykładem projektu szablonu umożliwiającego szybkie wstawienie struktury do nowego modułu formularza.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Data=""/> // <Описание> // // /////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////////////// ////////// // NA SERWERZE //********** ZDARZENIA NA SERWERZE ********** &Na serwerze Procedura w przypadku utworzenia na serwerze (awaria, przetwarzanie standardowe) ///////////// /wstaw zawartość procedury obsługi Koniec procedury //********** INTERFEJS ZDALNEGO DOSTĘPU ******* //********** LOGIKA BIZNESOWA NA SERWERZE ******* ///////// /////////////////////////////////////// /////// /////////////////// // WSPÓLNE METODY KLIENTA I SERWERA /////////////// /////// //////////////////////////////////////// ///// //////// // NA KLIENCIE //********** LOGIKA BIZNESOWA NA KLIENCIE ********** //********** ZESPÓŁ * ****** //********** WYDARZENIA KLIENTA ********** ////////////////////////// ///// ////////////////////////////////////////// // / / GŁÓWNE OPERATORY PROGRAMÓW

Powiązane pytania

• Opcje implementacji interfejsu zdalnego dostępu. Asynchronia, poziom szczegółowości...
• Buforowanie. 1C podjął nieudaną decyzję architektoniczną, wprowadzając buforowanie tylko na poziomie wywoływania metod wspólnych modułów i nie zapewniając możliwości kontroli (czas istotności, resetowanie na żądanie).
• Niejawne wywołania serwera. Nie zapomnij o funkcjach technologicznych, wiele „nieszkodliwych” operacji na kliencie prowokuje platformę do kontaktu z serwerem.

1. Pole wejściowe
2. Pole wyboru
3. Przełącznik

Pole wejściowe

Z reguły pole wejściowe jest powiązane z atrybutem obiektu i odzwierciedla jego dane. Jest to prawdopodobnie jeden z najczęstszych elementów. Istnieje kilka sposobów wyboru wartości:

Wybieranie z listy (Tryb wyboru z listy)

Wybór z innego formularza (przycisk Wybierz)

Przyciski sterujące

Implementacja powyższych przykładów nie wymaga dużego wysiłku ze strony programisty. np. dla trybu listy konieczne jest wypełnienie listy elementu wartościami, aby dokonać wyboru z innego formularza wystarczy po prostu powiązać element kontrolny z danymi katalogowymi. Ale w przypadku przycisków sterujących będziesz musiał napisać więcej kodu, aby przetworzyć kliknięcia każdego przycisku, chociaż nie będzie on duży:

Procedura pvWybór nomenklaturyRegulacja (element, kierunek, standardowe przetwarzanie)
//Wybierz dane do pola wejściowego
// w tym przypadku katalog Nomenklatura
Żądanie = Nowe żądanie;
Żądanie.Tekst=
"WYBIERAĆ
| Nomenklatura. Link jako produkt
|OD
| Katalog.Nomenklatura AS Nomenklatura
| ZAMÓW PRZEZ
| Nomenklatura.Kod";
TZNomenklatura = Request.Run().Upload();

//poszukaj bieżącego elementu katalogu określonego w polu wejściowym
CurrentElement = TZNomenclature.Find(Element.value);

Jeśli TechElement = Niezdefiniowany, to
// jeśli element nie zostanie znaleziony, ustaw numer indeksu
// poza tabelą wartości, ponieważ pierwszy element w
// tabela wartości ma indeks 0
Indeks Technologiczny = -1;
W przeciwnym razie
// jeśli element zostanie znaleziony, otrzymamy jego indeks
TechIndex = TZNomenclature.Index(TechElement);
koniecJeśli;

// oblicza nowy indeks w zależności od naciśnięcia przycisku
// minus przed zmienną Kierunek jest umieszczony tak, że kiedy
// kliknięcie górnej strzałki wyświetliło element znajdujący się nad nim
// i dlatego z mniejszym indeksem
NewIndex = Kierunek TechIndex;

// pobierz liczbę elementów w katalogu
// odejmij jeden, ponieważ wszystkie kolekcje w wersji 8.1 zaczynają się od 0
Liczba elementów = TZNomenklatura.Quantity()-1;

Jeśli NovIndex< 0 Или НовИндекс >Liczba elementów następnie
// jeśli przy zmianie indeksu znajduje się poza tabelą wartości
// tj. jego liczba jest większa od największego indeksu lub mniejsza od 0
// nie zmieniaj wartości i poinformuj o tym użytkownika
Notify("Osiągnąłeś limit katalogów");
W przeciwnym razie
// przypisz nową wartość, „Produkt” to nazwa kolumny tabeli wartości
Element.wartość = TZNomenclature.Get(NewIndex).Product;
koniecJeśli;

Koniec procedury

Pole wyboru

W większości programów pole wyboru służy do wyświetlania dwóch stanów: zaznaczonego i niezaznaczonego. W 1c pole wyboru ma trzy stany, w trzecim stanie pole wyboru jest wyświetlane jako zaznaczone i jednocześnie zacienione. Te trzy stany są dostępne tylko wtedy, gdy dane pola wyboru są liczbą, a stany mają następujące znaczenie:

Przełącznik

Przełącznik służy do wybrania jednej wartości z niewielkiej liczby możliwych (najlepiej nie więcej niż pięć), a wartości nie można łączyć, np.: nadaje się do wyboru płci osoby. Inny przykład: załóżmy, że firma udziela jednego z 3 rabatów na produkt, a rabaty nie sumują się:

W tym przypadku wygoda korzystania z przycisków radiowych może polegać na tym, że każdy z nich może mieć jakąś wartość, którą ustawia się we właściwości „Wartość do wyboru”. A następnie „5% rabatu” może przechowywać wartość 5 lub 0,05.

Używając przełączników, należy pamiętać o trzech rzeczach:

Pierwszy przełącznik powinien mieć właściwość „FirstInGroup” (w tym przykładzie jest to przełącznik „5% Rabat”).

Przełączniki, które są w znaczący sposób powiązane z jedną grupą, powinny być ustawione w rzędzie podczas ustawiania kolejności przechodzenia, bez przerywania przez inne elementy formularza. Kolejność przechodzenia ustawia się z menu „Formularz -> Ustawianie kolejności przechodzenia”, w tym przykładzie wygląda to tak:

1. Typ wybranej wartości jest ustawiany dla przełącznika posiadającego właściwość „FirstInGroup”.

Rozwój interfejsu w 1C składa się z dwóch części - opracowania menu lub pulpitu oraz opracowania formularzy ekranowych 1C. Okna, z którymi użytkownik pracuje w 1C, nazywane są formularzami ekranowymi 1C lub po prostu formularzami 1C.

Użytkownicy programu pracują z formularzami 1C. Ponadto użytkownicy widzą tylko formularze 1C. Dlatego z punktu widzenia łatwości obsługi w programie jest to jeden z istotnych elementów. Jednocześnie możesz zmarnować więcej czasu na opracowanie formularza 1C niż programowanie najbardziej złożonego algorytmu.

Częstym błędem popełnianym przez programistów jest próba narysowania wszystkiego tak, jak im się podoba. Zmień tło na niebieskie, a tekst na zielony. Lub żółty na czarnym. Albo jak mu się podoba w innym ulubionym programie.

Niestety takie podejście jest błędne, ponieważ użytkownicy są przyzwyczajeni do pracy ze standardowymi formularzami 1C, które stanowią większość w konfiguracji. Rysowanie własnego roweru i oznaczanie go napisami kurierskimi w stylu „Copyright Vasya Pupkin” jest wyraźnie w złym guście.

Teraz przejdziemy przez krótki program edukacyjny na temat rysowania formularzy 1C.

Co to są formularze 1C

Formularz 1C to metoda prezentacji użytkownikowi. Zazwyczaj formularz składa się z szeregu pól, które należy wypełnić oraz zestawu przycisków (poleceń menu) którymi można sterować. Większość obiektów 1C ma formę 1C.

Gruby klient 1C używa „zwykłych” formularzy 1C. Oznacza to, że programista po prostu rysuje myszką formularz 1C, tak jak dzieje się to w Visual Studio i innych frameworkach.

Cienki klient 1C i klient sieciowy 1C korzystają z zarządzanych formularzy 1C. Oznacza to, że ich rozmiaru, kształtu 1C i położenia na nich pól nie można zmieniać za pomocą myszki. Są one generowane automatycznie na podstawie ustawień. W kolejnych lekcjach porozmawiamy o zarządzanych formularzach 1C.

Większość form standardowych konfiguracji 1C w 1C ma własną standardową prezentację, znaną użytkownikowi.

Jak działają formularze 1C

Logika (kolejność) pracy użytkownika w 1C jest następująca:

Dlatego użytkownik zawsze pracuje z formularzami 1C, zaczynając od formularza listy 1C i przechodząc do formularza elementu 1C. Jeśli programista nie narysował formularzy, wówczas 1C domyślnie generuje formularze. Brakuje im naturalnie idealnej urody i doskonałości, ale pozwalają pracować.

Automatycznie wygenerowany formularz listy 1C zawiera zwykle minimalną liczbę pól (odpowiednio kod/nazwa i data/numer). Automatycznie wygenerowany formularz elementu zawiera zazwyczaj wszystkie pola (szczegóły) wymienione od góry do dołu.

Zadaniem formularza 1C jest otwarcie i oczekiwanie na działania użytkownika. Działając, reaguj. Zatem podstawą modułu formularza 1C są procedury obsługi zdarzeń. Są to funkcje wywoływane, gdy użytkownik wykonuje jakąś akcję w formularzu 1C.

Gdzie znajdują się formularze 1C?

W trybie 1C Enterprise, gdy wybierzesz prawie dowolny obiekt 1C (katalog, dokument, raport, przetwarzanie itp.), otworzy się forma tego obiektu.

W konfiguratorze w oknie konfiguracji wybierz potrzebny obiekt, rozwiń jego gałąź, aby zobaczyć podgałąź 1C Form.

Inną opcją jest otwarcie edytora obiektów (dwukrotnie myszą lub umieszczenie kursora i Enter) i przejście do zakładki Formularze 1C.

Oto lista formularzy 1C. Jeden z dodanych formularzy 1C można dodać jako formularz domyślny (formularz listy 1C, formularz elementu 1C itd.).

Tworzenie formularzy 1C

Aby dodać nowy formularz 1C, kliknij przycisk Dodaj (Ins na klawiaturze). Aby wejść do istniejącego, kliknij go dwukrotnie myszką.

Projektant poprosi Cię o wybranie typu formularza 1C - formularza elementu 1C, listy. Tutaj możesz dodawać lub usuwać panele poleceń w formularzu 1C. Najczęściej te ustawienia są domyślnie pozostawiane bez zmian.

Otworzy się formularz 1C, domyślnie wypełniony - dodano do niego wszystkie szczegóły istniejącego obiektu 1C. Konkretną listę wymaganych pól możesz zaznaczyć na drugiej zakładce projektanta.

Niepotrzebne szczegóły można usunąć. Aby to zrobić, wybierz jedno lub więcej pól i naciśnij Del.

Aby przenieść inne detale w wolną przestrzeń, zaznacz je w ten sam sposób i przeciągnij myszką.

Aby dodać nowe szczegóły do ​​formularza 1C, kliknij przycisk w panelu Umieszczenie danych (menu Umieszczenie formularza/danych), zaznacz pola obok elementów, które należy dodać, a także „Wstaw etykiety” i „Umieść automatycznie” pola wyboru.

Alternatywnie możesz po prostu dodać kontrolkę, klikając odpowiedni przycisk na panelu poniżej lub wybierając z menu opcję Formularz/Wstaw kontrolkę. Kliknij dwukrotnie element kontrolny (pole) lewym przyciskiem myszy, a otworzą się jego właściwości. Właściwość „Data” zawiera nazwę atrybutu. Tutaj możesz to zmienić lub przypisać.

Właściwości kontrolki zawierają również pola wyboru umożliwiające kontrolowanie wyglądu kontrolki. Możesz użyć pól wyboru, aby włączyć lub wyłączyć przyciski wyboru, rozwijania, czyszczenia, widoczności i ułatwień dostępu.

Prawie wszystkie formularze dokumentów korzystają z zakładek. Dodanie zakładki przebiega tak samo, jak dodanie kolejnej kontrolki (patrz wyżej), wystarczy wybrać kontrolkę „Panel”. Aby dodać stronę panelu, kliknij ją prawym przyciskiem myszy i wybierz opcję Dodaj stronę. Inne kontrolki (pola) można po prostu przeciągnąć i upuścić na strony panelu.

Aby zmienić rozmiar formularza 1C, po prostu przesuń kursor na krawędź formularza 1C, kliknij lewym przyciskiem myszy i po prostu przeciągnij krawędź formularza 1C.

Aby formularz 1C działał - tj. zrobił coś w odpowiedzi na działania użytkownika - musisz dodać funkcje obsługi. Wprowadź właściwości dowolnego elementu (klikając dwukrotnie lewym przyciskiem myszy) lub samego formularza 1C (podobnie w nagłówku formularza). Na samym dole okna właściwości znajduje się sekcja „Zdarzenia”. Wybierz wygodne wydarzenie (dla wszystkich pól jest to zazwyczaj „Przy zmianie”, dla formularza „Po otwarciu”) i kliknij przycisk z lupą. Otworzy się jego moduł obsługi zdarzeń.

W przypadku przycisków dodawanie przebiega tak samo. Jednak oprócz dowolnych procedur obsługi, dla tego formularza możesz wybrać jeden ze standardowych (dla formularza katalogu są to niektóre standardowe akcje, dla formularza dokumentu - inne). Po prostu wybierz jedną ze standardowych akcji we właściwości „Akcja” lub kliknij krzyżyk, jeśli chcesz stworzyć własny moduł obsługi.

Prawdopodobnie żaden algorytm nie jest w stanie uchronić bazy danych przed błędami pojawiającymi się przy wprowadzaniu danych przez użytkowników. Główne problemy związane z nieuwagą człowieka można zidentyfikować na poniższej liście:

• Zły wybór obiektu;
• Nieprawidłowa ilość lub literówka w nazwie;
• Powielanie elementów katalogu, ich niepowtarzalność lub błędne sortowanie;
• Ignorowanie wypełniania pól kluczowych dla prawidłowego obliczenia i płynnego działania programu.

Rozwiązaniem ostatniego problemu jest sprawdzenie w ósmej wersji programu 1C, czy dane formularza są wypełnione.

Sprawdzanie wypełnienia zwykłego formularza

Gdy użytkownik otworzy formularz, jeśli tryb uruchamiania to „Normalna aplikacja”, wymagane elementy są podświetlone czerwoną przerywaną linią (rys. 1).

Jak widać z powyższego przykładu wymagane pola w dokumencie „Sprzedaż towarów i usług” to „Numer” i „Kontrahent”. W takim przypadku pole „Numer” nie jest dostępne do edycji. Oznacza to, że w przypadku zarejestrowania dokumentu w bazie informacji zostanie on automatycznie uzupełniony zgodnie z zasadami numeracji określonymi dla tej organizacji.

Zapisanie pozycji w katalogu lub zaksięgowanie dokumentów zawierających niewypełnione wymagane pola spowoduje wyjątek (rys. 2).

Ryż. 2

Bardziej szczegółowe informacje o tym, które pole nie zostało wypełnione, znajdziesz w oknie komunikatów serwisowych.

Sam znak informujący o konieczności wypełnienia pola ustawiany jest we właściwościach elementu formularza. Dla tego:

1. Otwórz formularz w Konfiguratorze;
2. Kliknij prawym przyciskiem myszy element formularza i otwórz okno „Właściwości”;
3. Należy zaznaczyć checkboxy AutoMark Unfilled i AutoSelect Unfilled w podmenu „Use” (rys. 3);

Weryfikacja bezpośrednia z reguły jest zapisana w module obiektowym.

W przypadku spisów i dokumentów niewysłanych wskazane jest wywołanie procedury sprawdzania kompletności podczas rejestracji elementu. Dokumenty, które nie są całkowicie wypełnione, jeśli są przeprowadzane, można zapisać w bazie danych i lepiej wywołać procedurę weryfikacji przed utworzeniem ruchów, czyli podczas realizacji. Wskazane jest przeprowadzanie kontroli przetwarzania i raportów zawierających pola obowiązkowe bezpośrednio w przetwarzaniu kliknięcia przycisku.

Możesz sprawdzić czy wartość przekazana do pola różni się od pustej (wartość domyślna) korzystając z funkcji ValueFilled („Wartość”). Należy jednak pamiętać, że jeśli pole ma złożony typ danych, wykonanie tej funkcji spowoduje zgłoszenie wyjątku.

Walidacja w zarządzanych formularzach

Specyfika działania platformy w wersji klient-serwer również pozostawia swoje piętno na sprawdzeniu zapełnienia.

Najpierw musisz zrozumieć, jaka procedura następuje przy wejściu do obiektu w tym trybie działania.

Zatem po kliknięciu przycisku „Nagraj”, „OK”, „Podaj”:

1. Na kliencie wywoływana jest procedura „Przed nagraniem”;
2. Dane zostają przesłane do serwera i na serwerze zachodzą zdarzenia określone w module formularza (tutaj można uruchomić procedurę ProcessingFillingCheckOnServer);
3. Dane formularza przekazywane są do modułu obiektowego na serwerze (możliwe staje się uruchomienie standardowej procedury ProcessingCheckFill);
4. Dane z modułu zwracane są do modułu formularza na serwerze i następuje procedura BeforeWritingOnServer;
5. Dane są zwracane do modułu obiektowego i następuje kolejna procedura BeforeWrite;
6. Obiekt jest zapisywany bezpośrednio do bazy danych.

W dowolnym miejscu diagramu można wstawić funkcję CheckFill(). Po przejrzeniu szczegółów, we właściwościach których atrybut „Sprawdzenie wypełnienia” ma wartość „Podaj błąd” (ryc. 4), funkcja ta, jeśli chociaż jeden z nich nie zostanie wypełniony, zwróci „Fałsz” .

Różnice między procedurami obsługi ProcessingFillCheck() i ProcessingFillCheckOnServer().

Ze względu na to, że interfejs zarządzanej aplikacji może zawierać zarówno szczegóły obiektu, jak i bezpośrednio szczegóły formularza, te dwie procedury są rozdzielone. Jednocześnie mają podobne parametry, które można przekazać do procedur obsługi:

1. Odmowa (wynik kontroli jest przesyłany tutaj);
2. Sprawdzone Szczegóły (typ danych – tablica, jeśli nie zostaną wypełnione, to sprawdzone zostaną wszystkie szczegóły, dla których we właściwościach ustawiono opcję „Sprawdź wypełnienie”, w przeciwnym razie przetworzone zostaną wybrane programowo szczegóły).

Procedura ProcessingFillingCheckOnServer() umożliwia sprawdzenie szczegółów nie związanych bezpośrednio z edytowanym obiektem. Każdy programista sam decyduje, co i w jakim zakresie chciałby sprawdzić.

Procedura ProcessingCheckFill() sprawdza podstawowe szczegóły.