itthon » Sport » Kapcsolók, rendszeres jelentkezés, kezelt űrlapok. Kapcsolók, normál alkalmazás, kezelt űrlapok 1c problémák a kezelt űrlapokkal

Kapcsolók, rendszeres jelentkezés, kezelt űrlapok. Kapcsolók, normál alkalmazás, kezelt űrlapok 1c problémák a kezelt űrlapokkal

Az 1C:Enterprise platform lehetővé teszi egy felügyelt űrlap elemeinek programozott hozzáadását és módosítását. Nézzük meg, miért lehet erre szükség.

Az űrlap szoftveres módosítására több esetben is szükség lehet:

A szabványos konfigurációk véglegesítésekor a későbbi frissítési eljárás megkönnyítése érdekében. Ebben az esetben csak az űrlapmodul módosul. A modulokat sokkal könnyebb frissíteni, mint az űrlapokat.
Néhány gyakori algoritmus implementálásakor. Például az „Objektumrészletek szerkesztésének tilalma” alrendszerben programozottan létrehozható egy gomb az alrendszerhez kapcsolódó összes objektumhoz, amely lehetővé teszi a részletek szerkesztését.
Egyes konkrét algoritmusok implementálásakor. Például a Nomenclature könyvtárban mezők jönnek létre további részletek szerkesztéséhez.

A kezelt űrlapon programozottan hozzáadhat, módosíthat és törölhet:

kellékek;
helyi csapatok;
elemeket.

Mindezek a műveletek csak a szerveren lehetségesek.

Az automatizált átalakításnak vannak korlátai:

Csak a programozottan hozzáadott részleteket/parancsokat/elemeket törölheti. A konfigurátorban létrehozott objektumok programozottan nem törölhetők.
Nem rendelhet hozzá attribútumot főként.

Űrlapparancsok módosítása

Egy objektumhoz tartozó parancsok összetételének kezelése ManagedForm van egy gyűjtemény Csapatok

Hozzáadás (< ИмяКоманды >)

Mennyiség ()

megtalálja (< ИмяКоманды >)

Töröl (< Команда >)

A Teams gyűjtemény a kliensen és a szerveren is elérhető. A gyűjteményt (Add() és Delete() metódusok) csak a szerveren módosíthatja. A kliensen és a szerveren is megkeresheti és lekérheti az elemek számát (a Find () és a Count () metódusokat.

Példaként az űrlapparancsokkal való munkavégzésre, hozzunk létre egy új ChangeHistory parancsot „ChangeHistory...” fejléccel, amely meghívja a kezelőt. DisplayHistory(). A létrehozás az űrlap megnyitásakor történik.

&A szerveren
Eljárás WhenCreatingOnServer (hiba, szabványos feldolgozás)
Csapat = Csapatok. Add( "Változások története");
Csapat . Akció = ;
Csapat . Cím = "A változások története...";
Az eljárás vége
&OnClient
Eljárás Connectable_DisplayHistory(Command)
// parancs műveletek
Az eljárás vége

A parancskezelőnek egy űrlapon kell elhelyezkednie, és rendelkeznie kell egy &OnClient fordítási direktívával.

Az űrlap részleteinek módosítása

Az űrlaprészletek összetételének beolvasását a funkció végzi Részletek(< Путь >) FormAttributes típusú tömböt ad vissza. A függvény paraméter adja meg a szülőattribútum elérési útját (karakterláncként). Ha a paramétert kihagyjuk, vagy üres karakterláncot adunk meg, a rendszer a legfelső szintű részleteket adja vissza.

A részletek módosítása a módszerrel történik Részletek módosítása(<Hozzáadott részletek>, <Kivehető részletek>) tárgy ManagedForm. A paraméterekhez Hozzáadott részletekÉs Kivehető részletek A Form Attributes típusú elemekkel rendelkező tömbök továbbítása történik.

Figyelem!

A részletek összetételének megváltoztatásának folyamata meglehetősen erőforrás-igényes. Az űrlap valójában újbóli létrehozás alatt áll. Ebben a tekintetben az űrlap részleteivel való munka kötegelt módban történik.

Hozzunk létre egy új űrlapattribútumot Vevő néven:

AddedDetails = Új tömb;
Hozzáadott részletek. Add(Új űrlapattribútumok(„Vevő”, Új típusleírás („DirectoryLink. Partnerek”), „Ügyfél”));

// Változások a részletek összetételében
);

Formaelemek megváltoztatása

Egy objektum elemeinek összetételének szabályozása ManagedForm van egy gyűjtemény Elemek. A gyűjtésnek több módja van:

Beszúrás (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Hozzáadás (< Имя>, < ТипЭлемента>, < Родитель >)

Mennyiség ()

megtalálja (< Имя >)

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

Töröl (< Элемент >)

A tételgyűjtemény a kliensen és a szerveren is elérhető. Gyűjtemény módosítása (Módszerek beszúrása () , Hozzáadás () , Áthelyezés () és Törlés () ) csak a szerveren érhetők el. A kliensen és a szerveren is megkeresheti és lekérheti az elemek számát (a Find () és a Count () metódusokat. A gyűjtemény elemei lehetnek:

FormGroup;
FormTable;
FormField;
Űrlap gomb.

Programozottan hozzárendelhet eseménykezelőket az űrlapelemekhez. A módszer erre a célra készült SetAction(< ИмяСобытия>, < Действие >) .

Nézzünk meg néhány példát a parancsokkal, részletekkel és űrlapelemekkel való munkavégzésre.

Parancs és a hozzá tartozó gomb hozzáadása:

// Hozzon létre egy parancsot
Csapat = Csapatok. Add( "Változások története");
Csapat . Akció = "Plug-in_DisplayHistory"; // Az űrlapnak tartalmaznia kell egy eljárást a megadott névvel
Csapat . Cím = "A változások története...";
// Hozzon létre egy gombot, és társítsa egy parancshoz
Elem = Tételek. Add( "Változások története", Type("FormButton" ));
Element.CommandName = "Változások története";

Attribútum és a hozzá tartozó beviteli mező hozzáadása:

// A hozzáadott részletek leírása
AddedDetails = Új tömb;
Hozzáadott részletek. Hozzáadás(Új forma kellékek ("Vevő", új típusleírás ( "DirectoryLink. Partnerek"), "Ügyfél" ));
// A részletek összetételének megváltoztatása
ChangeDetails (Részletek hozzáadva);
// Beviteli mező létrehozása és kapcsolódás attribútumokkal
Elem = Tételek. Add("Vevő" , Type("Űrlapmező" ));
Elem . Nézet = FormFieldView. beviteli mező;
Elem . PathToData= "Vevő" ;

Eseménykezelő hozzárendelése egy űrlapelemhez:

ItemCustomer. SetAction("Amikor megváltozik" , "Connected_BuyerOnChange");

&OnClient
Eljárás Connected_BuyerOnChange(Elem)
// Eseményműveletek
Az eljárás vége

Figyelem!

A metódus használatával kódból eseménykezelőként beállított eljárások SetAction(), ajánlott a Connectable_ előtagot beállítani.

Figyelem!

Letöltheti a feldolgozást példákkal a programozott keresésre és a felügyelt űrlap részleteinek, parancsainak és elemeinek módosítására.

És adatátviteli objektum a kód strukturálásához, vezérelt formában az 1C 8.2 környezetben.

Bevezetés

Kezdjük a „menedzselt forma” fogalmának és az 1C platform kapcsolódó fogalmainak rövid leírásával. A platform ínyencei érdemes kihagyni ezt a részt.

2008-ban elérhetővé vált az 1C platform új verziója: Enterprise 8.2 (a továbbiakban: felügyelt alkalmazás), amely teljesen megváltoztatja a felülettel végzett munka teljes rétegét. Ez magában foglalja a parancsfelületet, az űrlapokat és az ablakrendszert. Ugyanakkor nemcsak a konfigurációs felhasználói felület fejlesztésének modellje változik meg, hanem egy új architektúra is javasolt a kliens alkalmazás és a szerver közötti funkcionalitás elválasztására.
A felügyelt alkalmazás a következő típusú ügyfeleket támogatja:

Vastag kliens (normál és felügyelt indítási mód)
Vékony kliens
Web kliens

A felügyelt alkalmazás új technológiára épülő űrlapokat használ. Úgy hívják Kezelt űrlapok. Az átállás megkönnyítése érdekében a korábbi űrlapok (az ún. reguláris űrlapok) is támogatottak, de ezek funkcionalitása nincs kifejlesztve, és csak vastag kliens indító módban érhetők el.
A kezelt űrlapok fő különbségei a fejlesztők számára:

A szerkezet deklaratív, nem „pixelről pixelre” leírása. Az elemek konkrét elhelyezését a rendszer automatikusan elvégzi az űrlap megjelenítésekor.
Az űrlap összes funkciója a következőképpen van leírva részletekÉs csapatok. A részletek azok az adatok, amelyekkel az űrlap működik, a parancsok pedig a végrehajtandó műveletek.
Az űrlap a szerveren és a kliensen is fut.
Kliens környezetben szinte minden alkalmazástípus nem érhető el, ennek megfelelően az infobázisban lévő adatok megváltoztatása nem lehetséges.
Minden metódushoz vagy űrlapváltozóhoz meg kell adni összeállítási irányelv, amely meghatározza a végrehajtási helyet (kliens vagy szerver) és az űrlapkontextushoz való hozzáférést.

Soroljuk fel az űrlapmetódusok összeállítására vonatkozó direktívákat:

&OnClient
&A szerveren
&OnServerContext nélkül
&OnClientOnServerKontextus nélkül

Illusztráljuk a fentieket. A képernyőkép egy felügyelt űrlapra és annak moduljára mutat példát fejlesztési módban. Keresse meg a deklaratív leírást, kellékeket, összeállítási utasításokat stb.

Minden további megbeszélés az illusztráció jobb oldaláról fog szólni, arról, hogyan kell felépíteni a modul kódját, és milyen elvek teszik lehetővé a hatékony kliens-szerver interakció megvalósítását.

Határozzuk meg a problémát

Több év telt el azóta, hogy az 1C platform új verzióját aktívan használják, és számos megoldást (konfigurációt) adott ki az 1C és számos partnere.
Ezalatt az idő alatt kialakult-e a fejlesztők közös értelmezése a kliens-szerver interakció elveiről az űrlapok létrehozásakor, és megváltozott-e a szoftvermodulok megvalósításának megközelítése az új építészeti valóságban?

Nézzük meg a kódszerkezetet (űrlapmodult) ugyanazon szabványos konfiguráció több alakjában, és próbáljunk mintákat találni.
Struktúrán a kód szakaszait értjük (leggyakrabban ezek megjegyzésblokkok), amelyeket a fejlesztő a metódusok csoportosítására és az ezekhez a metódusokhoz tartozó fordítási direktívákhoz rendel hozzá.
1. példa:
Eseménykezelők szekciója Módszer - a kliensen Módszer - a szerveren Módszer - a kliensen Szervizeljárások és -funkciók szekció Kiegészítő bemenetvezérlő funkciók
2. példa:
Szolgáltatási eljárások és funkciók Fizetési bizonylatok Értékek Eseménykezelők
3. példa:
Szervizeljárások a szerveren Szervizeljárások a kliensen Szolgáltatási eljárások a szerveren kontextus nélkül Fejléc eseménykezelők Parancs eseménykezelők
4. példa:
Általános célú eljárások Űrlap-eseménykezelők A „kapcsolati adatok” alrendszer eljárásai
Lényegében hiányzik a kódstruktúra, vagy enyhén szólva hasonló a Forms 8.1-hez:

Nem tájékoztató jellegű „Általános, Szerviz, Kisegítő” szavak.
Félénk kísérletek a kliens és a szerver metódusainak elkülönítésére.
A módszereket gyakran interfész-elemek szerint csoportosítják: „Munka a táblázatos résszel Termékek, Elérhetőségek”.
Metódusok és kódcsoportok tetszőleges elrendezése. Például előfordulhat, hogy az eseménykezelők egyik formában felül vannak, egy másikban alul, harmadikban egyáltalán nincsenek kiemelve stb.
És ne felejtsük el, hogy mindez egyetlen konfiguráción belül van.
Igen, vannak olyan konfigurációk, amelyekben az „Általános, Szerviz, Kisegítő” szavak mindig ugyanazokon a helyeken vannak, de...

Miért van szükség kódszerkezetre?

A karbantartás egyszerűsítése.
A tanulás egyszerűsítése.
Általános/fontos/sikeres alapelvek rögzítése.
...a te választásod

Miért nem segít az 1C meglévő fejlesztési szabványa?

Nézzük meg az ITS-lemezeken és a különféle „Fejlesztői útmutatókban...” közzétett alapelveket, amelyek a kezelt űrlap megírásakor ajánlottak.

Minimalizálja a szerverhívások számát.
Maximális számítási lehetőség a szerveren.
A nem kontextuális szerverhívások gyorsabbak, mint a kontextus szerintiek.
Program az ügyfél-szerver kommunikációt szem előtt tartva.
stb.

Ezek teljesen igazak szlogenek, de hogyan valósítsuk meg őket? Hogyan lehet minimalizálni a hívások számát, mit jelent kliens-szerver módban programozni?

Tervezési minták vagy generációs bölcsesség

A kliens-szerver interakciót évtizedek óta használják a különféle szoftvertechnológiákban. Az előző részben felvázolt kérdésekre a válasz régóta ismert, és két alapelvben foglalható össze.

Távoli homlokzat(a továbbiakban: Távoli hozzáférési interfész)
Adatátviteli objektum(a továbbiakban: adatátviteli objektum)

Egy szó Martin Fowlertől, ezekről az elvekről:

… Minden távoli hozzáférésre szánt objektumnak rendelkeznie kell alacsony részletességű interfész, amely minimálisra csökkenti az adott eljárás végrehajtásához szükséges hívások számát. ... A számlát és az összes tételét külön kéri, hanem az összes számlatételt egy kérelemben kell elolvasnia és frissítenie. Ez kihat az objektum teljes szerkezetére...Ne feledje: távoli elérési felület nem tartalmaz tartomány logikát.
...ha gondoskodó anya lennék, biztosan azt mondanám a gyerekemnek: "Soha ne írj adatátviteli objektumokat!" A legtöbb esetben az adatátviteli objektumok nem mások, mint dagadt mezei készlet... Ennek az undorító szörnyetegnek az értéke kizárólag a lehetőségben rejlik több információ továbbítása a hálózaton keresztül egy hívás során- elosztott rendszerekben nagy jelentőségű technika.

Példák sablonokra az 1C platformon

A felügyelt űrlap fejlesztése során a fejlesztő rendelkezésére álló alkalmazásprogramozási felület számos példát tartalmaz ezekre az elvekre.
Például az OpenForm() metódus, egy tipikus „durva” felület.
OpeningParameters = New Structure("Paraméter1, Paraméter2, Paraméter 3", Érték1, Érték2, Érték3); Form = OpenForm(FormName, OpeningParameters);
Hasonlítsa össze a v8.1-ben elfogadott stílussal.
Form = GetForm(FormName); Form.Parameter1 = Érték1; Form.Parameter2 = Érték2; Form.Open();

A kezelt űrlap kontextusában sok „adatátviteli objektum” létezik. Választhat szisztémásÉs fejlesztő által meghatározott.
A rendszeresek egy alkalmazásobjektumot modelleznek az ügyfélen, egy vagy több űrlapadat-elem formájában. Lehetetlen létrehozni őket az űrlap részleteire való hivatkozás nélkül.

DataFormsStructure
DataFormsCollection
DataFormStructureWithCollection
DataShapesTree

A rendszeradatátviteli objektumok alkalmazástípusokká konvertálása és fordítva a következő módszerekkel történik:

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

Gyakran explicit konverziót használnak egy meglévő megoldás adaptálásakor. A metódusok bemeneti paramétereket várhatnak (funkciókat használhatnak), például a ValueTable-t a FormDataCollection helyett, vagy a metódust egy alkalmazásobjektum kontextusában határozták meg, és nem elérhető az űrlapról történő közvetlen meghíváshoz.
Példa 1C v8.1:
// az ügyfélen a FillUserCache(DepartmentLink) űrlap kontextusában
Példa 1C v8.2:
// a szerveren a ProcessingObject = Form AttributesValue("Object") űrlap kontextusában; ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Az adatátviteli objektumok, amelyek szerkezetét a fejlesztő határozza meg, a kliensen és a szerveren egyaránt elérhető típusok egy kis részhalmazát alkotják. Leggyakrabban a következőket használják a „durvított” interfész metódusainak paramétereiként és eredményeiként:

Primitív típusok (karakterlánc, szám, logikai érték)
Szerkezet
Levelezés
Sor
Alkalmazásobjektumokra mutató hivatkozások (egyedi azonosító és szöveges megjelenítés)

Példa: a metódus elfogadja a megbízások listáját az állapot módosítására, és visszaküldi a hibák leírását az ügyfélnek.
&OnServerWithoutContext függvény SzerverChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [megrendelés][hiba leírása] Minden rendelésből Megbízás Cycle StartTransaction(); Próbáld ki a DocOb = Order.GetObject(); …. egyéb műveletek, amelyek nem csak a megrendeléssel lehetségesek... Kivétel CancelTransaction(); Errors.Insert(Rendelés, Hibaleírás()); EndAttempt; EndCycle; Visszaküldési hiba; EndFunction // ServerChangeOrderStatus()

A kód strukturálása

A fő célok, amelyeket a kezelt űrlap modulnak tükröznie kell, és a megoldás megközelítései.

A kliens és a szerver kód egyértelmű elkülönítése. Ne felejtsük el, hogy a végrehajtás időpontjában ez két kölcsönhatásban lévő folyamat, amelyek mindegyike jelentősen eltérő elérhető funkciókkal rendelkezik.
A távelérési felület egyértelmű azonosítása, mely szerver metódusok hívhatók a kliensből és melyek nem? A távoli interfész metódusainak neve a "Szerver" előtaggal kezdődik. Ez lehetővé teszi, hogy a kód olvasása közben azonnal láthassa az irányítás átadását a szerverre, és leegyszerűsíti a kontextus súgó használatát. Ne feledje, hogy a hivatalos ajánlás (ITS) a postfixes elnevezési módszereket javasolja, például ChangeOrderStatusOnServer(). Megismételjük azonban, hogy nem minden szervermetódus hívható meg a klienstől, ezért a logikai hozzáférhetőség fontosabb, mint a fordítási hely. Ezért a „Server” előtaggal csak a kliens számára elérhető metódusokat jelöljük, nevezzük a példametódusnak ServerChangeOrderStatus().
Olvashatóság.Ízlés dolga, akkor fogadjuk el a sorrendet, amikor a modul elkezdődik a szerveren lévő űrlapkészítési eljárásokkal és a távoli elérési módokkal.
Karbantarthatóság. Az új kód hozzáadásához egyértelmű helyet kell biztosítani. Fontos szempont, hogy a konfigurátor által automatikusan létrehozott metódusablonok a modul végére kerülnek. Mivel az űrlapelemek eseménykezelői leggyakrabban automatikusan jönnek létre, a megfelelő blokk az utolsó helyen található, hogy ne húzza át az egyes kezelőket a modul másik helyére.

Az alábbiakban a felsorolt célokat megvalósító modul alapvető felépítése látható.

Grafikus opció – világosan mutatja a végrehajtás fő folyamatát.
A szöveg opció egy példa egy sablontervre, amellyel gyorsan beszúrhat egy szerkezetet egy új űrlapmodulba.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Dátum=""/> // <Описание> // // //////////////////////////////////////////////// /////////////////////////// // MODUL VÁLTOZÓI ////////////////// ////////////////////////////////////////////////// ////////// // A SZERVEREN //******* ESEMÉNYEK A SZERVEREN ******** &A kiszolgálói eljárásról a szerveren történő létrehozáskor (hiba, szabványos feldolgozás) / /A kezelő tartalmának beillesztése Eljárás vége //******* TÁVELÉRÉSI INTERFÉSZ ****** //******** ÜZLETI LOGIKA A SZERVEREN ******* ////////////////////////////////////////////////// /////// //////////////////// // AZ ÜGYFÉL ÉS A SZERVER KÖZÖS MÓDSZEREI //////////////// /////// /////////////////////////////////////////// ///// //////// // AZ ÜGYFÉLEN //******* ÜZLETI LOGIKA AZ ÜGYFÉLEN ******** //******** CSAPAT * ****** //******** CLIENT ESEMÉNYEK ******* /////////////////////////// ///// ///////////////////////////////////////////// // / / FŐ PROGRAM ÜZEMELTETEŐI

Kapcsolódó kérdések

Végezetül felvázolunk néhány olyan területet, amelyekre érdemes gondolni a kliens-szerver interakció programozása során.

A távelérési interfész megvalósítási lehetőségei. Aszinkron, részletesség...
Gyorsítótárazás. Az 1C sikertelen építészeti döntést hozott, a gyorsítótárazást csak a közös modulok hívási módszereinek szintjén vezette be, és nem biztosított vezérlési képességeket (relevanciaidő, igény szerinti visszaállítás).
Implicit szerverhívások. Ne feledkezzünk meg a technológiai jellemzőkről, az ügyfél számos „ártalmatlan” művelete arra készteti a platformot, hogy kapcsolatba lépjen a szerverrel.

Űrlapok Az 1C:Enterprise az adatbázisban található információk megjelenítésére és szerkesztésére szolgál. Az űrlapok tartozhatnak meghatározott konfigurációs objektumokhoz, vagy azoktól különállóan létezhetnek, és a teljes alkalmazási megoldás használja őket.

Például egy könyvtár Elnevezéstan több formája is lehet, amelyeket meghatározott célokra használnak majd - egy könyvtárelem szerkesztése, lista megjelenítése stb.:

Ezzel együtt lehetnek általános űrlapok, amelyek nem tartoznak konkrét konfigurációs objektumokhoz - általános űrlapok.

Alapformák

Mindegyik konfigurációs objektum felhasználható néhány szabványos művelet végrehajtására. Előfordulhat például, hogy bármely könyvtár esetében meg kell jelenítenie az elemeinek listáját, meg kell jelenítenie a könyvtár egyes elemeit, meg kell jelenítenie a könyvtár egy csoportját, ki kell választania elemeket és elemcsoportokat a könyvtárból. Bármely dokumentum esetében az ilyen műveletek listája sokkal kisebb lesz: dokumentumok listájának megtekintése, kiválasztás a dokumentumok listájából és egy külön dokumentum megtekintése.

Annak érdekében, hogy az ilyen szabványos műveletek végrehajtásra kerüljenek az alkalmazásmegoldás-objektumok adataival, mindegyikhez van egy sor alapvető űrlap, amelyet a megfelelő műveletek végrehajtásakor használunk. Az objektumnak alárendelt bármelyik űrlap főként hozzárendelhető. Például a könyvtárban Elnevezéstan A következő alapformák létezhetnek:

És a dokumentum Áruk és szolgáltatások átvétele a fő formák összetétele eltérő lesz:

Így ha a felhasználó meg akarja tekinteni a címtárlistát Elnevezéstan vagy dokumentumok listája Áruk és szolgáltatások átvétele, a rendszer megnyitja az objektumok listájaként kijelölt megfelelő űrlapot.

Automatikusan generált űrlapok

Az 1C:Enterprise 8 rendszer egyik fontos jellemzője az automatikusan generált űrlapok mechanizmusa. Ez a mechanizmus megszabadítja a fejlesztőt attól, hogy minden konfigurációs objektumhoz minden lehetséges űrlapot létre kell hoznia. A fejlesztőnek csak egy új konfigurációs objektumot kell hozzáadnia, és a rendszer maga generálja a felhasználó munkájának megfelelő pillanataiban a szükséges űrlapokat az objektumban található információk megjelenítéséhez.

Így a fejlesztőnek csak akkor kell saját alkalmazási megoldási objektumformáit létrehoznia, ha azok eltérnek (eltérő kialakítás vagy specifikus viselkedés) a rendszer által automatikusan generált űrlapoktól.

Űrlap összekapcsolása adatokkal

Az, hogy egy űrlap egy adott konfigurációs objektumhoz tartozik-e, nem határozza meg az űrlapon megjelenített adatok összetételét. Az a tény, hogy az űrlap például egy könyvtárhoz tartozik Elnevezéstan, lehetővé teszi, hogy a könyvtár egyik fő űrlapjaként rendelje hozzá, de semmilyen módon nem határozza meg, hogy ez az űrlap milyen adatokat jelenítsen meg, és mi lesz a viselkedése.

Az űrlap adatokkal való társításához űrlapadatokat használnak, amelyek jelzik az űrlap által megjelenített adatok listáját. Minden űrlap ugyanolyan viselkedést mutat, függetlenül attól, hogy milyen adatokat jelenít meg. Azonban az egyik form attribútum kijelölhető hozzá főattribútumként (félkövéren van kiemelve), ebben az esetben az űrlap szokásos viselkedése és tulajdonságai kiegészülnek attól függően, hogy a fő forma attribútum milyen típusú:

Például, ha egy dokumentum fő űrlapattribútumként van hozzárendelve Áruk és szolgáltatások átvétele, akkor az űrlap bezárásakor a rendszer megerősítést kér a jelen dokumentum rögzítéséről és feladásáról. Ha mondjuk egy könyvtárat rendel hozzá az űrlap fő attribútumaként Elnevezéstan, akkor az űrlap bezárásakor nem jelenik meg ilyen megerősítési kérés.

Formaszerkezet

Az űrlapok fő jellemzője, hogy a fejlesztő nem rajzolja meg őket részletesen, „pixelről pixelre”. A konfigurációban lévő űrlap az űrlap összetételének logikus leírása. Az elemek konkrét elhelyezését pedig a rendszer automatikusan elvégzi az űrlap megjelenítésekor.

Az űrlap megjelenített (felhasználó számára látható) része egy űrlapelemeket tartalmazó faként van leírva.

Az elemek lehetnek beviteli mezők, jelölőnégyzetek, választógombok, gombok stb. Ezen kívül egy elem lehet egy csoport, amely más elemeket is tartalmaz. Egy csoport ábrázolható kerettel ellátott panelként, oldalakat tartalmazó panelként (könyvjelzők), maga egy oldalként vagy parancspanelként. Emellett az elem lehet egy táblázat is, amely elemeket (oszlopokat) is tartalmaz. Az elemstruktúra leírja, hogyan fog kinézni az űrlap.

Az űrlap összes funkciója részletek és parancsok formájában van leírva. A részletek azok az adatok, amelyekkel az űrlap működik, a parancsok pedig a végrehajtandó műveletek. Így az űrlapszerkesztőben a fejlesztőnek bele kell foglalnia az űrlapba a szükséges részleteket, parancsokat, létre kell hoznia azokat megjelenítő űrlapelemeket, és ha szükséges, az elemeket csoportokba kell rendeznie.

E logikai leírás alapján a rendszer automatikusan generálja az űrlap megjelenését a felhasználó számára történő megjelenítéshez. Ebben az esetben a rendszer figyelembe veszi a megjelenített adatok különféle tulajdonságait (például típusát), hogy az űrlapelemeket a felhasználó számára a lehető legkényelmesebben rendezze el.

A fejlesztő különféle beállításokkal befolyásolhatja az elemek elrendezését. Meg tudja határozni az elemek sorrendjét, megadhatja a kívánt szélességet és magasságot. Ez azonban csak néhány további információ, amely segíti a rendszert az űrlap megjelenítésében.

Az űrlapoknál a fejlesztő nem csak magának az űrlapnak a parancsait használhatja, hanem a teljes konfiguráció parancsfelületén használt globális parancsokat is. Ezen kívül lehetőség van olyan paraméterezhető parancsok létrehozására, amelyek az aktuális űrlap konkrét adatait figyelembe véve nyitnak meg más űrlapokat. Ez lehet például a számlaűrlapon jelenleg kiválasztott raktár egyenlegeiről szóló jelentés meghívása.

Mindannyian tudjuk, hogy az 1C vállalatnak számos különböző verziója volt az 1C platformról; most a cikk írásakor az egyik legújabb verzió érdekelni fog minket, ezek az 1C 8.2 és 1C 8.3 verziók. Ha mindkét verzióban kellett dolgoznia, akkor valószínűleg különbségeket észlelt ezen verziók interfészeiben, a felhasználók számára csak megjelenésükben különböznek. Lényegében egy választás rendszeres vagy menedzselt alkalmazás megmondja a rendszernek, hogy mely űrlapokat kell megjeleníteni a futtatáshoz, rendszeres vagy ellenőrzött, valamint azt, hogy melyik alkalmazáskliens lesz alapértelmezetten használatos, vastag vagy vékony. Az ügyfelekkel kapcsolatos részletesebb információkért olvassa el a „Mi a vastag és vékony kliens az 1C-ben, valamint ezek különbségei” című cikket.

Normál 1C alkalmazás (normál űrlapok, normál interfész, 1C 8.2 verzió)

Az 1C 8.2-ben csak a munkavégzés lehetséges szabályos nyomtatványokkal, normál alkalmazási módban. Az alábbi kép az adatbázist „normál 1C alkalmazás” üzemmódban mutatja (normál űrlapok).

Felügyelt 1C alkalmazás (felügyelt űrlapok, felügyelt felület, 1C 8.3 verzió)

Az 1C 8.3 platformon normál (kompatibilitási módban) és menedzselt űrlapokkal is dolgozhatunk. Ráadásul a kezelt űrlapoknak kétféle megjelenítésük van, ez a standard és a taxi. Az alábbiakban látható egy példa egy 1C 8.3 konfigurációra szabványos kezelt űrlapokkal, majd utána a „Taxi” felület látható.

Mi a különbség a normál és a felügyelt 1C alkalmazás között?

Mint azt már megtudtuk egy normál alkalmazás és egy felügyelt alkalmazás az 1C program ilyen típusú elindítása. Sőt, az 1C indítási típus értékétől függően ( rendszeres vagy menedzselt alkalmazás), alapértelmezés szerint egy adott felület töltődik be ( rendszeres vagy kezelt űrlapok), ezért nagyon sok szinonimája van ennek a fogalomnak. Szeretnénk megjegyezni, hogy az interfészek közötti különbségek meglehetősen jelentősek, a menedzselt felületet teljesen újratervezték. Elvileg ezek mind azok a különbségek, amelyeket az 1C program hétköznapi felhasználói látnak. Ami a programozókat illeti, a felügyelt interfész módosított kódot igényel, mivel a fejlesztés már az 1C 8.3-ban történik, és az 1C 8.2-ben nem, tehát az ebből eredő összes következmény. A kódot kliensre és szerverre is fel kell osztani; ezt a konfigurátor megfelelő direktívái jelzik.

Klyuev V.V.

http://prof1c.kklab.ru

MUNKA KAPCSOLÓKKAL

Kérem az oldal szolgáltatás minden felhasználóját figyelembe venni - anyagokat a Kezdők rovatba teszek fel!!!

8.2 Kezelt űrlapok

A felügyelt űrlapok viselkedésének tanulmányozása során a programozók vagy az interfészfejlesztők azzal a kérdéssel szembesülnek, hogy hol vannak a kapcsolók a felügyelt űrlapokon, és hogyan lehet őket hozzáadni az űrlaphoz. Apróság, de kellemetlen, hogy sok időt fordítanak az ilyen apróságokra, pedig ezt az időt inkább az algoritmus fejlesztésére, optimalizálására fordíthatnánk, nem pedig a formatervezésre.

Tehát hozzunk létre egy üres konfigurációt a kérdés megértéséhez, vagy válasszunk egy tipikusat.
Lépjen a könyvtárakat tartalmazó csoportba, és adjon hozzá egy új könyvtárat a kísérlethez. Szeretném megjegyezni, hogy a konfigurációnak rendelkeznie kell a fő indítási móddal - Felügyelt alkalmazás.

Tehát hozzunk létre egy új könyvtárat, és adjuk hozzá a "Tulajdonság1" attribútumot "Boolean" típussal.

Most menjünk az Űrlapok lapra, és adjunk hozzá egy új űrlapot.

Tehát a vezérelt űrlap létrejött, most dolgozzunk az űrlappal, és keressük meg, hol található a kapcsoló.
Itt van a formánk, és rajta látjuk a kellékeinket, de zászló formájában

Szóval mit csináltunk rosszul?
Nézzük meg a kellékek tulajdonságaiban, hogy van-e váltás a vezérlés típusára.
És látjuk, hogy a Switch mező nincs itt! (Hol hibáztunk?

Nyilván az adattípustól függ, hogy az űrlapon milyen vezérlési módot használunk, térjünk vissza az űrlap tulajdonságaihoz, nevezetesen a részletek fülhöz, és változtassuk meg attribútumunk tulajdonságait - nevezetesen annak típusát „Boolean”, a „Number” típusra. ”.

Most térjünk vissza a vezérlő tulajdonságaihoz, és nézzük meg, hogy a vezérlő nézete hozzá lett-e adva a tulajdonságaihoz - - - És hurrá, ott látjuk a nézetet - Switch Field.

Most nézzük meg az űrlapot, amit látunk:

Látunk - 3 alapértelmezett értéket, 3 kapcsolót, de kettőre van szükségünk, menj újra az attribútum tulajdonságaihoz, és nézd meg ott az „Oszlopok száma” tulajdonságokat

2 esetén állítsa be az Oszlopok számát - 2.

Ez egy kicsit megállíthat egy fáradt programozót)), de most már ő is és mi is tudjuk!

8.2 Normál nyomtatványok.

Unalmas kapcsolókkal hétköznapi formában.
Vannak ilyen pillanatok, és előfordulnak), amikor módosítania kell egy kész űrlapot, amelyen már van néhány kapcsoló, és ehhez az űrlaphoz egy másik kapcsolót kell hozzáadnia. Itt jön egyfajta unalmasság, ami sok időt vesz igénybe, és nem a kód programozása, hanem időpocsékolás, hogy ezeket a kapcsolókat megjelenítse a felhasználó számára.

