1c afișează un mesaj în fereastră. Mesaje către utilizator în formulare gestionate (din nou). Mesaje legate de atributul părții tabulare a obiectului

În programele de pe platforma 1C:Enterprise, un mesaj poate fi afișat utilizatorului în diferite moduri.

1. Metoda ShowWarning.

Afișează avertisment(< ОписаниеОповещенияОЗавершении> , < ТекстПредупреждения> , < Таймаут> , < Заголовок> )

Când utilizați acest design, o fereastră de avertizare apare în centrul interfeței programului.

Parametri:

Descriere Alerte complete(optional)
Tip: Descriere Alerte. Conține o descriere a procedurii care va fi apelată după închiderea ferestrei de alertă cu următorii parametri: Parametri suplimentari - valoarea care a fost specificată la crearea obiectului Alert Description. Dacă parametrul nu este specificat, atunci la finalizare nu va fi apelată nicio procedură.

Text de avertizare(necesar)
Tip: Snur; FormattedString. Text de avertizare.

Timeout (opțional)
Tip: Număr. Intervalul de timp în secunde în care sistemul va aștepta răspunsul utilizatorului. Când intervalul expiră, fereastra de avertizare va fi închisă. Dacă parametrul nu este specificat, atunci timpul de așteptare este nelimitat. Dacă parametrul este negativ, va fi aruncată o excepție. Valoare implicită: 0.

Titlu (opțional)
Tip: șir. Conține titlul ferestrei de avertizare. Descriere: Afișează o fereastră de avertizare, dar nu așteaptă să se închidă.

Disponibilitate: client subțire, client web, client gros, aplicație mobilă (client).

Notă: Dacă orice cod trebuie executat după ce utilizatorul închide fereastra de avertizare, acesta trebuie plasat într-o procedură de modul separată și descris într-un parametru.

2. Avertisment de metodă.

O fereastră de avertizare apare în centrul interfeței programului. Cu toate acestea, dacă proprietatea de configurare Mod de utilizareModalitate este setat la Nu folosiți, atunci metoda nu funcționează.

Disponibilitate: client subțire, client web, client mobil, client gros, aplicație mobilă (client).

3. Metoda ShowUserAlert.

ShowUserAlert(< Текст> , < ДействиеПриНажатии> , < Пояснение> , < Картинка> , < СтатусОповещенияПользователя> , < КлючУникальности> )

Când utilizați această metodă, apare un mesaj în colțul din dreapta jos al interfeței.

Disponibilitate: client subțire, client web, client gros.

4. Metoda raportului.

Raport(< ТекстСообщения> , < Статус> )

Disponibilitate: client subțire, client web, client mobil, server, client gros, conexiune externă, aplicație mobilă (client), aplicație mobilă (server).

5. Obiect Mesaj pentru utilizator.

Proiectat pentru a stoca parametrii de mesaj care trebuie afișați utilizatorului. Dacă mesajul nu a fost încă afișat utilizatorului (acest lucru se poate întâmpla atunci când lucrați pe partea de server, într-o lucrare de fundal, conexiune externă sau servicii Web), puteți obține mesajele acumulate folosind metoda Primiți mesaje către utilizator.

Proprietăți: ID destinație(TargetID); DataKey; Domeniu; DataPath(DataPath); Text.

Metode: Mesaj; SetData(SetData).

Mesajul apare în partea de jos a interfeței, într-o linie.

Mesaj = New MessageToUser(); Mesaj. Text =„Nomenclatură insuficientă” ; Mesaj. Câmp =

"Nomenclatură. Cantitate"

;

Mesaj. SetData(DataObject) ;

Mesaj. Raport () ;

• Articolul continuă seria articolelor „Primii pași în dezvoltare pe 1C”.
• În acesta, vom analiza metodele de informare a utilizatorului care sunt prezente în platforma 1C:Enterprise 8 și, de asemenea, vă vom concentra atenția asupra unora dintre caracteristicile de funcționare a acestor mecanisme sunt legate de modul de utilizare; modalitatea.
• Aplicabilitate

Articolul discută funcționalitatea:

Interfață în versiunea „Versiunea 8.2” pentru configurația dezvoltată pe platforma 1C:Enterprise 8.2.19.130

• Interfață taxi pentru configurație dezvoltată pe platforma 1C:Enterprise 8.3.4.496 până la 8.3.9+
• Interfață taxi pentru o configurație dezvoltată pe platforma 1C:Enterprise 8.3.10-8.3.11
• Cum să afișați un mesaj utilizatorului în 1C

Afișarea mesajelor în modul utilizator rezolvă o serie de probleme:

• reflectarea progresului procesului curent (afișarea stadiului procesului; afișarea valorilor calculate obținute în timpul funcționării algoritmului);
• afișarea erorilor către utilizator pentru o eventuală corectare;

emiterea de recomandări;

Mesajele introductive au scopul de a oferi utilizatorului anumite informații.

Este necesar ca utilizatorul să se familiarizeze cu acesta și, eventual, să întreprindă unele acțiuni care sunt descrise în acest mesaj.

Este foarte important ca utilizatorul să citească efectiv aceste mesaje, așa că acestea ar trebui să conțină doar informații importante.

Mesajele de testare și depanare nu ar trebui să fie emise utilizatorului, deoarece mai devreme sau mai târziu va începe să ignore absolut toate mesajele.

În conceptul de interfață gestionată, abordarea emiterii unui mesaj s-a schimbat oarecum. Acum este legat de forma în care a apărut. Nu mai poate fi închis, astfel încât textul să fie complet invizibil.

