Buiten de context aanroepen van methoden van een verwerkingsobject (rapport) in een beheerde vorm. Buiten de context aanroepen van methoden van een verwerkingsobject (rapport) in een beheerd formulier 1c Aanroepen van een formulierprocedure vanuit een objectmodule

In nieuwe versies van 1C:Enterprise-systeemconfiguraties zijn veel functies en procedures verplaatst van objectmodules (documenten, mappen, enz.) naar managermodules. Laten we eens kijken naar de verschillen tussen deze twee modules.

Volgens de theorie van objectgeoriënteerd programmeren zijn objectmethoden onderverdeeld in twee groepen: statisch en eenvoudig. Eenvoudige methoden hebben alleen toegang tot een specifiek exemplaar van een klasse. Statische methoden hebben geen toegang tot objectgegevens, maar werken met de klasse als geheel.

Als we dit allemaal vertalen naar termen van het 1C:Enterprise-systeem, dan Objectmodule bevat eenvoudige methoden. Om ze te gebruiken, moet u eerst een specifiek object verkrijgen: een element van een directory, document, enz. Managermodule bevat statische methoden. Om er gebruik van te maken, hoeft u niet elk specifiek object afzonderlijk aan te schaffen; u kunt met de hele collectie in één keer werken.

Objectmodule kan procedures en functies hebben die extern kunnen worden gebruikt. Voor dit doel wordt een dergelijke procedure of functie aangeduid met het woord Exporteren.

Functie NewFunction() Exporteren

Om een ​​dergelijke functie vanuit een objectmodule te kunnen gebruiken, moet u eerst, nadat u een link naar het vereiste object heeft, dit verkrijgen met behulp van de functie GetObject().



Per = Voorwerp. NieuweFunctie() ;

Op dezelfde manier kunt u nieuwe variabelen maken die kunnen worden gebruikt vanuit verschillende configuratieobjecten.

Variabele Nieuwe Variabele Export

Directory-element = Directory's. Nomenclatuur. FindByCode("000000001" );
Object = Directory-element. GetObject() ;
Een voorwerp. NieuweVariabele= );

Op deze manier kunt u standaardprocedures, functies en eigenschappen (variabelen) van objecten aanvullen. Dergelijke variabelen zijn dynamisch, ze worden niet opgeslagen in de infobase en bestaan ​​alleen tijdens het werken met het ontvangen object.

Managermodule heeft allemaal dezelfde mogelijkheden, het enige verschil is dat u om het te gebruiken geen specifiek object hoeft te verkrijgen; met de managermodule kunt u met de gehele verzameling objecten van een bepaald type werken.

Procedure NewProcedure() Exporteren

Directory-element = Directory's. Nomenclatuur. NieuweProcedure();

Of voor een variabele:

Variabele Nieuwe Variabele Export

Directory-element = Directory's. Nomenclatuur. nieuwVariabele;

Laten we eens kijken naar de verschillen in het gebruik van de objectmodule en de managermodule aan de hand van het voorbeeld van de procedure voor het maken van een afgedrukte vorm van een document.

Wanneer u de objectmodule gebruikt, ziet de code er als volgt uit:

Functie Afdrukken Document (Link) Exporteren
//U moet een link naar een specifiek document doorgeven aan deze functie
TabDoc retourneren;
Eindfunctie

Op het documentformulier moet u een procedure maken die een link naar het document doorgeeft aan de afdrukfunctie.

&OnClient
Procedure Afdrukken (opdracht)
TabDoc = PrintOnServer();
TabDoc. Show() ;
EindeProcedure
&Op server
Functie PrintOnServer()
Doc = FormAttributesValue("Object" );
Retourdoc. PrintDocument(Object.Link) ;
Eindfunctie

Het nadeel van deze methode is dat er slechts één object wordt afgedrukt. Als u meerdere documenten tegelijk wilt afdrukken, moet u ze allemaal ophalen en vervolgens de functie oproepen vanuit de objectmodule. Dit vereist aanzienlijke systeembronnen, omdat wanneer een object wordt opgehaald, het gehele object in het RAM wordt geplaatst.

Vanuit prestatieoogpunt is het veel beter om waar mogelijk de managermodule te gebruiken. In ons voorbeeld ziet de oplossing voor het probleem er als volgt uit.
Functie PrintOnServer()
Retourdocumenten. OnsDocument. PrintDocument(ArrayLinks);
Eindfunctie

Als u de managermodule gebruikt, kan de afdrukprocedure zowel vanuit het documentformulier als vanuit het lijstformulier worden aangeroepen, waarbij koppelingen naar verschillende documenten in een array worden doorgegeven. In dit geval hoeft het systeem niet elk document uit de array op te halen, waardoor systeembronnen aanzienlijk worden bespaard.

Dus wanneer gebruik je een objectmodule en wanneer een managermodule?

Het hangt allemaal af van de taak. Als een verwijzing naar een object voldoende is om het te voltooien (bijvoorbeeld een afdruktaak), dan kunt u beter de managermodule gebruiken. Als het de taak is om gegevens te wijzigen, bijvoorbeeld het invullen van een document, dan moet u deze ophalen en de objectmodule gebruiken.

Het artikel vervolgt de serie “Eerste stappen in de ontwikkeling van 1C”, en bespreekt in detail de volgende kwesties:

  • Wat is een softwaremodule en uit welke onderdelen bestaat deze?
  • Waar is de applicatiemodule voor? Waarom zijn het er twee? Wanneer begint welke? Wat zijn de subtiliteiten van het werk?
  • Welke gebeurtenissen houden verband met de start van de systeemwerking, hoe en waar moeten deze worden verwerkt?
  • Waar is de externe aansluitmodule voor? Wanneer en hoe gebruik je het?
  • Wanneer wordt de sessiemodule gebruikt?
  • Wat zijn algemene modules? Wat zijn de eigenschappen en bedieningsregels? Waarom de eigenschap 'Hergebruik van retourwaarden' gebruiken?
  • Wanneer wordt de formuliermodule gebruikt en welke gebeurtenissen kunnen daarin worden verwerkt?
  • Waar is de objectmodule voor? Uit welke secties bestaat het? Hoe kan ik de beschikbare modulegebeurtenissen zien?
  • Wat zijn de subtiliteiten van het werken met waardebeheermodules (voor constanten) en recordsetmodules (voor registers)?
  • Wat zijn de verschillen tussen een objectmodule en een managermodule? Wanneer moet je dit laatste gebruiken?

Toepasbaarheid

Het artikel bespreekt het 1C:Enterprise-platform 8.3.4.496. Het materiaal is ook relevant voor huidige platformreleases.

Modules in "1C:Enterprise 8.3"

Modules zijn objecten die programmacode bevatten.

Er zijn een vrij groot aantal soorten modules op het platform, die elk hun eigen doel en kenmerken hebben.