Tehát nézzünk egy példát. Van egy ilyen dokumentum a nyugták kiigazításához az 1C UPP-ben - ez határozottan létezik. Egyszer kellett hozzá kapcsolókat hozzáadni, hogy kicsit más könyvelési tételek legyenek rajzolva. Mi a probléma, úgy tűnik, muszáj, muszáj, megtesszük. De ezen az űrlapon már van 2 választógomb.

Így néz ki az űrlap, amelyben további kapcsolókat kell hozzáadnunk

A Speciális fülön szeretnénk még két rádiógombot elhelyezni. Az első lépés tehát az, hogy bátran adjunk hozzá egy új vezérlőelemet a számunkra szükséges helyre és helyezzük be.

Úgy tűnik, minden egyszerű. Létrehozunk egy új attribútumot „Szám” típussal, és beillesztünk 2 kapcsolót, amelyek közül az egyik tud adatokat írni az attribútumba, a másik nem.

Adjon hozzá egy új vezérlőelemet - Kapcsoló, adja hozzá a Switch2-t a táblázathoz a kapcsolók számával és leírásával, állítsa be a Switch1-et a csoport első helyére, majd nyomja meg az OK gombot. Helyezze el a létrehozott vezérlőket az űrlapon. Frissítjük az adatbázis-konfigurációt (F7), és futtatjuk a hibakereséshez.

Végrehajtáskor (új dokumentum 1C:Enterprise módban létrehozásakor) azt látjuk, hogy hiába próbálunk rákattintani a Switch2-re, semmi sem történik. Az elemek nem úgy működnek, ahogy kellene. Van itt egy trükk.
Térjen vissza a konfigurátorhoz. Válassza az Űrlap -> Bejárási sorrend beállítása... menüpontot (fontos, hogy az űrlap meg legyen nyitva a képernyőn)

Ahhoz, hogy kapcsolóink működjenek, meg kell szakítania az automatikus rendelést, és el kell fogadnia a kézi rendelést. És tedd bele a formába, hogy a kapcsolóink rendre menjenek egymás után.