Nu puteți anula fixarea unei casete de mesaj dintr-un formular.

Sintaxa funcției:

Raport (<Текст сообщения>, <Статус>)

Aceste. primul parametru este textul în sine.

Al doilea parametru (starea mesajului) este opțional. Puteți specifica valori pentru starea: Normal, Important, Foarte important etc.

Această valoare determină ce pictogramă va fi amplasată lângă mesaj. Cu toate acestea, acest lucru funcționează numai în interfața normală.

În conceptul de interfață gestionată, pictograma este întotdeauna un semn de exclamare și nu poate fi suprascrisă.

Faptul este că dacă un mesaj este generat în momentul scrierii unui element de director, poate apărea următoarea situație.

Utilizatorul face clic pe un buton Salvați și închideți, in acest caz mesajul este afisat in fereastra corespunzatoare (in dreapta formularului).

Dar formularul se închide instantaneu, iar utilizatorul nu va vedea că a fost afișată nicio informație pentru el.

Prin urmare, în conceptul de aplicație gestionată, se recomandă afișarea mesajelor introductive folosind așa-numitele alerte. Un exemplu de utilizare incorectă a unei funcții Raport prezentate în figură.

Cu toate acestea, funcția Raport poate fi folosit pentru a afișa informații despre anumite erori, de exemplu, la momentul postării documentului.

În acest caz, sistemul poate fi informat că formularul nu trebuie să fie închis și să arate utilizatorului ce erori apar la postarea documentului.

Funcţie Raport pe deplin suportat în Platforma 8.3. Poate fi folosit și va funcționa (atât în ​​versiunea de fișier, cât și în versiunea client-server).

Dar trebuie remarcat și faptul că funcția Raport Există o dezvoltare ulterioară - aceasta este o clasă de mesaje pentru utilizator, care permite, pe lângă afișarea unui mesaj, să-l lege contextual la orice elemente de formular.

De exemplu, un mesaj de eroare poate fi legat de un element de formular, ceea ce este foarte clar pentru utilizator. Vom reveni să analizăm această problemă puțin mai târziu. Funcţie Raport există o caracteristică interesantă.

Astfel, codul programului din Platforma 8.3 poate fi executat atât pe partea Client, cât și pe partea Server.

În acest caz, codul programului client este responsabil pentru interacțiunea cu utilizatorul, adică. Pe partea clientului, se deschid formulare și sunt afișate rapoarte.

Diverse documente de dialog sunt, de asemenea, afișate numai pe client. Ele nu pot fi executate pe server deoarece serverul nu are capacitatea de a interacționa cu utilizatorii.

Dar funcția Raport poate fi executat atât pe partea Client cât și pe partea Server. În acest caz, utilizarea metodei Raport pe Server nu înseamnă deloc că mesajul va fi afișat pe Server, pur și simplu nu există unde să le afișeze.

Aceasta înseamnă că dacă afișăm un mesaj în procedura serverului folosind această metodă, ele se vor acumula într-un buffer și vor fi afișate pe ecran doar când procedura serverului se încheie și revine la Client.

În acest moment, sistemul va solicita date din buffer și le va afișa pe ecran.

Aceeași caracteristică se aplică clasei Mesaj pentru utilizator. Figura prezintă un exemplu de utilizare a metodei Raport pe partea Server.

Ca urmare a utilizării metodei Raport pe partea Server, mesajele au fost afișate pe ecran pe partea Client.

Este necesar un mecanism de alertă pentru a informa utilizatorul că „ceva” s-a întâmplat în sistem și că „ceva” necesită atenția utilizatorului. Alertele sunt generate de două scenarii:

1. Prin platforma în sine atunci când înregistrați sau schimbați interactiv un obiect
2. De către dezvoltator atunci când apelează o metodă din cod .

Notificarea în sine este o fereastră mică care apare, de regulă, în colțul din dreapta jos și informează despre acțiunea finalizată. În câteva secunde, se estompează și dispare treptat. În același timp, dacă treci cu cursorul mouse-ului peste notificare, aceasta nu dispare și o poți citi cu atenție.

În plus, alertele pot fi accesate în zona corespunzătoare a panoului de informații (butonul „Istoric” din partea stângă jos a formularului de cerere în opțiunea de interfață „Versiunea 8.2”).

Pentru a vă crea propriile alerte, trebuie să utilizați metoda contextului global ShowUserAlert(). Sintaxa sa înainte de versiunea 8.3.10 este prezentată mai jos:

Afișați alertă utilizator (<Текст>, <НавигационнаяССылка>, <Пояснение>, <Картинка>)

Primul parametru conține textul care va fi afișat în notificare.

Apoi, ca al doilea parametru, puteți trece un anumit link de navigare către orice element al bazei de informații (elementul care corespunde textului mesajului nostru). Când un utilizator face clic pe o alertă, linkul va fi urmat.

Folosind al treilea parametru, puteți transmite o explicație pentru mesaj, de exemplu. o descriere extinsă.

De asemenea, puteți aloca o imagine care afișează starea notificării.

Trebuie remarcat faptul că toți acești parametri sunt opționali. Mai jos este un exemplu de utilizare a acestei metode (în configurator și în modul utilizator în opțiunea de interfață „Versiunea 8.2”).

În versiunea platformei 8.3.10.216 pentru interfața „Taxi”, mecanismul de notificare a fost îmbunătățit semnificativ pentru a îmbunătăți gradul de utilizare atât a clientului subțire, cât și a clientului web. Din acest motiv, s-au modificat și parametrii trecuți metodei ShowUserAlert(). Acum sintaxa arată astfel:

ShowUserAlert(<Текст>, <ДействиеПриНажатии>, <Пояснение>, <Картинка>, <СтатусОповещенияПользователя>, <КлючУникальности>)

Se poate observa că al doilea parametru, numit anterior Legătură de navigație, a primit un nume nou ActionWhenClicked. Acest lucru se datorează faptului că acum este posibil să trimiteți nu numai un șir cu un link de navigare, ci și o descriere a alertei. Acest lucru este ilustrat în captura de ecran de mai jos:

După cum se poate vedea din exemplu, acum avem capacitatea de a procesa programatic un clic pe o fereastră de notificare, conform logicii necesare.

Următorul parametru Stare alertă utilizator a aparut pentru prima data. Indică starea alertei (Informații sau Important).

În cazul opțiunii Important, dacă utilizatorul nu a răspuns la mesaj, atunci după ce acesta este ascuns de pe ecran, acesta poate fi citit prin Centrul de notificare (mai multe despre el mai jos). În cazul opțiunii Informații, notificarea este ștearsă fără a fi stocată în acest centru. Să rescriem codul din exemplul nostru, după cum urmează:

După executarea comenzii, obținem aproximativ această vedere a ferestrei aplicației:

Un buton cu o pictogramă clopoțel a apărut în bara de instrumente, care apelează Centrul de notificare menționat mai sus. Acumulează noi alerte importante la care utilizatorul nu a răspuns încă.

Dacă există alerte în Centru, lângă el apare un mic punct portocaliu pentru a atrage atenția utilizatorului. Utilizatorul poate deschide Centrul de notificare, poate citi textul și, dacă este necesar, poate întreprinde unele acțiuni.

Din Centru, alerta este ștearsă făcând clic pe butonul de ștergere, dar dacă există o acțiune asociată cu alerta, atunci de îndată ce utilizatorul face clic pe textul mesajului, acesta va dispărea și el.

Și, în sfârșit, ultimul parametru adăugat a fost Cheia unicității. Îl puteți folosi pentru a găsi alerta afișată pe ecran și pentru a o modifica. Dacă nu există nicio alertă cu acest parametru, va fi afișată o nouă alertă.

După cum puteți vedea, posibilitățile oferite de metoda corespunzătoare au devenit și mai mari! Dar acestea nu sunt toate modificările în mecanismul de notificare.

După cum probabil ați observat deja, aspectul lor s-a schimbat. Alertele arată acum mai moderne și mai ergonomice, dar nu pot fi mutate pe ecran sau redimensionate. Vă rugăm să rețineți că, în exemplul nostru, textul de notificare pur și simplu nu s-a încadrat în întregime în fereastra în sine, iar utilizatorul îl va putea citi în întregime doar prin deschiderea Centrului de notificări. Prin urmare, nu ar trebui să scrieți o cantitate mare de text în textul de notificare.

Noile funcții includ, de asemenea, afișarea simultană a până la trei alerte pe ecran.

Aceasta încheie cunoștințele noastre cu generarea software-ului de alerte. Totuși, rețineți că alertele sunt generate nu numai de dezvoltator în mod programatic, ci și de platforma însăși în momentul înregistrării interactive sau al modificării unui obiect. Și adesea acest fapt provoacă neînțelegeri în primul rând în rândul utilizatorilor începători: de ce sunt necesare aceste alerte de serviciu, care, apropo, nu pot fi dezactivate?

Să ne imaginăm această situație simplă: utilizatorul a setat un filtru într-o listă pentru comoditate. Să presupunem că a făcut asta sub forma unei liste în directorul Nomenclatură. Apoi, după ceva timp, am decis să introduc un nou element numit „Scaun”, care nu corespunde filtrului instalat anterior. Intră în el, îl notează și...? Și nu o vede pe listă. Ce va face utilizatorul mediu? Desigur, va intra în el a doua oară, dar nu o va mai vedea. Aceasta poate fi urmată de a treia, a patra, a cincea oară. Când se sătura să intre în același lucru iar și iar, te va întreba în sfârșit: unde se duce totul?

Tocmai de aceea platforma afișează aceste alerte de service, informând utilizatorul că acțiunea sa a fost finalizată. În exemplul nostru, în momentul înregistrării interactive, utilizatorul va vedea următoarea notificare:

Mesaje de terminare

Mesajele de terminare sunt acele mesaje care nu vor permite lucrul până când utilizatorul efectuează anumite acțiuni, de ex. până când procesează mesajul.

Despre posibilitatea utilizării mesajelor de terminare în Platforma 8.3 vom vorbi puțin mai târziu (în ultimul timp au încercat să nu le folosească, așa că exemplul luat în considerare este mai relevant pentru Platforma 8.2).

Există două metode de emitere a mesajelor de terminare AvertizareŞi Întrebare. Avertizare diferit de Întrebare deoarece are un singur buton Bine.

O întrebare poate specifica seturi diferite de opțiuni de răspuns ( Nu chiar, DaNuAnulează, Bine, OKAnulează, RepetAnulare, AbortRepeatSkip), care sunt specificate cu ajutorul parametrului.

Să afișăm niște avertismente folosind linia (de exemplu, într-un modul de aplicație gestionată):

Avertisment(„Baza va fi acum deschisă”);

Pentru a deschide un modul de aplicație gestionat, selectați obiectul din arborele de configurare Configurare, apelați meniul contextual și selectați elementul Deschideți un modul de aplicație gestionat.