Elke coderegel moet in een bepaalde module voorkomen. Er zijn algemene modules en objectmodules. Sommige modules kunnen zowel op de Client als op de Server worden gecompileerd, en andere alleen op de Server.

Een module kan uit meerdere onderdelen bestaan. In het gedeelte met de variabelenbeschrijving worden de lokale variabelen van deze module beschreven, die vervolgens in elke procedure kunnen worden gebruikt.

Binnen elke procedure heeft u toegang tot een modulevariabele. Bovendien kan er binnen de procedure zelf nog een variabeledeclaratie met dezelfde naam bestaan. Dit zal een lokale variabele van deze procedure zijn.

Ondanks dezelfde naam zijn dit twee verschillende variabelen: de ene wordt binnen een specifieke procedure gebruikt en de andere wordt daarbuiten gebruikt.

In sommige modules kunnen variabelen een compilatielocatie (beschikbaarheid) op de server of client hebben. Bijvoorbeeld:

De sectie waarin variabelen worden beschreven, wordt gevolgd door een sectie met procedures en functies, waarin lokale methoden van deze module worden aangegeven. Sommige modules moeten specificeren waar de procedure of functie zal worden gecompileerd.

In principe kan de compilatierichtlijn achterwege blijven. In dit geval is de standaard compilatie-instructie Server. Voor het gemak van het analyseren van programmacode wordt echter aanbevolen om expliciet aan te geven waar een bepaalde procedure zal worden gecompileerd. De volgorde waarin de procedures worden beschreven, doet er niet toe.

Aan het einde van de module, na het beschrijven van alle procedures en functies, is er een sectie van het hoofdprogramma, die enkele operators kan bevatten en lokale variabelen van de formuliermodule kan initialiseren. Deze sectie wordt uitgevoerd bij toegang tot de module.

Wanneer u dus bijvoorbeeld een elementformulier opent, wordt eerst het hoofdprogrammagedeelte van de formuliermodule uitgevoerd.

Opgemerkt moet worden dat de sectie voor het declareren van variabelen en de sectie voor het hoofdprogramma niet voor alle modules bestaan ​​(d.w.z. deze secties zijn niet geldig in sommige modules). Een sectie voor het beschrijven van procedures en functies kan in vrijwel elke module voorkomen.

Applicatiemodule

Deze module is ontworpen om de gebeurtenissen bij het opstarten en beëindigen van applicaties af te handelen. Wanneer u de toepassing start, kunt u bijvoorbeeld valutakoersen downloaden van internet. Wanneer u een applicatie beëindigt, kunt u bij de gebruiker bevestigen dat hij of zij van plan is te stoppen.

Ook in de applicatiemodule zijn er speciale handlers waarmee u externe gebeurtenissen van de apparatuur kunt onderscheppen.

Dit kunnen gebeurtenissen zijn van een magneetkaartlezer of een belastingambtenaar. En deze gebeurtenissen kunnen ook op de een of andere manier worden verwerkt.

Houd er rekening mee dat het de interactieve opstart van het systeem is die in de applicatiemodule wordt bewaakt.

De applicatiemodule werkt niet als het 1C-programma bijvoorbeeld wordt gestart in de com-verbindingsmodus. In dit geval wordt het programmavenster niet gemaakt.

Opgemerkt moet worden dat er in Platform 8.3 twee verschillende applicatiemodules zijn: de Managed Application-module en de Regular Application-module. Gebeurtenissen in beheerde applicatiemodules worden verwerkt wanneer de beheerde applicatie Thin en Thick Client en Web Client worden gestart.

Module Regelmatige toepassing werkt wanneer de Thick Client in de modus wordt uitgevoerd Regelmatige toepassing, die de gebruikelijke opdrachtinterface in het formulier bevat Hoofdmenu.

Als de applicatie actief is Beheerd en in modus Regelmatige toepassing, dan is het noodzakelijk om de afhandelingsprocedures te beschrijven zoals voor de module Beheerde applicatie en voor de module Regelmatige toepassing.

Module Beheerde applicatie kan worden geselecteerd in het contextmenu van het hoofdconfiguratieknooppunt.

Deze module kan ook worden geopend vanuit het eigenschappenpalet van het hoofdconfiguratie-element.

Om een ​​module te openen Regelmatige toepassing, moet u de configuratie-instellingen raadplegen (command Opties op het menu Dienst).

Het formulier wordt geopend Opties. Op de bladwijzer Komen vaak voor configuratiebewerkingsmodus moet worden opgegeven Beheerde applicatie En Regelmatige toepassing.

In dit geval de module Regelmatige toepassing het zal ook mogelijk zijn om te openen vanuit de eigenschappen van het hoofdknooppunt.

Lijst met gebeurtenissen waarvoor verwerking mogelijk is Beheerd En Regelmatige toepassing is hetzelfde.

Deze module kan een gedeelte voor het declareren van variabelen bevatten, een gedeelte met beschrijvingen van willekeurige procedures en functies, en een hoofdprogrammagedeelte. Maar naast willekeurige procedures en functies kunnen er ook speciale gebeurtenishandlers in de module worden geplaatst.

De lijst met beschikbare handlers kan worden bekeken door de lijst met procedures en functies van de huidige module op te roepen wanneer de module geopend is.

Het geopende venster Procedures en functies toont alle procedures en functies van deze module, evenals gebeurtenissen waarvoor nog geen handlers zijn aangemaakt.

Er zijn twee gebeurtenissen gekoppeld aan de start van het systeem (“voor” en “om”). Twee gebeurtenissen die verband houden met het afsluiten van het systeem (“before” en “at”). En ook de verwerking van externe gebeurtenissen (bijvoorbeeld gebeurtenissen van commerciële apparatuur).

Wanneer een gebeurtenishandler "before" wordt uitgevoerd, wordt aangenomen dat de actie nog niet heeft plaatsgevonden. Wanneer de gebeurtenishandler “at” wordt uitgevoerd, is de actie al voltooid.

Evenement Voordat u het systeem start vindt plaats op het moment dat Enterprise 8.3 wordt gelanceerd, maar de applicatie zelf is nog niet op het scherm verschenen. Deze gebeurtenis heeft de volgende parameter: Weigering.

Als deze parameter de waarde aanneemt WAAR, dan start de applicatie niet. Evenement Bij het opstarten van het systeem gaat ervan uit dat de actie al is voltooid, het venster al is gemaakt en in dit geval kunnen we bijvoorbeeld een speciaal formulier weergeven. Het is niet langer mogelijk om de lancering te weigeren.

Op dezelfde manier is de applicatie nog steeds geopend voordat u het systeem afsluit en kunt u weigeren deze te sluiten. Wanneer het systeem wordt afgesloten, is het toepassingsvenster al gesloten. Het is alleen mogelijk om aanvullende acties uit te voeren, bijvoorbeeld het verwijderen van enkele bestanden of het verzenden van een e-mail.

