Как да издаде съобщение за потребителя
Рейтинг: 0/5
Днес ние говорим за такъв привидно просто нещо като послание към потребителя.
Методът 1С 8 мигрирали от 7.7 - "доклад (.)". Този метод е много прост, той се отваря съобщението, ако не е вече е отворен, и води до увеличаване на текстовото съобщение. Както в 1С 7.7 има втори параметър, който определя иконата до съобщението. Тази икона определя значението на съобщението.
С течение на времето, а ние имаме в ръцете на контролирана форма. В контролираните форми без прозорец едно съобщение. Методът обаче все още се поддържа. В нов интерфейс съобщение придържат към активния прозорец. Когато превключите към друг прозорец, съобщението от вида, а в замяна да се показват отново. В някои случаи, това не е удобно, но нищо не може да се направи, за да се контролира формата предполага отсъствие на главния прозорец, който може да се свърже съобщение.
Фактът, че сега е обща за да не се използва в световен контекст метод "Доклад (.)", И обект "SoobscheniePolzovatelyu". Това съоръжение е на разположение навсякъде, и на клиента и на сървъра. В него има няколко свойства и няколко метода.
По принцип, ако трябва да се даде на потребителя съобщение, без каквато и интерактивност, че е достатъчно да се напише:
Публикация = New SoobscheniePolzovatelyu;
Soobschenie.Tekst = "раздел с това Id вече съществува";
Soobschenie.Soobschit ();
Тези три линии са абсолютно идентични с вече известния метод и съгласно това използване на този обект на това съобщение е безсмислено.
Основните области, които се простират възможностите на комуникацията са:
Глупости може да се случи, ако искаме да генерира съобщение, под формата на обекта все още не се записва. В този случай, ние имаме един празен връзка. Но платформата не се губи, и просто не разкрива всичко, което е Останете във форма, която е била.
Невярно - е низ с името на областта, която трябва да бъде активирана. Няма значение, отворете формата на друг обект, или ще остане в сегашния си вид.
Ето как става това:
Да предположим, че преди записа на директорията в модула на формата ние проверка на уникалността на подпори "Id" и, ако то вече е това, се появява съобщение:
В този пример, като кликнете два пъти, за да отворите влизането директория със същото Id, лична и областта е активен и това ще ви подкани:
Изглежда удобно, можем да променим, като идентификацията на новия елемент и да редактирате старите, че е лесно да стигнем до там, като кликнете върху съобщението. Но областта на текущата клетка не са били активирани, че когато голям брой полета могат да бъдат по-полезни, отколкото да се отвори под формата на друг предмет. След още един обект вече е записан и се използва и вероятността за грешка в него - малък. Преди всичко, ние трябва да редактирате текущия елемент.
За да направите това, промените кода, както следва:
Единствената разлика е, че в KlyuchDannyh прехвърляме препратка към елемента, че сме отворени. За съжаление този код не работи :( Ако кликнете два пъти, за да отворите модален прозорец при нас.
За да стане това, има нюанс, който трябва да попълните "PutKDannym". Не мога да обясня точно защо, това е просто да се помни. Отворете друг обект - начина, по който не е необходимо данните, позициониране в рамките на текущата - необходимостта. Заключение - по-добре винаги да се запълни, не може да се обърка. Дори и добавете ред:
Друг нюанс, за което искам да кажа. Ако "Полето" е оставено празно, това няма да се случи позициониране контрол, и до него не излезе подсказка. Ако полето "" не е валидно, позиционирането ще се появят на формата като цяло и подсказка ще бъде, но в края на формата, без privzyaki недвижими поле за въвеждане.
Следваща нюанс - постовете имат метод - "UstanovitDannye". Той се основава на обекта изпълва в областта и KlyuchDannyh PutKDannym. Това е много по-удобно да се направи всичко в един ред. Обикновено под формата на елемент / документ имаме един обект. Единственото нещо, което сървърът трябва да бъде написана, както следва:
Но в рамките на предварително определени процедурни форми PeredZapisyuNaServere всъщност вече са създаване TekuschiyObekt. Всеки клиент, обект ние не го получи. Дори и в модула за обект (не в униформа), трябва да бъде написана, както следва:
В заключение искам да разкажа една история за лоши неща управляема форма. Това важи както за TAXI и конвенционални UV. Фактът, че UV е много лошо предава интерфейс списъци. Таблица, съдържаща 1000 линиите, много бавно, а през уеб браузър, той може да направи за няколко минути, за да се отворят. Това важи и за списъка със съобщения. експериментирате печат 1000 съобщенията и се опитват popereklyuchatsya между прозорците. Системата ще умре веднага. което ясно показва как системата си мисли, че е над ПИН съобщенията. Отивате до прозореца с един куп мнения е както следва:
-показва съдържанието на кутията
-драматично мига и се появява лентата с послание
-всички увисва и ще видите как да преминете в прозореца на съобщението пълзи надолу
Т.е. както и преди, да се въвеждат в произведенията за обработка на лог съобщения продължителни панела, в които няколко хиляди записи - това е невъзможно. Бих посъветвал да се ограничи 10yu съобщения. Дневници трябва да бъдат изведени в многоредово низ, тя се показва почти мигновено, независимо от броя на линиите. Разбира се, ако проверите заетостта на масата за подпори, нейните редове на 1000 и във всяка грешка, а след това да, това е необходимо potervet :) Въпреки че е възможно в този случай да се помисли за начин за показване на съобщения, например в областта на документа за HTML.