În acest caz, la lansarea aplicației, va fi afișată o fereastră care este modală. O fereastră modală se suprapune pe toate ferestrele care există în aplicație. Până când procesăm această fereastră, nu sunt posibile alte acțiuni.

Funcția funcționează într-un mod similar Întrebare.

Sintaxă:
Întrebare(<ТекстВопроса>,<Кнопки>,<Таймаут>,<КнопкаПоУмолчанию>,<Заголовок>,
<КнопкаТаймаута>);

Sunt necesari doar primii doi parametri. Pentru al doilea parametru, tipul de date este compus ( Modul de dialog Întrebare sau ListValues). Al treilea parametru ( <Таймаут> ) caracterizează intervalul de timp în secunde în care sistemul va aștepta răspunsul utilizatorului.

Când intervalul expiră, fereastra de întrebări va fi închisă. Parametru similar( <Таймаут> ) este prezentă și în funcție Avertizare.

Ca exemplu de utilizare a funcției Întrebare Puteți utiliza următorul cod, scris într-un modul de aplicație gestionat:

Vă rugăm să rețineți că aceste metode ( AvertizareŞi Întrebare) nu sunt disponibile pe server. Și acest lucru este logic, deoarece metodele de interfață nu pot fi executate pe un Server unde nu există utilizator.

Caracteristici de utilizare a ferestrelor modale în Platforma 8.3

În platforma 8.3, există moduri de operare cu și fără modalitate. Setarea implicită este Nu utilizați modul modality.

În acest caz, utilizarea mesajelor de reziliere este imposibilă. Dacă este necesar să folosiți mesaje de terminare (funcții AvertizareŞi Întrebare) ar trebui să modificați valoarea proprietății de configurare pe Utilizare.

Fereastra modală este afișată în partea de sus și blocurile funcționează cu alte ferestre până când acțiunile cu fereastra modală sunt finalizate. În plus, execuția codului programului se oprește în punctul în care este apelată această fereastră. Execuția codului va continua numai după ce fereastra modală este închisă.

În primul rând, apar probleme cu utilizarea ferestrelor modale pentru o aplicație mobilă. În al doilea rând, în browser, modalitatea ferestrelor este implementată folosind ferestre pop-up separate.

Ferestrele pop-up sunt adesea dezactivate prin setările implicite ale browserului. Utilizatorul trebuie să fie forțat să seteze permisiunea pentru aceste ferestre.

Browserele pentru tablete și telefoane în majoritatea cazurilor nu acceptă deloc ferestre pop-up.

Pentru a înlocui funcțiile ÎntrebareŞi Avertizare au fost dezvoltate noi metode: Afișează întrebarea, ShowWarning.

Aceste metode vă permit să apelați o fereastră, dar nu opresc execuția codului programului. Din punct de vedere tehnic, acest lucru se realizează prin formarea unei pseudo-fereastră în interiorul ferestrei părinte. Pseudo-fereastra nu se suprapune cu fereastra părinte. După deschiderea unei astfel de ferestre, codul continuă să se execute.

Primirea și procesarea valorilor introduse de utilizator se efectuează într-o procedură separată, care este numită atunci când caseta de dialog este închisă.

Sintaxa funcției ShowWarning:

Afișează avertisment(<ОписаниеОповещенияОЗавершении>, <ТекстПредупреждения>, <Таймаут>, <Заголовок>)

Parametru <ОписаниеОповещенияОЗавершении> (optional)

Tip de date: Descrierealerte.

Conține o descriere a procedurii care va fi apelată după închiderea ferestrei de avertizare.

Sintaxa funcției Afișează întrebarea:

Afișează întrebarea(<ОписаниеОповещенияОЗавершении>, <ТекстВопроса>, <Кнопки>, <Таймаут>, <КнопкаПоУмолчанию>, <Заголовок>, <КнопкаТаймаута>)

Primii trei parametri sunt necesari.

Mai jos este un exemplu de utilizare a funcției.

Clasa MessageToUser

Comoditatea de bază a clasei de mesaje Mesaj pentru utilizator este că acesta este un mesaj contextual (spre deosebire de metode AvertizareŞi Întrebare).

Mesajele pot fi legate de un anumit element de ecran. Acest obiect este disponibil și pe Server.

Vă rugăm să rețineți că, în primul rând, acest obiect trebuie creat. De exemplu: Mesaj = New MessageToUser;

Astfel creăm o instanță a acestui obiect.

În al doilea rând, trebuie să specificați textul mesajului într-o proprietate separată.

În al treilea rând, în proprietate Domeniu Puteți specifica la ce element de formular trebuie atașat acest mesaj.

Atenţie! Pentru a vă lega la câmpul de formular dorit, acordați atenție inițializării proprietăților PathToDataŞi DataKey. Pentru un document, atunci când plasați cod într-un modul obiect, puteți scrie:

Message.DataPath = „Obiect”;
Message.DataKey = ThisObject.Link;

Pentru a deschide modulul document, în fereastra de editare a obiectului (documentului), accesați fila Alte apăsați butonul Modul obiect.

Pentru experiment, vom plasa codul în modulul obiect al unui document.

Mai jos este rezultatul obținut în modul utilizator pentru Platforma 8.3.

Trebuie remarcat faptul că mesajele ies folosind noul obiect de sistem Mesaj pentru utilizatorîn cazul general nu încetează. Aceste. sistemul va permite utilizatorului să continue alte acțiuni fără a răspunde la mesajele afișate.