In de module Beheerde applicatie Richtlijnen voor het compileren van procedures en functies zijn niet gespecificeerd, aangezien de module volledig aan de clientzijde is gecompileerd. Dit betekent dat we in de procedures en functies van de module niet direct toegang hebben tot bijvoorbeeld naslagwerken.

Indien uit module Beheerde applicatie moet u een serveroproep doen, dan moet u hiervoor een speciaal maken met een vlag .

In de module Regelmatige toepassing Dergelijke beperkingen bestaan ​​niet, aangezien deze module wordt gecompileerd bij het laden van de Thick Client. Bijna alle soorten gegevens zijn beschikbaar in de Thick Client.

Procedures, functies en variabelen van een applicatiemodule kunnen worden omschreven als exports.

Omdat de module volledig op de Client is samengesteld, betekent dit dat we in clientprocedures toegang hebben tot deze methode en deze eigenschap.

U kunt bijvoorbeeld een procedure of functie van een applicatiemodule oproepen vanuit de formuliermodule van een object. Het wordt echter aanbevolen om Common Modules te gebruiken om algemene algoritmen te beschrijven. Het hoofddoel van de applicatiemodule is het verwerken van het start- en eindpunt.

Naar analogie met een applicatiemodule is deze module ontworpen om de openingsgebeurtenis van het programma en de afsluitgebeurtenis te verwerken.

In tegenstelling tot de applicatiemodule, die wordt gestart op het moment dat de applicatie interactief wordt gestart, werkt de externe verbindingsmodule in de COM-verbindingsmodus, d.w.z. wanneer een 1C:Enterprise 8-object wordt gemaakt en verbonden met een specifieke database.

Deze module bevat gebeurtenissen: Bij het opstarten van het systeem En Bij het afsluiten van het systeem.

De externe verbindingsmodule kan worden geopend via het contextmenu op het hoofdconfiguratieobjectniveau, of via het eigenschappenpalet voor het hoofdknooppunt.

Het proces van externe verbinding zelf is een proces van programmatisch werken met de informatiebasis, en niet interactief. Dienovereenkomstig kunt u op dit moment geen dialoogformulieren gebruiken of waarschuwingsberichten weergeven, omdat er geen gebruikersinterface is.

In de Externe Verbindingsmodule is het mogelijk om exportvariabelen en exportmethoden te beschrijven die beschikbaar zullen zijn aan de kant waar de externe oproep naar 1C:Enterprise 8.3 plaatsvindt.

Omdat er geen gebruikersinterface in een outside join zit, wordt de Outer Join-module volledig op de server samengesteld.

Sessiemodule

Deze module is nodig om sessieparameters te initialiseren. Sessieparameters zijn snelle globale variabelen waarvan de waarden overal in de configuratie beschikbaar zijn.

U kunt de sessiemodule openen via het contextmenu of via het eigenschappenpalet van het hoofdknooppunt.

De sessiemodule biedt een evenement Sessieparameters instellen.

Wanneer de applicatie start, wordt deze procedure eerst aangeroepen. Sessieparameters zijn nodig voor elke applicatiebewerking: zowel wanneer deze interactief wordt gestart als wanneer deze wordt gestart in de externe verbindingsmodus.

De Sessiemodule beschrijft verschillende acties om sessieparameters te initialiseren, afhankelijk van verschillende omstandigheden.

Deze module beschrijft in de regel verschillende procedures die vanuit de procedure worden aangeroepen Sessieparameters instellen. Daarom zijn al deze procedures gescheiden in een aparte module.

De sessiemodule draait altijd in de geprivilegieerde modus. Dit betekent dat er geen toestemmingscontrole wordt uitgevoerd bij toegang tot de database. De sessiemodule wordt op de server gecompileerd, d.w.z. Het is mogelijk om toegang te krijgen tot alle servermethoden (inclusief het lezen van waarden uit de database).

In de Sessiemodule is het mogelijk om alleen procedures en functies te definiëren, d.w.z. er is geen sectie met variabelebeschrijvingen en geen hoofdprogrammasectie. U kunt geen exportmethoden definiëren in een sessiemodule.

Als het bij het opstarten van het systeem nodig is om bepaalde acties op de server uit te voeren, bijvoorbeeld een element van een directory aan te maken, dan is het optioneel mogelijk om de sessiemodule te gebruiken, omdat het wordt op de server gecompileerd en wordt altijd betrouwbaar uitgevoerd bij het opstarten van het systeem. Er moet echter rekening worden gehouden met de volgende punten:

  • procedure Sessieparameters instellen wordt niet alleen uitgevoerd bij het opstarten van het systeem, maar ook bij toegang tot niet-geïnitialiseerde sessieparameters. Die. de SetSessionParameters-handler kan herhaaldelijk worden aangeroepen tijdens de werking van de applicatie;
  • als het aantal elementen in de sessieparameterarray nul is (de array met vereiste parameters heeft het datatype Ongedefinieerd), dan is dit het moment waarop de applicatie wordt gestart;
  • aangezien de Sessiemodule in de geprivilegieerde modus werkt en er geen controle van toegangsrechten plaatsvindt, moet u zeer zorgvuldig omgaan met databaseobjecten, aangezien de gebruiker toegang kan krijgen tot gegevens die niet aan hem mogen worden verstrekt;
  • Wanneer het systeem opstart, is het nog niet zeker of de applicatie gelanceerd zal worden. In dit geval kunnen onnodige acties worden uitgevoerd in de gebeurtenishandler SetSessionParameters.

Deze modules vertegenwoordigen een beschrijving van enkele algemene algoritmen, d.w.z. procedures en functies die vanaf verschillende plaatsen kunnen worden opgeroepen.

Logisch gerelateerde methoden kunnen worden gegroepeerd in verschillende gemeenschappelijke modules. Deze modules worden gemaakt in de afdeling Algemeen.

U kunt een willekeurig aantal gedeelde modules toevoegen. Om Common Module-methoden elders in de configuratie beschikbaar te maken, moeten ze worden gedefinieerd met het trefwoord Export. Clientprocedures van algemene modules zijn beschikbaar op de client, en serverprocedures op de server.

In Algemene Modules is alleen het gedeelte dat procedures en functies beschrijft beschikbaar. Die. in de Algemene Module kun je geen variabelen beschrijven, en je kunt ook geen gedeelte van het hoofdprogramma beschrijven.

Als een globale variabele nodig is, kunt u sessieparameters of exportvariabelen van de toepassingsmodule gebruiken.

Voor algemene modules kunt u enkele parameters instellen die het gedrag van deze module beïnvloeden. Als de eigenschap Global is ingesteld voor een module Algemeen, zijn de exportmethoden die in deze module zijn gedeclareerd, rechtstreeks van buitenaf toegankelijk, zonder aanvullende instructies.

Die. de Algemene module zal deelnemen aan de vorming van de mondiale configuratiecontext.

Eigendom Globaal voor algemene modules kan het nuttig zijn. U moet het echter niet overal voor alle gangbare modules gebruiken.

Die , die zijn gemarkeerd met het bord Globaal, wordt gecompileerd bij het opstarten van het systeem. Hoe meer van dergelijke modules, hoe langzamer het programma start.

Als de vlag Globaal Voor Algemene module niet is opgegeven, wordt de compilatie van deze module uitgevoerd op het moment dat de module voor de eerste keer wordt aangeroepen (d.w.z. nadat het systeem is opgestart).

Bovendien heeft het gebruik van globale gemeenschappelijke modules invloed op het begrip van de code. Methoden van een niet-globale gemeenschappelijke module worden via de naam aangeroepen Algemene module en de naam van de methode, bijvoorbeeld:
Kostenberekeningsmodule.DistributeIndirectCosts();

In dit geval moeten de namen van de gemeenschappelijke modules de inhoud van de daarin beschreven procedures weerspiegelen. Het opgeven van de naam van de gemeenschappelijke module bij het aanroepen van een procedure helpt om de code beter te begrijpen.

Voor Algemene module V Eigenschappenpalet U kunt de eigenschap instellen Bevoorrecht.

De bevoorrechte module beheert geen toegangsrechten. Dit is nodig als Algemene module Het is vereist om massale gegevensverwerking uit te voeren en gegevens uit de database te verkrijgen.

Het controleren van toegangsrechten verhoogt de tijd die nodig is om toegang te krijgen tot een database, en massa-algoritmen moeten vaak zo snel mogelijk werken.

Loonadministratie is bijvoorbeeld een arbeidsintensieve operatie. Het moet zo snel mogelijk gebeuren. Om dit te doen, worden algoritmen die de lonen berekenen in een geprivilegieerde positie geplaatst .

Tegelijkertijd vallen alle procedures die zorgen voor het invullen van loondocumenten daarbuiten Gemeenschappelijke modules. Het is in deze procedures dat de controle van de toegangsrechten wordt uitgevoerd.

Op deze manier kunnen aanzienlijke prestatieverbeteringen worden bereikt. Dit is met name het geval bij het gebruik van een mechanisme voor rij-voor-rij toegangscontrole tot tabelrecords.

Als een Gemeenschappelijke Module geprivilegieerd is, kunnen de procedures van deze module alleen op de Server worden gecompileerd.

Er zijn situaties waarin een object niet toegankelijk zou moeten zijn voor de gebruiker, bijvoorbeeld een bepaalde map. Maar bij het uitvoeren van een bepaald document is verwijzing naar dit naslagwerk noodzakelijk.

Die. Het is nodig om de gebruikersrechten tijdelijk uit te breiden en ze vervolgens terug te brengen naar hun oorspronkelijke staat. Dit effect kan worden verkregen door privileged te gebruiken Gemeenschappelijke modules.

Om dit te doen in een bevoorrechte Algemene module U moet een procedure maken die toegang krijgt tot de vereiste gegevens.

Deze procedure wordt opgeroepen vanuit het overeenkomstige document. Die. de gebruiker krijgt feitelijk uitgebreide rechten op het moment dat deze procedure wordt aangeroepen.

Voor Gemeenschappelijke modules Het is mogelijk om de compilatielocatie op te geven. De vlaggen worden gebruikt om te bepalen of de gemeenschappelijke module beschikbaar zal zijn op de client (beheerde applicatie), op de server of in de externe verbindingsmodus.

Als u bovendien de configuratiebewerkingsmodus overschakelt naar Beheerde applicatie en reguliere applicatie, is een andere compilatiecontext mogelijk: Client (reguliere applicatie).

Er zijn dus vier opties voor de werking van het programma. Afhankelijk van de actieve applicatie, afhankelijk van het werk op de Client of op de Server, zullen bepaalde Gemeenschappelijke Modules beschikbaar of niet beschikbaar zijn.

Naast de mogelijkheid om compilatievlaggen te specificeren, is het mogelijk om compilatierichtlijnen op te geven voor procedures en functies die zich in de Common Module bevinden.

Als er voor een methode een compilatierichtlijn is gespecificeerd, wordt de beschikbaarheid van de specifieke methode, hoewel de Common Module beschikbaar is in alle gespecificeerde contexten, beperkt door de compilatierichtlijn.

In dit geval is de procedure niet toegankelijk in een context die niet toegankelijk is voor de hele module.

Als u geen compilatierichtlijn voor een procedure (functie) opgeeft, wordt deze gecompileerd in alle contexten die voor de module zijn gedefinieerd.

Die. In principe zullen er meerdere kopieën van de procedure worden gemaakt. De keuze voor een bepaald gecompileerd exemplaar hangt af van waar de procedure wordt aangeroepen (door de dichtstbijzijnde aanroepregel). Er moet rekening mee worden gehouden dat de code van een dergelijke procedure moet worden geschreven, rekening houdend met de beschikbaarheid ervan in alle contexten die voor de module zijn gedefinieerd.

Generieke modules die gelijktijdig toegankelijk zijn in verschillende contexten zijn in de eerste plaats bedoeld om procedures te creëren die in meerdere contexten toegankelijk zijn.

Bij het maken van een algemene module wordt het als goede praktijk beschouwd om geen compilatierichtlijnen op te geven. Die. De beschikbaarheid van procedures en functies moet worden bepaald door de eigenschappen van de module zelf.

Met deze aanpak zullen clientprocedures zich in afzonderlijke gemeenschappelijke modules bevinden, en zullen serverprocedures zich in afzonderlijke gemeenschappelijke modules bevinden.

Modules waarvoor meerdere compilatievlaggen zijn ingesteld, worden in de praktijk uiterst zelden gebruikt. Dit zijn enkele veelvoorkomende acties die beschikbaar zijn op zowel de client als de server. Meestal zijn dit enkele eenvoudige berekeningen.

Belangrijk! Het is voor de Klant mogelijk om toegang te krijgen tot de exportservermethoden van een Gemeenschappelijke Module, maar alleen als deze Gemeenschappelijke Module alleen op de Server is gecompileerd. In dit geval wordt er een speciale vlag voorzien om toegang te verlenen aan de Klant .

Voor niet-globale Common-modules is het mogelijk om de waarden die door functies worden geretourneerd in de cache op te slaan. Die. Na de eerste aanroep van een functie kan het systeem het resultaat van de uitvoering ervan onthouden. Als deze functie opnieuw wordt aangeroepen met dezelfde parameters, retourneert het systeem de waarde uit de cache.