Dar, în primul rând, aceste mesaje sunt destul de vizibile. În al doilea rând, mesajele sunt de obicei afișate utilizatorului în momentul înregistrării elementelor directoarelor sau postării documentelor, adică atunci când se efectuează unele verificări. Și dacă au fost detectate erori, utilizatorul va vedea aceleași mesaje.

În consecință, atunci când sunt detectate erori, tranzacția este anulată, adică. scrierea unui element de director este interzisă sau postarea unui document este interzisă.

Astfel, apare un fel de emulare a mesajului de terminare. Deoarece acțiunea este anulată până când utilizatorul reacționează la mesajul introdus, va fi imposibil să finalizați acțiunea, de exemplu, postarea unui document.

Dar, pe de altă parte, este posibil să închideți documentul fără a-l conduce, fără a reacționa în vreun fel la mesaj. Prin urmare, aceste mesaje către utilizator nu se încheie.

Notificarea de stare proces

Există o funcție specială cu care puteți afișa progresul aproximativ al unui proces.

Sintaxă: Stat(<ТекстСообщения>, <Прогресс>, <Пояснение>, <Картинка>)
Parametri:<ТекстСообщения>Şi<Пояснение>– optional, tip – Linia.
Textul este afișat pe o bară de stare specială.
<Прогресс>Parametrul este, de asemenea, opțional, dar vizual.
Tip: Număr. Valoarea indicatorului de progres (de la 1 la 100).
<Картинка>de asemenea, un parametru opțional.
La procesarea oricărui eveniment, apelurile periodice ale unei funcții precum:

În acest caz, etichetele se pot schimba, iar valorile parametrului Progress se pot modifica.

O funcție poate fi apelată dintr-o procedură (funcție) sau din mai multe. În acest fel, puteți urmări starea de execuție a procesului.

Dacă doriți să aruncați o privire mai atentă asupra mecanismului de notificare, opriți-vă chiar acum și citiți noul nostru articol, Afișarea progresului operațiunilor de lungă durată în 8.3.10. Ea explică, nu mai la nivelul unui începător, toate subtilitățile și capcanele funcționării acestui mecanism.

Terminăm introducerea noastră cu privire la modalitățile de informare a utilizatorului. Sperăm că ați înțeles în ce situații ar trebui folosită una sau alta metodă.

Aș dori să vă atrag încă o dată atenția asupra faptului că, dacă configurația dvs. (versiunea 8.3.3+) implică lucrul cu un client web, atunci:

• la nivelul de configurare, setarea modului modalității trebuie să fie setată la „Nu utilizați”
• Codul trebuie să utilizeze metode ale modelului de interacțiune cu utilizatorul asincron. Astfel de metode încep cu cuvintele Spectacol sau ÎNCEPE.

Puteți citi mai multe despre refuzul de a utiliza ferestrele modale în platforma 1C:Enterprise 8.3 în articolul final al seriei. Și trecem mai departe și, în sfârșit, începem să studiem mult așteptata interfață Taxi, care a fost deja menționată de mai multe ori în materialele noastre.

Bună ziua.

Astăzi vom vorbi despre un lucru atât de simplu ca mesajele către utilizator.

ÎN 1C Metoda 8 a migrat de la 7.7 - " Raport(...)„. Această metodă este foarte simplă, deschide o fereastră de mesaj dacă nu este deschisă și adaugă acolo textul mesajului. Ca și în 1C 7.7, are un al doilea parametru care definește pictograma vizavi de mesaj. Această pictogramă determină importanța mesajului.

Pe măsură ce timpul a trecut, am primit forme controlabile în mâinile noastre. Formularele gestionate nu au o singură casetă de mesaje. Cu toate acestea, metoda este încă acceptată. În noua interfață, mesajele se lipesc de fereastra activă. Când trec la altă fereastră, mesajele dispar din vedere, dar când revin, apar din nou. În unele cazuri, acest lucru nu este convenabil, dar nu puteți face nimic în acest sens, un formular gestionat implică absența unei ferestre principale la care ar putea fi atașate mesajele.

Cu toate acestea, deoarece mesajul este asociat cu un formular specific, acest lucru permite autorilor platformei să extindă funcționalitatea unui mesaj simplu. Este posibil să fi văzut deja în configurațiile tipice că mesajele sunt acum integrative, făcând clic pe un mesaj ne poziționează pe un anumit câmp, dublu clic poate deschide un alt element al bazei de date.

Faptul este că acum se obișnuiește să se folosească nu metoda contextului global „Report(...)”, ci obiectul „ Mesaj pentru utilizator". Acest obiect este disponibil peste tot, atât pe client, cât și pe server. Are mai multe proprietăți și câteva metode.

În general, dacă trebuie să oferiți utilizatorului doar un mesaj, fără nicio interacțiune, atunci este suficient să scrieți:

Message.Message();

Aceste trei linii sunt absolut identice cu metoda pe care o cunoaștem deja și, prin urmare, utilizarea acestui obiect pentru un astfel de mesaj este inutilă.

Principalele câmpuri care extind capacitățile mesajului sunt:

• DataKey
• Domeniu

Cheie de date- un link către obiectul bazei de informații la care se referă acest mesaj sau o cheie de înregistrare. Asa scrie in certificat. Dacă punem aici un link către un document sau o carte de referință, atunci făcând dublu clic se va deschide acest obiect, indiferent de forma în care a fost afișat mesajul. În consecință, dacă mesajul apare sub forma unui document și cheia de date conține un link către acesta, atunci noul formular nu se va deschide.