Het doel van dit mechanisme is om herhaalde oproepen te versnellen. Om dit gedrag te configureren, moet u het volgende doen Eigenschappenpalet module, stel de juiste waarde in voor de eigenschap Hergebruik van retourwaarden.

Standaard is deze eigenschap ingesteld op Niet gebruiken. Andere mogelijke waarden: cache Tijdens het gesprek, of Voor de duur van de sessie.

Het is zinvol om deze eigenschap alleen te gebruiken voor die functies waarvan de resultaten uitsluitend afhankelijk zijn van de invoerparameters. Dit mechanisme is alleen beschikbaar voor niet-globale gemeenschappelijke modules.

Als de waarde van de overeenkomstige parameter For the Duration of the Call wordt geselecteerd, blijft de cache actief zolang de procedure van waaruit de General Module-methode is aangeroepen, actief is. Als de waarde Voor de duur van de sessie is geselecteerd, wordt er voorwaardelijk van uitgegaan dat de cache werkt terwijl de gebruiker aan het werk is.

Er zijn echter bepaalde tijdsbeperkingen. De cache wordt automatisch gewist 20 minuten nadat de waarde in de cache is ingevoerd.

Formuliermodule

Deze module is ontworpen om gebruikersacties te verwerken. Beschrijf bijvoorbeeld het algoritme voor hoe een programma reageert als er op een knop wordt gedrukt. Of controleer bijvoorbeeld direct op het moment dat u een waarde in een veld invoert, op juistheid.

Naast gebeurtenissen die verband houden met formulierbesturingselementen (knoppen, invoervelden), zijn er gebeurtenissen die rechtstreeks verband houden met het formulier zelf.

U kunt bijvoorbeeld de openingsgebeurtenis van het formulier afhandelen en een initiële initialisatie uitvoeren. U kunt ook de formuliersluitingsgebeurtenis afhandelen en controleren of de gebruiker alles correct heeft ingevoerd.

Er zijn gecontroleerde vormen en reguliere vormen. De modules van deze formulieren verschillen voornamelijk doordat de beheerde formuliermodule duidelijk is onderverdeeld in context. Elke procedure (functie) moet een compilatierichtlijn hebben. In normale vorm wordt alle code op de Klant gebruikt.

In een beheerde formuliermodule kunt u procedures en functies declareren, variabelen declareren en een gedeelte van het hoofdprogramma beschrijven.

De programmacode van het hoofdprogramma wordt uitgevoerd op het moment van initialisatie van het formulier, d.w.z. wanneer de gebruiker het begint te openen. De afbeelding toont een lijst met standaardgebeurtenissen voor een beheerd formulier.

De lijst met gebeurtenissen van een beheerd formulier is ook rechtstreeks zichtbaar in de lijst met eigenschappen van het formulier zelf. Deze lijst wordt opgeroepen in de beheerde formuliereneditor.

In een beheerd formulier kunt u de schrijfgebeurtenis van het item afhandelen. Deze gebeurtenis is alleen aanwezig voor objectvormen (directories, documenten en enkele andere). Als het formulier niet aan een specifiek object is gebonden, is er geen schrijfgebeurtenis.

Voor een module met een reguliere vorm is de lijst met standaardevenementen wat kleiner, omdat In een beheerde vorm zijn veel gebeurtenissen gemaakt om te worden gekoppeld (de ene wordt uitgevoerd op de client en de andere op de server). In de normale vorm wordt alle code op de Klant uitgevoerd.

Objectmodule

Deze modules zijn typisch voor mappen, documenten, plannen voor soorten berekeningen, rekeningschema's en vele andere objecten. De objectmodule is ontworpen om standaardgebeurtenissen af ​​te handelen. Bijvoorbeeld een gebeurtenis voor het invoeren van een directory-element, een gebeurtenis voor het schrijven van een element, het verwijderen, het plaatsen van een document, enz.

In principe bestaat de write-event ook in de Formuliermodule. Maar de schrijfgebeurtenis in de Formuliermodule vindt plaats tijdens het interactieve opnameproces, wanneer met een specifiek formulier wordt gewerkt.

De write-gebeurtenis in de Objectmodule wordt uitgevoerd bij elke schrijfactie vanuit elke vorm van het gegeven object. Als het object programmatisch wordt geschreven, wordt bovendien de modulegebeurtenis van het object geactiveerd.

In de schrijfgebeurtenis van de Objectmodule kunt u alle controles inbouwen voor de juistheid van de gegevens die worden geschreven, aangezien deze procedure bij absoluut elke opname wordt uitgevoerd.

De module van dit object kan worden opgeroepen via het contextmenu, vanuit het Objecteigenschappenpalet en vanuit het objectbewerkingsvenster.

De onderstaande afbeelding toont een lijst met beschikbare directorymodule-gebeurtenissen.

In de Objectmodule kunt u een sectie plaatsen voor het beschrijven van variabelen, waarin willekeurige functies worden beschreven die mogelijk niet aan een gebeurtenis zijn gekoppeld, evenals een sectie van het hoofdprogramma.

In het hoofdprogrammagedeelte kunt u bijvoorbeeld lokale variabelen van een bepaalde module initialiseren. Deze programmacode wordt uitgevoerd wanneer deze objectmodule wordt benaderd.

Opgemerkt moet worden dat alle procedures van de Objectmodule op de Server worden gecompileerd. Dienovereenkomstig zijn compilatierichtlijnen voor procedures en functies van de Objectmodule niet vereist. Sommige configuratieobjecten hebben geen objectmodules.

Dit komt door de kenmerken van de objecten zelf. Dergelijke objecten omvatten Constanten En Registreert. Voor Constante er is geen objectmodule, maar er is een zeer vergelijkbare module genaamd Waardemanager module.

IN Waardemanager module je kunt schrijfgebeurtenissen afhandelen Constanten en vulverificatieverwerking.

De volledige modulecontext wordt uitgevoerd op de server.

Voor registers is er een Recordset Module.

Deze module heeft ook de mogelijkheid om schrijfgebeurtenissen af ​​te handelen en bezettingscontroles uit te voeren.

In Object Modules, Value Manager Modules (voor constanten) en Recordset Modules (voor registers) kun je methoden beschrijven die exporteerbaar gemaakt kunnen worden, en deze methoden zullen van buitenaf toegankelijk zijn.

Die. Naast het gebruik van de vaste methoden van een objectklasse, kunt u in de Objectmodule aanvullende methoden voor een object maken. Deze module moet de bijbehorende procedure beschrijven met het trefwoord Exporteren.

Dan is het mogelijk om van buitenaf toegang te krijgen tot deze procedure. Bovendien wordt deze methode weergegeven in de contexttooltip. Nieuwe methoden in de contexttooltip worden gemarkeerd in een blauw lettertype (blauw pictogram P() voor procedures en F() voor functies).

Op dezelfde manier kunt u een nieuwe eigenschap maken door een variabele met het trefwoord te declareren Exporteren. Deze woning is ook van buitenaf te betreden.

Op deze manier is het mogelijk om de functionaliteit van objecten uit te breiden (om nieuwe methoden en nieuwe eigenschappen te definiëren). De eigenschappen zijn echter dynamisch en worden niet in de database opgeslagen.

Als u een eigenschap moet gebruiken voor een object dat in de database wordt opgeslagen, moet u een objectattribuut maken.

Managermodule

Deze module bestaat voor veel objecten (directories, documenten, registers, etc.). De module wordt geopend via het contextmenu voor het object of via Eigenschappenpalet of via het bewerkingsvenster.

In de Manager Module kunt u enkele standaardgebeurtenissen overschrijven, bijvoorbeeld in VerwerkenOntvangenSelectieGegevens, wanneer een element uit de map wordt geselecteerd, kan er wat extra filtering of controle worden uitgevoerd.

Daarnaast kunt u in de Manager Module extra methoden aanmaken en aangeven dat het exportmethoden zijn. In dit geval is het mogelijk om van buitenaf toegang te krijgen tot deze methoden.

Om deze oproep uit te voeren, is het noodzakelijk om het gegevenstype te verkrijgen DirectoryManager.

Het verschil tussen de exportmethoden van de Manager Module en de Object Module is dat om toegang te krijgen tot de methode van de Object Module, u eerst het object zelf moet verkrijgen (dat wil zeggen, op de een of andere manier een link moet verkrijgen en deze link vervolgens in een object moet converteren). .

Hierna zullen exportvariabelen en -methoden van de Objectmodule beschikbaar zijn. Voor de Manager Module is de oproep eenvoudiger, bijvoorbeeld:
Directory's.Tegenpartijen.Methodenaam

Dit zijn twee verschillende oproepen. Converteren van referentie naar object (methode GetObject) is een vrij serieuze actie voor het systeem, omdat bij het ontvangen van een object absoluut alle gegevens van dit object worden gelezen, wat behoorlijk lang kan duren.

Het tweede verschil is dat Objectmodule aangeroepen in de context van een specifiek element. Dienovereenkomstig kunnen we aannemen dat het van toepassing is op een bepaald element (in de meeste gevallen is dit precies de gebruikte logica).

Wat de Manager Module betreft, deze beschrijft een aantal algemene acties voor een groep of voor alle elementen van een map of een document. Als u bijvoorbeeld een directory-item wilt afdrukken, kunt u de Objectmodule gebruiken.

Maar in de Manager Module is het mogelijk om een ​​universeler mechanisme te creëren dat onder andere een groep elementen afdrukt.

Bovendien is toegang tot de objectmodule nog steeds een langere actie. Daarom heeft het meer de voorkeur om dit probleem op te lossen in de managermodule.

Hiermee is onze kennismaking met de modules in de 1C:Enterprise systeemconfiguratie afgerond. Als we al het bovenstaande kort samenvatten, komen we op de volgende conclusies:

  • Een softwaremodule maakt deel uit van de configuratie en kan alleen tekst in de ingebouwde 1C-taal bevatten
  • Softwaremodules zijn geclassificeerd volgens de typen die we in dit artikel hebben besproken. Elke weergave wordt bepaald door de plaatsing en de beschikbare programmacontext.
  • De structuur van de module bestaat uit verschillende secties, die in een bepaalde volgorde zijn gerangschikt. De samenstelling van de onderdelen wordt bepaald door het type module.

Merk ook op dat we bewust één type module hebben weggelaten, namelijk de commandomodule. Het is niets opmerkelijks en we nodigen u uit om vertrouwd te raken met de functionaliteit ervan.

Tot nu toe hebben we al onze programmacode afzonderlijk van de applicatieoplossing bekeken, en in de regel hebben we deze in een kleine eigen testconfiguratie geschreven. Bent u zich ervan bewust dat u “niet zomaar kunt gaan” en de code van een standaardconfiguratie kunt gaan bewerken? Nee? Dan leggen we het in het volgende artikel allemaal uit!

Oké 693 22.12.13 22:44 Momenteel on-topic

() Laten we beginnen met het belangrijkste. Onzin en onzin zijn een poging om uitingen te kleuren met emoties. Dat is vrij moeilijk te doen via het brievengenre. Dit is dus een uiting van mijn onbegrip, en geen poging om te beledigen. Het is fijn om met iemand te maken te hebben die dit begrijpt. Als ik je beledigd heb, spijt me dat.

De analogie is simpelweg ongepast vanwege de aard van OOP. OOP is de erfgenaam van procedureel, modulair programmeren. Het is alsof je vader en zoon vergelijkt, terwijl je de zoon als voorbeeld voor de vader houdt.

Het is moeilijk om de verklaring te betwisten. Maar de betekenis van deze opmerking houdt zwak verband met de passage waarop in het artikel commentaar wordt gegeven.

Dit houdt verband met het voorbeeld dat in het artikel wordt gegeven. Daar heeft de methode een compilatierichtlijn en om de een of andere reden is het trefwoord “exporteren” weggelaten.

Het feit dat hij nog nooit iets heeft hoeven doen, betekent niet dat het niet relevant is, of dat anderen het niet doen.

Ja. Ik hoefde geen algemene modules te wijzigen voor externe verwerking. Het was noodzakelijk om verschillende versies te maken voor verschillende configuraties.

In een typische toepassing worden ze vaak gebruikt om puur interfaceproblemen op te lossen:

Dat is het, op de gebruikelijke manier. Ik voorspel niet de dood ervan (een zeer goede en bewezen oplossing), maar de trends zijn zodanig dat 1C steeds verder in de richting van gedistribueerd computergebruik beweegt, met de expliciete toewijzing van code op basis van de plaatsen waar het actief is. Hier werkt het zelden (als het überhaupt werkt): "Alles staat op de client, en we komen er wel uit" of "Laten we de server een paar keer terughalen - we hebben tenslotte gigabit."

Ik denk dat het nuttig zou zijn om de abstractie die inherent is aan het concept van "GeneralModule" uit te breiden en in de configuratie te introduceren
entiteiten van een nieuw type, bijvoorbeeld "ExecutableModule", vergelijkbaar met Module-objecten van MS VBA.
"GeneralModules" zou een speciaal geval zijn van "ExecutableModule" -objecten, die zich ongeveer bevinden
in dezelfde relatie als de objecten "GeneralForm" en eenvoudigweg "Form"....

Om te beginnen zou het leuk zijn om naamruimten en module-metagegevens in 1C te implementeren, en niet zoals het nu is (citaat van de syntaxisassistent); "Ongedefinieerd - omdat er niet wordt verwacht dat het werkt vanuit de ingebouwde taal"