Prostii se pot întâmpla dacă emitem un mesaj sub forma unui obiect care nu a fost încă notat. În acest caz avem un link gol. Dar platforma nu este pierdută și pur și simplu nu deschide nimic, adică. Rămâni în forma în care ai fost.

Domeniu- aceasta este o linie cu numele câmpului care trebuie activat. Și nu contează dacă forma altui obiect se deschide sau dacă rămânem în forma actuală.

Iată un exemplu despre cum funcționează:

Să presupunem că înainte de a scrie un element de director în modulul formular, verificăm unicitatea atributului „Id” și, dacă există deja, afișăm mesajul:

Dacă selectează.Next() Atunci
Refuza = Adevărat;
Mesaj = New MessageToUser;
Message.DataKey = Select.Link;
Message.Field = "id";
Message.Text = „O secțiune cu acest ID există deja”;
Message.Message();
endIf;

În acest exemplu, dublu clic se va deschide un element de director cu același Id, iar câmpul Id va fi activ și va conține un indiciu:

Pare convenabil, atât putem schimba ID-ul noului element, cât și pe cel vechi, este ușor să intri în el făcând clic pe mesaj. Dar nu este activat câmpul din elementul curent, ceea ce, cu un număr mare de câmpuri, poate fi mai util decât deschiderea formei unui alt obiect. La urma urmei, un alt obiect a fost deja înregistrat și este utilizat, iar probabilitatea ca să existe o eroare în el este mică. Cel mai probabil trebuie să edităm elementul curent.

Pentru a face acest lucru, schimbați codul după cum urmează:

//dacă există duplicate, eșantionul va conține date
Dacă selectează.Next() Atunci
Refuza = Adevărat;
Mesaj = New MessageToUser;
Message.DataKey = Object.Link;
Message.Field = "id";
Message.Text = „O secțiune cu acest ID există deja”;
Message.Message();
endIf;

Singura diferență este că în DataKey trecem un link către elementul pe care îl avem deschis. Din păcate, acest cod nu funcționează: (Dublu clic se va deschide o fereastră modală.

Pentru ca acest lucru să funcționeze, există o nuanță pe care trebuie să completați „ PathToData". Nu pot explica exact de ce, trebuie doar să-mi amintesc asta. Deschide un alt obiect - calea datelor nu este necesar, poziționăm în interiorul celui actual – necesar. Concluzie - este mai bine să o completați întotdeauna, nu puteți greși. Adăugați linia la cod:

Message.DataPath = „obiect”;

Și totul este frumos:

Mai este o nuanță despre care vreau să vorbesc. Dacă „câmpul” este lăsat gol, atunci poziționarea pe elementul de control nu va avea loc și nu va apărea un sfat cu instrumente în dreptul acestuia. Dacă „câmpul” este completat incorect, atunci poziționarea va avea loc pe formular în ansamblu și va apărea un tooltip, dar la sfârșitul formularului, fără referire la câmpul de intrare real.

Următoarea nuanță este că mesajul are o metodă - " SetData„. Pe baza obiectului, completează câmpurile DataKeyŞi PathToData. Este mult mai convenabil să faci totul într-o singură linie. De obicei, sub forma unui element/document, avem un obiect. Singurul lucru care trebuie scris pe server este următorul:

Message.SetData(FormAttributesValue(„Obiect”));

Dar în procedura predefinită a formei Înainte de a înregistra pe server de fapt există deja un parametru CurrentObject. Dar pe client nu vom primi deloc obiectul. Chiar și în modulul obiect (nu în formă) trebuie să scrieți acest lucru:

Message.SetData(ThisObject);

În concluzie, vreau să spun câteva lucruri urâte despre formularele gestionate. Acest lucru se aplică atât TAXI-urilor, cât și UV-urilor obișnuite. Faptul este că listele de interfețe sunt transferate foarte slab la UV. Un tabel care conține 1000 de rânduri este desenat foarte lent, iar într-un browser web poate dura câteva minute pentru a se deschide. Acest lucru este valabil și pentru lista de mesaje. Pentru un experiment, afișați 1000 de mesaje și încercați să comutați între ferestre. Sistemul va muri imediat. Mai mult decât atât, este clar vizibil modul în care sistemul se gândește la ieșirea mesajelor. Accesul la o fereastră cu o grămadă de mesaje arată astfel:

Conținutul ferestrei este afișat
-care pâlpâie puternic și apare bara de mesaje
-totul se blochează și vezi cum scroll-ul din fereastra de mesaj se strecoară în jos

Aceste. Ca și înainte, este imposibil să afișați un jurnal de procesare pe termen lung în panoul de mesaje, care conține câteva mii de înregistrări. Aș recomanda să vă limitați la 10 mesaje. Jurnalele trebuie să fie scoase pe o linie cu mai multe linii; acestea sunt afișate aproape instantaneu, indiferent de numărul de linii. Desigur, dacă verificați caracterul complet al detaliilor părții tabelare, există 1000 de rânduri în ea și există o eroare în fiecare, atunci da, va trebui să așteptați :) Deși în acest caz vă puteți gândi la dvs. propriul mod de a afișa mesajele, de exemplu într-un câmp de document HTML.

Dar unele aspecte ale lucrului cu obiectul „Mesaj către utilizator” nu au rămas acoperite în acesta. De exemplu, ce să scrieți în câmpul „Câmp” dacă numele

props diferă de numele câmpului din formular. Ce să scrieți în câmpul „Cale către date”. Și, în sfârșit, cel mai delicios lucru este cum să lucrezi cu partea tabelară.