Laten we aannemen dat het aantal toestanden dat in het formulier wordt gebruikt groot is, en laten we dat aannemen
bij gebruik van een formulier is de kans op het realiseren van een specifieke toestand laag;

Bij klassiek webprogrammeren wordt dit opgelost door de mogelijkheid om formulieren in formulieren en asynchrone oproepen in te sluiten (AJAX), helaas werd dit door 1C genegeerd. Er blijven dus drie opties over:

1. Gebruik verschillende formulieren
2. Draag alle benodigde gegevens over aan de klant
3. Trek de server eruit.

Over het algemeen worden serveroproepen die buiten de context vallen niet als een slechte zaak beschouwd en moeten ze worden vermeden.
- In principe is er zelfs een mening (waar ik het niet echt mee eens ben) dat er een soort “extra” nummer is
servercontextaanroepen zijn het minste kwaad als hun optimalisatie "te" de "leesbaarheid" van de code in de war brengt.


Serveroproepen die buiten de context vallen, zijn ontworpen om het verkeer te verminderen bij het overbrengen van gegevens van de client naar de server. Dit is de enige manier waarop ze verschillen van contextuele.

Voorbeeld 1: u heeft een tegenpartij nodig op basis van het document.

client server
1. selectieformulier --> formulier verkrijgen
2. Bij het wisselen<--
3. Tegenpartij ophalen --> DocumentBase["Tegenpartij"]

In de derde stap heeft het geen zin om het hele formulier, met alle details, naar de server te slepen. Daarom is het raadzaam om OnServerWithoutContext te gebruiken.

In uw versie kunt u eenvoudigweg het volgende gebruiken:

Voor objectmodulemethoden:

&OpServerZonder context
Functie Something_with_something (ProcessingObject, ProcessingTypeString, Parameters)
RetourformulierDataValue(ProcessingObject, Type(ProcessingTypeString)).FunctionWe Need(Parameters);
Eindfunctie

Voor managermodulemethoden:

&OpServerZonder context
Functie Something_with_something (naam, parameters)
Retourverwerking[Naam].FunctieWeNeed(Parameters);
Eindfunctie

Vraag: Hoe kan ik een functie aanroepen vanuit een beheerd formulier dat zich in een module van een ander object bevindt?


Hoe roep ik een functie aan vanuit een beheerd formulier dat zich in een module van een ander object bevindt?

Ik ben het aan het proberen:
&Op server
Procedure MyProcedure() Processing = Form AttributesValue("Record", Type("ProcessingObject.NecessaryProcessing")); Resultaat = Processing.ExportProcedureInNecessaryProcessingModule("NecessaryParameter"); Einde procedurefout: ongeldige parameter nr. 1

Antwoord: En dit geldt niet alleen voor de verwerking, maar in het algemeen, in principe zelfs voor alle objecten.

Je kunt ook de details en andere onzin invullen die er zijn van de ene verwerking naar de andere.


Hallo!
Geef me een codevoorbeeld van hoe u een ingevuld afgedrukt formulier programmatisch kunt oproepen met behulp van een link naar een object,
Bijvoorbeeld,
link=Documenten.InvoiceIssued.FindByCode(...);
...
link...Afdrukbare formuliergegevens ophalen...
enzovoort

Antwoord: Roep de opdracht aan van waaruit het afdrukken van dit document wordt aangeroepen en daarin is één parameter uw document.

Vraag: beheerde formulieren in UPP 1.3


Goedemiddag In de configurator maak ik een verwerking aan met een beheerd formulier (zet de vlag op beheerd). In de bedrijfsmodus wordt het helemaal niet geopend. Wie kwam het tegen? hoe open ik het aangemaakte beheerde formulier?

Antwoord:+() Klassiekers van het genre:

<<К сожалению, это невозможно. Свойство "Использовать управляемые формы в обычном приложении" не влияет на внешние обработки и отчёты. В обычном приложении можно открывать только обычные формы таких объектов, а в управляемом только управляемые. Это ограничение платформы.>>

Vraag: [OPGELOST] Een formuliermoduleprocedure aanroepen vanuit een door externe verwerking beheerde formuliermodule


Beste experts, vertel me alstublieft:
8.3.9.2170
Hoe kan ik een procedure van de formuliermodule van dit document oproepen vanuit een clientprocedure van een externe verwerkingsformuliermodule (EF) die aan een document is gekoppeld?
Bedankt

Antwoord:

Ontvang een documentformulier en roep de gewenste exportfunctie aan in de resulterende formuliermodule.

Vraag: Beheerde formulieren, evenals aanvullende formulieren. mapgegevens


Hallo!
Ik ben eindelijk begonnen met beheerde formulieren, en met aanvullende formulieren. directorygegevens die zijn ingevoerd in de bedrijfsmodus.
1C: Enterprise 8.3 (8.3.8.2054), 1C: Geïntegreerde automatisering 2 (2.2.3.196).
Helaas kwam ik een probleem tegen en kon ik via Google geen oplossing vinden.
De essentie is dit: er is externe verwerking, waarbij de gebruiker een item selecteert, waarna de andere velden van deze verwerking automatisch moeten worden ingevuld met extra velden. details van deze nomenclatuur. Ik struikelde helemaal aan het begin: ik probeer deze extra's te krijgen met een verzoek. benodigdheden.
1C
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 & Op de clientprocedure NomenclatureOnChange(Element)AdditionalDetails = RequestAdditionalDetails(Object. Nomenclatuur) ; Einde van de procedure en op de serverfunctie Verzoek om aanvullende details (nomenclatuur) Verzoek om aanvullende details = New Request() ; Verzoek om aanvullende details. Tekst = "SELECTEER | NomenclatuurAanvullende details.Link, | NomenclatuurAanvullende details.Eigendom, | NomenclatuurAanvullende details.Waarde, | NomenclatuurAanvullende details.TextString| VAN | Directory.Nomenclatuur.Aanvullende details AS-nomenclatuurAanvullende details|WAAR | NomenclatuurAanvullende details.Link = &Nomenclatuur"; Verzoek om aanvullende details. SetParameter("Nomenclatuur", Objectnomenclatuur) ; ResultRequest voor aanvullende details = Verzoek voor aanvullende details. Uitvoeren(). Ontladen() ; RetourresultaatAanvraagAanvullende details; einde functie

Problemen