Toate cercetările sunt colectate într-o bază de date de testare. Conține câteva cărți de referință și un document. Formularul de document are mai multe butoane, la apăsare, sunt afișate diverse tipuri de mesaje. Ei bine, acum despre fiecare moment în ordine, să mergem!!!

Tot ce scriu mai jos a fost testat pe 1C:Enterprise 8.3 (8.3.7.1860). Nu este ultimul de până acum, dar îl scriu așa cum este.

1. Doar un mesaj.

Să începem cu ceva simplu: doar afișați un mesaj în formular, fără referire la câmpuri, date etc.

Am vorbit despre asta mai devreme, dar pentru integritatea articolului îl voi scrie din nou. Mai ales cu unele completări.

Message1 = mesaj nou pentru utilizator;
Message1.Text = „1. doar un mesaj fără nicio legătură”;
Mesaj1.Mesaj();

Acest cod poate fi executat atât pe client, cât și pe server. Acesta este aproape un analog complet al liniei:

Raport ("1. doar un mesaj fără nicio legătură");

De ce este mai corect să comunici nu cu o procedură, ci cu un obiect. Faptul este că mesajele emise într-o sarcină de fundal (de exemplu, când se execută o procedură de rutină conform unui program) nu sunt afișate nicăieri. Dar ceea ce este comunicat de obiect poate fi

primiți pe server într-o sesiune client folosind metoda „GetMessagesToUser(...)” în timp ce jobul de fundal este activ.

Aici te-am mințit puțin, nu am verificat niciodată. Este foarte posibil ca mesajele emise prin procedura „Raport(...)” să poată fi obținute și dintr-un job de fundal, dar poate nu. Documentația nu spune despre asta, ceea ce înseamnă că noi

nu o vom face.

Deci, concluzia: acum faceți întotdeauna mesajele un obiect, aceasta este o formă bună a noii platforme și uitați de procedură. Dacă nu vă place să scrieți un mesaj în trei rânduri, atunci scrieți procedura într-un modul general și fiți fericit. O să fie chiar

ton foarte bun, pentru că Veți primi o serie de avantaje:

1. Funcționalitate extinsă a noului obiect (mai multe detalii mai jos)

2. Capacitatea de a afișa mesaje în felul tău. De exemplu, într-un câmp text sau într-un fișier, și nu într-o casetă de mesaj.

3. Posibilitate de logare. De exemplu, puteți salva toate mesajele din baza de date sau într-un fișier sau le puteți duplica în jurnal, pentru a face acest lucru, trebuie doar să modificați procedura obișnuită a modulului. Și apoi dezbaterea este că programul nu este nimic pentru utilizator

nu a informat se va opri pentru totdeauna.

2. Un mesaj asociat cu un atribut de obiect.

După cum am scris în articolul anterior, pentru a lega trebuie să completați câmpurile „Field” și „PathKData”. Dar nu am tratat subiectul în detaliu în articol.

Deci, exemplul 2 în document există un atribut de antet „Client”, trebuie să vă poziționați pe el și să raportați ceva în procedura clientului. Iată codul care face asta:

Message2 = mesaj nou pentru utilizator;
Message2.Text = "2. Mesaj asociat cu atributul antet Client";
Message2.Field = "Client";
Message2.DataPath = "obiect";
Mesaj2.Mesaj();

Și iată nuanțele:

1. Un câmp nu este un câmp, pentru că în exemplul meu, controlul se numește „FieldClient” și obiectul prop este „Client”. Linia Message2.Field = "FieldClient" nu funcționează.

2. Calea către date nu este „Obiect.Client”, ci pur și simplu „Obiect”, deoarece Trebuie să arătăm mesajul nu sub forma contrapărții, ci sub forma documentului curent. „Obiect.Client” - nu funcționează.

3. Acesta este un exemplu de lucru pe un client. În procedurile de server, este puțin diferit. Acest lucru este IMPORTANT, nu confundați legarea mesajelor pe server și pe client.

Voi mai da un exemplu, astfel încât să puteți simți diferența dintre un client și un server. Cert este că avem la dispoziție metoda obiect „SetData(...)”. Asistentul de sintaxă spune „Obiectul cu care ar trebui să existe

mesajul este asociat." Acest lucru este important. De exemplu, să scriem următorul cod:

Message3 = mesaj nou pentru utilizator;
Mesaj3.SetData(Obiect);
Message3.Text = "3. Mesaj legat de atributul antet Număr, dar nu va fi legat, deoarece Obiectul nu este un obiect";
Message3.Field = „Număr”;
Mesaj3.Mesaj();

Acest cod nu va funcționa pentru că... pe client, atributul de formă „Obiect” nu este deloc un obiect, ci un fel de lucru urât, asta ne spune depanatorul despre variabila obiect:

Mai precis, utilizatorul va vedea desigur mesajul, dar atingerea lui de două ori nu va duce la nimic.

Acum să încercăm același lucru, dar pe server. Să creăm o procedură de server „Report4OnServer()” și să o apelăm de la client

&OnServer
Procedură Report4OnServer()
Message4 = mesaj nou pentru utilizator;
Message4.SetData(FormAttributesValue(„Obiect”));
Message4.Text = "4. Mesaj asociat cu atributul antet Organizație";
Message4.Field = „Organizație”;
Mesaj4.Mesaj();
Sfârșitul procedurii

Totul va fi bine aici, singura remarcă asupra codului este că variabila „obiect” trebuie convertită din „FormDataStructure” într-un obiect real apelând procedura „FormAttributesValue(...)”.

Concluzie: metoda „SetData(...)” poate fi folosită doar pe server, deoarece doar pe server se poate primi un obiect.

3. Mesaje legate de atributul părții tabulare a obiectului

Am omis acest subiect în articolul precedent. Cunoscând nuanțele descrise mai sus, nu ar trebui să existe probleme aici. Iată codul client de lucru:

Message5 = mesaj nou pentru utilizator;
Message5.Text = "5. Cantitatea câmpului liniei 1";
Message5.Field = "Produse.Cantitate";
Message5.DataPath = "obiect";
Mesaj5.Mesaj();

Deși nuanțele sunt aproape aceleași, repetarea este o lecție mamă:

1. Câmpul nu este numele controlului meu se numește „Cantitate Produse”, nu doar „Cantitate”. „Produse” este numele părții tabelare, nu elementul de control asociat cu partea tabelară.

2. Calea către date este un obiect, doar un obiect.

3. Numărul de linie între paranteze drepte - numerotarea de la zero și acesta este numărul de linie, nu identificatorul de linie în culegerea de date din formular. La mutarea liniilor sau la ștergerea acestora, se salvează identificatorul atribuit la deschiderea formularului, iar numerele liniilor sunt recalculate.

Asta e pentru data asta. Voi aminti imediat subiecte nedezvăluite despre care voi scrie mai târziu:

1. Cum să legați mesajele nu la obiectul curent, ci la orice obiect, astfel încât la dublu clic să se deschidă un alt formular

2. Cum să legați mesajele la un formular în care nu există obiecte

3. Cum să primiți mesaje despre starea de execuție a unui job cu fundal lung

4. Ce este o „Cheie de date” și când ar trebui să o utilizați?

Mai jos este o bază de date cu un exemplu, în ea accesați documentul și apăsați pe rând trei butoane. Cod în modulul formular document.

În timpul lecției: am creat o bază, am creat procesare, am creat un formular.

Acum vă vom spune 5 metode de mesaje de la 1C „Bună, lume!”

Nu toată lumea știe despre cel puțin două metode :)

Cum și unde să scrieți textul programului?

Treceți la fila ferestrei cu formularul „Modul”. Vă veți asigura că aveți deja un text acolo ("Procedură...").

Dacă nu există text, atunci:

• În clientul gros ați adăugat formularul la procesare incorect, repetați de la început
• Ați uitat să adăugați un buton în clientul subțire, repetați de la început.

În interiorul textului există o linie:

// Introduceți conținutul handler-ului

Sarcina ta este să ștergi această linie și să introduci textul programului în locul său. După aceea, salvați procesarea și deschideți-o în modul întreprindere.

Când faceți clic pe Execute, acțiunile pe care le-ați introdus vor fi acum efectuate.

Acum să trecem la metodele în sine!

Mesaj în 1C, metoda 1 - cea mai ușoară

Deci, în loc de textul „// Inserați conținutul handlerului”. scrie textul programului.

Raport ("Bună lume!");

De fapt, asta e tot :)

Mesajul în modul Enterprise în clientul gros va fi în partea de jos a ferestrei 1C, în clientul subțire - în partea dreaptă în fereastra de procesare.

Aceasta este cea mai simplă metodă, foarte utilizată de programatori.

Mesaj în 1C, metoda 2 - de asemenea simplu

Alert("Bună lume!");

De fapt, asta e tot :)

Mesajul pentru modul Enterprise pentru ambele opțiuni de client va apărea într-o fereastră pop-up.

Mesaj în 1C, metoda 3 - a apărut doar în 1C versiunea 8.2

ShowUserAlert("Bună, lume!","Bună ziua într-adevăr!");

Această metodă a apărut doar în versiunea 1C 8.2. Aceasta este o fereastră pop-up în colțul din dreapta jos al ecranului, care dispare în timp.

Mesaj în 1C, metoda 4 - programator

Throw Exception „Bună, lume!”;

Poate apărea o eroare la executarea oricărui program. Uneori, această eroare poate fi calculată în avans (de exemplu, trebuie să calculați a = b/c și în momentul execuției programului se știe că c este egal cu 0).

În acest caz, există o modalitate de a raporta eroarea folosind această metodă.

Mesaj în 1C, metoda 5 - avansat tehnologic, doar pentru configurație standard

Scop general.ReportError("Bună ziua, lume!");

Un programator 1C trebuie să cunoască nu numai metodele de programare care sunt disponibile în platforma 1C, ci și cele care sunt disponibile în configurații standard.

Începătorii, când încearcă să adauge orice configurație standard, încep să reinventeze roata.

Iată un exemplu perfect. Această caracteristică este prezentă în multe configurații standard (doar pentru client gros!). S-ar părea că rezultatul este egal cu acțiunea metodei 1.
Cu toate acestea, nu - în unele configurații (de exemplu soft starter), mesajele de eroare sunt duplicate în jurnal. De asemenea, cu setări suplimentare, mesajul arată complet diferit.

Deci, acum te poți simți ca un adevărat programator!

Exact asta este programarea 1C. Desigur, programarea reală este mult mai complexă și necesită multe cunoștințe, dar acum aveți o idee generală.

Noroc!

P.S. Versiunea pdf a lecției conține capturi de ecran pentru a face mai ușor să vă faceți propria experiență.

P.P.S. Lecția include 5 videoclipuri cu exemple de creare a unei baze pentru programare, creare de procesare, programare într-un client gros și subțire.