"(ExternalProcessing.PrintLabels.Form.Form.Form(11)): Fout bij het aanroepen van de contextmethode (RequestAdditionalDetails)
Aanvullende details = Verzoek om aanvullende details (Object.Nomenclatuur);
vanwege:
Fout bij gegevensoverdracht tussen client en server. De waarde is van een ongeldig type.
vanwege:
XDTO-gegevensconversiefout:
HomeProperties: ret Vorm: Element Type: (http://www.w3.org/2001/XMLSchema)anyType
vanwege:
Type mapping-fout:
Er is geen weergave voor het type "(http://v8.1c.ru/8.1/data/core)ValueTable""

Help alstublieft!

Toegevoegd na 9 minuten
In regel 28 "RetourresultaatRequest voor aanvullende details;" er wordt een tabel met waarden geretourneerd. Ik probeer de variabele "Aanvullende details" op de client aan te duiden als "Nieuwe waardetabel" - het programma klaagt dat het niet weet wat "Waardetabel" is. Ik probeer de context te veranderen van "NaClient" naar "NaServer" - dan klaagt hij niet langer, maar de debugger stopt ook met werken.

Antwoord: Dankje voor het antwoord!

Plaats een tabelvormig deel van een soortgelijke structuur op het formulier

Maar waarom heeft de gebruiker dit tabelgedeelte nodig? Gewoon een onnodige wirwar aan verwerkingsformulieren.

Na 6 minuten toegevoegd
Ik zal proberen eenvoudig een tabblad te maken. deel van de verwerking (zonder het op het formulier te plaatsen) en laad het resultaat erin.

En zo gebeurde het! Bedankt!

Vraag: Werken met een waardentabel in een beheerde vorm


Goedemiddag. De Waardentabel blijft mij verbazen. Dit is de eigenlijke vraag: ik creëer een externe verwerking (gecontroleerde vorm). Ik maak een “TK” -attribuut met het type “Waardetabel”. En ik sleep het naar het formulier. Vervolgens schrijf ik in de formuliermodule “TZ.” en na de punt in de vervolgkeuzelijst zie ik de eigenschap “Columns” niet. Vervolgens creëer ik programmatisch:

en schrijf “TZ.” in de vervolgkeuzelijst er is een eigenschap "Kolommen". De vraag is waarom????????

Antwoord:

bericht van Briolin

En 1C moet zo worden gedaan dat direct in de configurator wordt geschreven dat het attribuut op het formulier het datatype DataFormsCollection heeft!

Dan is het niet duidelijk naar welk applicatieobject dit vertaald kan worden

Vraag: Beheerd formulier (element toegankelijkheid)


Met behulp van het UTeshki 10.3.40.1-platform 8.3.9.2033 maak ik een productselectieformulier op internet. Ik creëerde een nieuwe rol en begon geleidelijk de toegang tot objecten daarvoor te openen. Alles was in orde totdat ik de map Waarden van eigenschappen van objecten bereikte. Het is duidelijk dat er in 10 geen beheerde formulieren zijn, ze worden allemaal tijdens het proces gegenereerd, maar als het formulier voor het selecteren van dezelfde “Objecteigenschappen” normaal wordt gemaakt, wordt het formulier voor het selecteren van “Waarden van Objecteigenschappen” gemaakt met inactieve elementen... En wat heb ik niet geprobeerd: rechten op lezen, kijkend naar zowel het naslagwerk als het Plan met soorten kenmerken.Eigenschappen van objecten... niets helpt. Waar graven? De mogelijkheid om een ​​apart formulier te maken en alles daarin op te schrijven hoeft niet geboden te worden, dat heb ik laten staan ​​voor het geval de reden onduidelijk blijft.

Antwoord: Misschien is de toegankelijkheid op basis van een bepaalde voorwaarde in het formulier zelf ingesteld?

Vraag: Bij het sluiten van een beheerd directoryformulier schrijf ik naar het informatieregister,


Bij het sluiten van het beheerde directoryformulier schrijf ik naar het informatieregister,
Als er een nieuw directory-item wordt gemaakt, is de fout dat het directory-object nog niet is gemaakt. Ik begrijp niet hoe ik moet wachten tot het mapobject is gemaakt.
Ik noem het tenslotte bij het sluiten van het directoryformulier?

&Op server
Procedure bij ClosingOnServer() Set=InformationRegisters.ContactInformation.CreateRecordSet(); Set.Select.Object.Set(huidig_.Object); Set.Selectie.Type.Set(huidige_.type); Set.Selectie.View.Set(huidige_.weergave);

Antwoord:() Misschien is dit bij de uitvoering ervan niet nodig. () Ik denk dat hij zich niet correct heeft uitgedrukt. Dit betekende gewijzigde gegevens. U deed iets soortgelijks toen hij de internationalisering introduceerde, door detailreeksen op te slaan met Engelse/Spaanse en andere namen. Om niet voor elke taal rekwisieten voor het object te maken, heb ik alles in het register gezet. En de opname werd parallel gemaakt met de opname van een map, zoiets als dit.

Vraag: Structuur van elementen op een beheerd formulier. Hoe vind je het gewenste element zonder door de elementen te zoeken?


U moet een tabelveld vinden op een beheerd formulier. Ik doe dit door alle formulierelementen te herhalen. Misschien is er een andere manier om het gewenste element van een beheerd formulier te vinden?
Een voorbeeld van een brute force-zoekopdracht:
//***** FlFoundTablePart = Onwaar; Voor elke El uit _ThisForm.Elements Cyclus If TypeValue(El)<>Type("FormTable") Ga vervolgens verder; stop als; Als El.DataPath = "Object." + _TablePartName Dan FlFoundTabularPart = Waar; Afbreken; stop als; Eindcyclus; //*****

Vraag: Schrijf() in beheerde vorm


De situatie is als volgt:

Ik heb ZUP 3.0. Er is een document “De personeelstabel wijzigen”. Er kunnen tijdelijk personeelsfuncties in een organisatie worden ingevoerd. Om dit te doen, wordt met behulp van de knop een document gemaakt van het brondocument voor de geselecteerde posities om posities uit te sluiten. Ik moet deze link opslaan. Om dit te doen, heb ik een attribuut gemaakt met het type “Bezettingstabel wijzigen”.
Nadat ik het document programmatisch heb geschreven, schrijf ik de link in dit attribuut. Ik roep de schrijfmethode aan vanuit een beheerd formulier met parameters... En hij pakt het en stelt de opnamemodus in op CONDUCT. Uiteraard heb ik het originele document ingevuld! maar ik moet één detail opschrijven en het originele document NIET opnieuw posten. Het is alsof hij mijn parameter niet heeft gezien. De code staat hieronder. De vraag is: wat heb ik verkeerd gedaan?

DesintegratieDocument.Write(DocumentWriteMode.Write);
Object.itr_DestructionDocument=DemontageDocument.Link; Recordparameters = Nieuwe structuur(); RecordingParameters.Insert("RecordingMode",DocumentRecordingMode.Recording); ThisForm.Record(RecordParameters);

Antwoord: Eigenlijk heb ik ontdekt hoe het moet... dus ik zal het delen.

U moet een object programmatisch ontvangen om te bewerken, ondanks het feit dat het formulier geopend is, het op de gebruikelijke manier bewerken en schrijven, en het formulier vervolgens eenvoudig opnieuw lezen.