1c come chiamare una funzione da un modulo comune. Moduli comuni

L'articolo continua la serie "Primi passi nello sviluppo di 1C", discute in dettaglio le seguenti questioni:

• Cos'è un modulo software e in quali sezioni è composto?
• A cosa serve il modulo applicativo? Perché ce ne sono due? Quando inizia quale? Quali sono le sottigliezze del lavoro?
• Quali eventi sono associati all'avvio del funzionamento del sistema, come e dove elaborarli?
• A cosa serve il modulo di connessione esterno? Quando e come usarlo?
• Quando viene utilizzato il modulo di sessione?
• Quali sono i moduli comuni? Quali sono le sue proprietà e regole operative? Perché utilizzare la proprietà “Riutilizzo dei valori restituiti”?
• Quando viene utilizzato il modulo modulo e quali eventi possono essere elaborati in esso?
• A cosa serve il modulo oggetto? In quali sezioni è composto? Come posso vedere gli eventi dei moduli disponibili?
• Quali sono le sottigliezze nel lavorare con i moduli value manager (per costanti) e i moduli recordset (per registri)?
• Quali sono le differenze tra un modulo oggetto e un modulo manager? Quando dovresti usare quest'ultimo?

Applicabilità

L'articolo discute la piattaforma 1C:Enterprise 8.3.4.496. Il materiale è rilevante anche per le versioni attuali della piattaforma.

Moduli in "1C:Enterprise 8.3"

I moduli sono quegli oggetti che contengono il codice del programma.

Esistono numerosi tipi di moduli nella piattaforma, ognuno dei quali ha il proprio scopo e le proprie caratteristiche.

Qualsiasi riga di codice deve trovarsi in qualche modulo. Esistono moduli di uso generale e moduli oggetto. Alcuni moduli possono essere compilati sia sul Client che sul Server, altri solo sul Server.

Un modulo può essere composto da più sezioni. La sezione di descrizione delle variabili descrive le variabili locali di questo modulo, che possono successivamente essere utilizzate in qualsiasi procedura.

All'interno di ciascuna procedura è possibile accedere a una variabile del modulo. Inoltre all'interno della procedura stessa può esserci un'altra dichiarazione di variabile con lo stesso nome. Questa sarà una variabile locale di questa procedura.

Nonostante lo stesso nome, si tratta di due variabili diverse: una viene utilizzata all'interno di una procedura specifica, l'altra al di fuori di essa.

In alcuni moduli, le variabili possono avere una posizione di compilazione (disponibilità) sul Server o sul Client. Per esempio:

La sezione che descrive le variabili è seguita da una sezione di procedure e funzioni, dove sono indicati i metodi locali di questo modulo. Alcuni moduli devono specificare dove verrà compilata la procedura o la funzione.

In linea di principio la direttiva di compilazione può essere omessa. In questo caso, la direttiva di compilazione predefinita è Server. Tuttavia, per comodità di analisi del codice del programma, si consiglia di indicare esplicitamente dove verrà compilata una determinata procedura. L'ordine in cui le procedure sono descritte non ha importanza.

Alla fine del modulo, dopo aver descritto tutte le procedure e le funzioni, si trova una sezione del programma principale, che può contenere alcuni operatori e inizializzare le variabili locali del modulo form. Questa sezione viene eseguita quando si accede al modulo.

Quindi, ad esempio, quando si apre un elemento del modulo, viene eseguita per prima la parte principale del programma del modulo del modulo.

Va notato che la sezione di dichiarazione delle variabili e la sezione del programma principale non esistono per tutti i moduli (cioè queste sezioni non sono valide in alcuni moduli). Una sezione per descrivere procedure e funzioni può esistere assolutamente in qualsiasi modulo.

Modulo applicativo

Questo modulo è progettato per gestire gli eventi di avvio e chiusura dell'applicazione. Ad esempio, quando avvii l'applicazione, puoi scaricare i tassi di cambio da Internet. Quando chiudi un'applicazione, puoi confermare all'utente che intende uscire.

Inoltre nel modulo applicativo sono presenti appositi gestori che permettono di intercettare eventi esterni provenienti dalle apparecchiature.

Potrebbero essere eventi provenienti da un lettore di carte magnetiche o da un registrar fiscale. E questi eventi possono anche essere elaborati in qualche modo.

Tieni presente che nel modulo dell'applicazione viene monitorato l'avvio interattivo del sistema.

Il modulo applicativo non funzionerà se il programma 1C viene avviato, ad esempio, in modalità di connessione com. In questo caso, la finestra del programma non viene creata.

È opportuno notare che nella Piattaforma 8.3 sono presenti due diversi moduli applicativi: il modulo Applicazione Gestita e il modulo Applicazione Regolare. Gli eventi del modulo dell'applicazione gestita vengono elaborati quando vengono avviati il ​​Thin e Thick Client e il Web Client dell'applicazione gestita.

Modulo Applicazione regolare funziona quando si esegue Thick Client in modalità Applicazione regolare, che contiene la consueta interfaccia di comando nel formato Menu principale.

Se l'applicazione è in esecuzione Gestito e in modalità Applicazione regolare, allora è necessario descrivere le procedure del gestore come per il modulo Applicazione gestita e per il modulo Applicazione regolare.

Modulo Applicazione gestita può essere selezionato dal menu contestuale del nodo di configurazione root.

Questo modulo può essere aperto anche dalla tavolozza delle proprietà dell'elemento di configurazione root.

Per aprire un modulo Applicazione regolare, è necessario fare riferimento alle impostazioni di configurazione (command Opzioni sul menu Servizio).

Si aprirà il modulo Opzioni. Sul segnalibro Sono comuniè necessario specificare la modalità di modifica della configurazione Applicazione gestita E Applicazione regolare.

In questo caso il modulo Applicazione regolare sarà possibile aprire anche dalle proprietà del nodo root.

Elenco degli eventi per i quali è possibile elaborare Gestito E Applicazione regolareè la stessa.

Questo modulo può contenere una sezione di dichiarazione delle variabili, una sezione di descrizione di procedure e funzioni arbitrarie e una sezione di programma principale. Ma oltre a procedure e funzioni arbitrarie, nel modulo possono essere posizionati gestori di eventi speciali.

L'elenco dei gestori disponibili può essere visualizzato richiamando l'elenco delle procedure e delle funzioni del modulo corrente quando il modulo è aperto.

La finestra Procedure e funzioni che si apre visualizza tutte le procedure e le funzioni di questo modulo, nonché gli eventi per i quali non sono ancora stati creati gestori.

Ci sono due eventi associati all'avvio del sistema (“prima” e “a”). Due eventi associati allo spegnimento del sistema (“prima” e “alle”). E anche elaborazione di eventi esterni (ad esempio, eventi di attrezzature commerciali).

Quando viene eseguito un gestore eventi "prima", si considera che l'azione non abbia ancora avuto luogo. Quando viene eseguito il gestore dell'evento "at", l'azione è già stata completata.

Evento Prima di avviare il sistema si verifica nel momento in cui viene avviato Enterprise 8.3, ma l'applicazione stessa non è ancora apparsa sullo schermo. Questo evento ha il seguente parametro: Rifiuto.

Se questo parametro assume il valore VERO, l'applicazione non si avvierà. Evento All'avvio del sistema presuppone che l'azione sia già stata completata, la finestra sia già stata creata e in questo caso possiamo, ad esempio, visualizzare qualche modulo speciale. Non è più possibile rifiutare il lancio.

Allo stesso modo, prima di spegnere il sistema, l'applicazione è ancora aperta e puoi rifiutarti di chiuderla. Quando il sistema si spegne, la finestra dell'applicazione è già chiusa. È possibile solo eseguire azioni aggiuntive, ad esempio eliminare alcuni file o inviare un'e-mail.

Nel modulo Applicazione gestita Non vengono specificate direttive per la compilazione di procedure e funzioni, in quanto il modulo è interamente compilato lato Client. Ciò significa che nelle procedure e nelle funzioni del modulo non potremo accedere direttamente, ad esempio, ai libri di consultazione.

Se dal modulo Applicazione gestitaè necessario effettuare una chiamata al server, quindi per questo sarà necessario creare uno speciale con una bandiera .

Nel modulo Applicazione regolare Non esistono restrizioni di questo tipo poiché questo modulo verrà compilato durante il caricamento del Thick Client. Quasi tutti i tipi di dati sono disponibili nel Thick Client.

Procedure, funzioni e variabili di un modulo applicativo possono essere descritte come esportazioni.

Dato che il modulo è compilato interamente sul Client, ciò significa che nelle procedure client possiamo accedere a questo metodo e a questa proprietà.

Ad esempio, puoi chiamare una procedura o una funzione di un modulo applicativo dal modulo form di un oggetto. Tuttavia, si consiglia di utilizzare i moduli comuni per descrivere algoritmi generali. Lo scopo principale del modulo applicativo è elaborare il punto iniziale e il punto finale.

Per analogia con un modulo applicativo, questo modulo è predisposto per elaborare l'evento di apertura del programma e l'evento di spegnimento.

A differenza del modulo applicativo, che viene avviato al momento del lancio interattivo dell'applicazione, il modulo di connessione esterna funziona in modalità connessione COM, cioè quando un oggetto 1C:Enterprise 8 viene creato e connesso a un database specifico.

Questo modulo contiene eventi: All'avvio del sistema E Allo spegnimento del sistema.

Il modulo di connessione esterna può essere aperto utilizzando il menu contestuale a livello dell'oggetto di configurazione root o la tavolozza delle proprietà per il nodo root.

Lo stesso processo di connessione esterna è un processo di lavoro programmatico con la base informativa e non interattivo. Pertanto al momento non è possibile utilizzare moduli di dialogo o visualizzare messaggi di avviso, poiché non esiste un'interfaccia utente.

Nel modulo di connessione esterna è possibile descrivere le variabili di esportazione e i metodi di esportazione che saranno disponibili sul lato in cui avviene la chiamata esterna a 1C:Enterprise 8.3.

Poiché non esiste un'interfaccia utente in un join esterno, il modulo Outer Join è compilato interamente sul server.

Modulo di sessione

Questo modulo è necessario per inizializzare i parametri di sessione. I parametri di sessione sono variabili globali veloci i cui valori sono disponibili ovunque nella configurazione.

È possibile aprire il Modulo Sessione tramite il menu contestuale o tramite la tavolozza delle proprietà del nodo radice.

Il Modulo Sessione fornisce un evento Impostazione dei parametri di sessione.

All'avvio dell'applicazione, questa procedura viene richiamata per prima. I parametri di sessione sono necessari per qualsiasi operazione dell'applicazione: sia quando avviata in modo interattivo sia quando avviata in modalità di connessione esterna.

Il Modulo Sessione descrive varie azioni per inizializzare i parametri della sessione in base alle diverse condizioni.

Questo modulo, di regola, descrive diverse procedure chiamate dalla procedura Impostazione dei parametri di sessione. Pertanto, tutte queste procedure sono separate in un modulo separato.

Il modulo di sessione viene sempre eseguito in modalità privilegiata. Ciò significa che non verrà eseguito alcun controllo delle autorizzazioni quando si accede al database. Il modulo di sessione è compilato sul Server, cioè È possibile accedere a qualsiasi metodo del server (inclusa la lettura dei valori dal database).

Nel Modulo Sessione è possibile definire solo procedure e funzioni, ovvero non esiste una sezione di descrizione delle variabili e nessuna sezione del programma principale. Non è possibile definire metodi di esportazione in un modulo di sessione.

Se all'avvio del sistema è necessario eseguire alcune azioni sul Server, ad esempio creare un elemento di una directory, allora, come opzione, è possibile utilizzare il Modulo Sessione, perché viene compilato sul Server e viene sempre eseguito in modo affidabile all'avvio del sistema. Bisogna però tenere in considerazione i seguenti punti:

• procedura Impostazione dei parametri di sessione viene eseguito non solo all'avvio del sistema, ma anche quando si accede a parametri di sessione non inizializzati. Quelli. il gestore SetSessionParameters può essere chiamato ripetutamente durante il funzionamento dell'applicazione;
• se il numero di elementi nell'array dei parametri di sessione è zero (l'array dei parametri richiesti ha un tipo di dati Undefinito), allora questo è il momento in cui viene avviata l'applicazione;
• poiché il Modulo Sessione funziona in modalità privilegiata e non ci sarà alcun controllo dei diritti di accesso, dovresti lavorare con molta attenzione con gli oggetti del database, poiché l'utente può accedere a dati che non dovrebbero essergli forniti;
• All'avvio del sistema non è ancora noto con certezza se l'applicazione verrà avviata. In questo caso, è possibile che vengano eseguite azioni non necessarie nel gestore eventi SetSessionParameters.

Questi moduli rappresentano una descrizione di alcuni algoritmi generali, ad es. procedure e funzioni richiamabili da diversi luoghi.

I metodi logicamente correlati possono essere raggruppati in diversi moduli comuni. Questi moduli vengono creati all'interno del ramo Generale.

È possibile aggiungere un numero qualsiasi di moduli condivisi. Per rendere disponibili i metodi del modulo comune altrove nella configurazione, è necessario definirli con la parola chiave Export. Le procedure client dei moduli comuni saranno disponibili sul client e quelle server sul server.

Nei Moduli Generali è disponibile solo la sezione che descrive procedure e funzioni. Quelli. nel Modulo Generale non è possibile descrivere variabili e non è possibile descrivere una sezione del programma principale.

Se è necessaria una variabile globale, è possibile utilizzare i parametri di sessione o le variabili di esportazione del modulo dell'applicazione.

Per i moduli Generali, è possibile impostare alcuni parametri che influenzeranno il comportamento di questo modulo. Se la proprietà Global è impostata per un modulo Generale, i metodi di esportazione dichiarati in questo modulo saranno accessibili direttamente dall'esterno, senza alcuna istruzione aggiuntiva.

Quelli. IL Modulo generale parteciperà alla formazione del contesto di configurazione globale.

Proprietà Globale per i moduli generali può essere utile. Tuttavia, non dovresti usarlo ovunque per tutti i moduli comuni.

Quelli , che sono contrassegnati dal segno Globale, verrà compilato all'avvio del sistema. Maggiore è il numero di moduli di questo tipo, più lento sarà l'avvio del programma.

Se la bandiera Globale Per Modulo generale non è specificato, la compilazione di questo modulo verrà eseguita al momento della prima chiamata ad esso (cioè dopo l'avvio del sistema).

Inoltre, l'uso di moduli comuni globali influisce sulla comprensione del codice. I metodi di un modulo comune non globale vengono chiamati tramite il nome Modulo generale e il nome del metodo, ad esempio:
Modulo di calcolo dei costi.DistributeIndirectCosts();

In questo caso i nomi dei Moduli Comuni dovranno riflettere il contenuto delle procedure in essi descritte. Specificare il nome del Modulo Comune quando si richiama una procedura aiuta a comprendere meglio il codice.

Per Modulo generale V Tavolozza Proprietàè possibile impostare la proprietà Privilegiato.

Il modulo privilegiato non controlla i diritti di accesso. Ciò è necessario se Modulo generaleÈ necessario eseguire l'elaborazione dei dati di massa, ottenendo i dati dal database.

Il controllo dei diritti di accesso aumenta il tempo necessario per accedere a un database e gli algoritmi di massa spesso devono funzionare il più rapidamente possibile.

Ad esempio, il libro paga è un'operazione ad alta intensità di risorse. È necessario farlo il più rapidamente possibile. Per fare ciò, gli algoritmi che calcolano i salari vengono posti in posizione privilegiata .

Allo stesso tempo, tutte le procedure che garantiscono il completamento dei documenti relativi alle buste paga ne sono escluse Moduli comuni. È in queste procedure che viene effettuato il controllo dei diritti di accesso.

In questo modo è possibile ottenere miglioramenti significativi delle prestazioni. Ciò è particolarmente vero quando si utilizza un meccanismo per il controllo dell'accesso riga per riga ai record della tabella.

Se viene privilegiato un Modulo Comune, allora le procedure di questo modulo possono essere compilate solo sul Server.

Ci sono situazioni in cui alcuni oggetti dovrebbero essere inaccessibili all'utente, ad esempio una determinata directory. Ma quando si realizza un documento, è necessario fare riferimento a questo libro di consultazione.

Quelli. È necessario espandere temporaneamente i diritti degli utenti e quindi riportarli al loro stato originale. Questo effetto può essere ottenuto utilizzando Privilegiato Moduli comuni.

Per farlo in maniera privilegiata Modulo generaleÈ necessario creare una procedura che acceda ai dati richiesti.

Questa procedura verrà richiamata dal documento corrispondente. Quelli. all'utente vengono effettivamente concessi diritti estesi nel momento in cui viene richiamata questa procedura.

Per Moduli comuniÈ possibile specificare il percorso di compilazione. I flag vengono utilizzati per determinare se il Modulo comune sarà disponibile sul Client (applicazione gestita), sul Server o in modalità Connessione Esterna.

Inoltre, se si passa dalla modalità di modifica della configurazione all'applicazione gestita e all'applicazione normale, sarà possibile un altro contesto di compilazione: Client (applicazione normale).

Pertanto, ci sono quattro opzioni per il funzionamento del programma. A seconda dell'applicazione in esecuzione, a seconda del lavoro sul Client o sul Server, alcuni Moduli Comuni saranno disponibili o non disponibili.

Oltre alla possibilità di specificare flag di compilazione, è possibile specificare direttive di compilazione per procedure e funzioni situate nel Modulo comune.

Se viene specificata una direttiva di compilazione per un metodo, sebbene il Modulo comune sia disponibile in tutti i contesti specificati, la disponibilità del metodo specifico sarà limitata dalla direttiva di compilazione.

In questo caso non è possibile accedere alla procedura in un contesto non accessibile all'intero modulo.

Se non si specifica una direttiva di compilazione per una procedura (funzione), questa verrà compilata in tutti i contesti definiti per il modulo.

Quelli. In sostanza, verranno effettuate più copie della procedura. La scelta di una particolare istanza compilata dipende da dove viene chiamata la procedura (dalla regola di chiamata più vicina). Va tenuto presente che il codice di tale procedura deve essere scritto tenendo conto della sua disponibilità in tutti i contesti definiti per il modulo.

I moduli generici accessibili simultaneamente in diversi contesti sono progettati principalmente per creare procedure accessibili in più contesti.

Quando si crea un modulo comune, è considerata buona pratica non specificare le direttive di compilazione. Quelli. La disponibilità di procedure e funzioni dovrebbe essere determinata dalle proprietà del modulo stesso.

Con questo approccio, le procedure client saranno posizionate in moduli comuni separati e le procedure server saranno posizionate in moduli comuni separati.

I moduli che hanno impostati più flag di compilazione vengono utilizzati molto raramente nella pratica. Queste sono alcune azioni comuni disponibili sia sul client che sul server. Di solito questi sono alcuni semplici calcoli.

Importante! È possibile per il Client accedere ai metodi del server di esportazione di un Modulo comune, ma solo se questo Modulo comune è compilato solo sul Server. In questo caso viene fornito un flag speciale per consentire l'accesso da parte del Client .

Per i moduli Common non globali, è possibile memorizzare nella cache i valori restituiti dalle funzioni. Quelli. Dopo la prima chiamata di una funzione, il sistema può ricordare il risultato della sua esecuzione. Se questa funzione viene richiamata nuovamente con gli stessi parametri, il sistema restituirà il valore dalla cache.

Lo scopo di questo meccanismo è accelerare la ripetizione delle chiamate. Per configurare questo comportamento è necessario Tavolozza Proprietà modulo, impostare il valore appropriato per la proprietà Riutilizzo dei valori restituiti.

Per impostazione predefinita, questa proprietà è impostata su Non utilizzare. Altri valori possibili: cache Durante la chiamata, O Per tutta la durata della sessione.

È opportuno utilizzare questa proprietà solo per quelle funzioni i cui risultati dipendono esclusivamente dai parametri di input. Questo meccanismo è disponibile solo per i moduli comuni non globali.

Se viene selezionato il valore del parametro corrispondente Per tutta la durata della chiamata, la cache funzionerà finché è in esecuzione la procedura da cui è stato chiamato il metodo Modulo Generale. Se è selezionato il valore Per tutta la durata della sessione, si presuppone condizionatamente che la cache funzionerà mentre l'utente sta lavorando.

Tuttavia, ci sono alcune restrizioni temporali. La cache viene cancellata automaticamente 20 minuti dopo che il valore è entrato nella cache.

Modulo modulo

Questo modulo è progettato per elaborare le azioni dell'utente. Ad esempio, descrivi l'algoritmo su come reagisce un programma quando viene premuto un pulsante. Oppure, ad esempio, nel momento in cui inserisci un valore in un campo, verificane immediatamente la correttezza.

Oltre agli eventi associati ai controlli del modulo (pulsanti, campi di input), ci sono eventi associati direttamente al modulo stesso.

Ad esempio, puoi gestire l'evento di apertura del modulo ed eseguire alcune inizializzazioni iniziali. Puoi anche gestire l'evento di chiusura del modulo e verificare se l'utente ha inserito tutto correttamente.

Esistono forme controllate e forme regolari. I moduli di questi moduli differiscono principalmente per il fatto che il modulo del modulo gestito è chiaramente suddiviso in contesto. Ogni procedura (funzione) deve avere una direttiva di compilazione. Nella forma normale, tutto il codice viene utilizzato sul Client.

In un modulo con modulo gestito è possibile dichiarare procedure e funzioni, dichiarare variabili e descrivere una sezione del programma principale.

Il codice del programma principale verrà eseguito al momento dell'inizializzazione del modulo, ad es. quando l'utente inizia ad aprirlo. La figura mostra un elenco di eventi standard per un modulo gestito.

L'elenco degli eventi di un modulo gestito è visibile anche nell'elenco delle proprietà direttamente del modulo stesso. Questo elenco viene richiamato nell'editor dei moduli gestiti.

In un modulo gestito è possibile gestire l'evento di scrittura dell'elemento. Questo evento è presente solo per i moduli oggetto (directory, documenti e altri). Se il modulo non è associato a un oggetto specifico, non vi è alcun evento di scrittura.

Per un modulo di forma regolare, l'elenco degli eventi standard è leggermente più piccolo, perché In una forma gestita molti eventi vengono fatti accoppiare (uno viene eseguito sul Client e l'altro sul Server). Nella sua forma normale, tutto il codice viene eseguito sul Client.

Modulo oggetto

Questi moduli sono tipici per directory, documenti, piani per tipi di calcoli, piani dei conti e molti altri oggetti. Il modulo oggetto è progettato per gestire eventi standard. Ad esempio, un evento per l'inserimento di un elemento di directory, un evento per la scrittura di un elemento, l'eliminazione, la pubblicazione di un documento, ecc.

In linea di principio l'evento di scrittura esiste anche nel Modulo Modulo. Ma l'evento di scrittura nel modulo modulo si verifica durante il processo di registrazione interattiva, quando si lavora con un modulo specifico.

L'evento di scrittura nel modulo oggetto verrà eseguito su qualsiasi scrittura da qualsiasi forma dell'oggetto dato. Inoltre, se l'oggetto viene scritto a livello di codice, verrà attivato l'evento del modulo dell'oggetto.

Nell'evento di scrittura del Modulo Oggetto è possibile inserire tutti i controlli sulla correttezza dei dati in scrittura, poiché questa procedura verrà eseguita assolutamente al momento di qualsiasi registrazione.

Il modulo di questo oggetto può essere richiamato tramite il menu contestuale, dalla palette Proprietà oggetto e dalla finestra di modifica dell'oggetto.

La figura seguente mostra un elenco degli eventi disponibili del modulo directory.

Nel Modulo Oggetto è possibile inserire una sezione per la descrizione delle variabili, che descrive funzioni arbitrarie che potrebbero non essere associate ad un evento, nonché una sezione del programma principale.

Nella sezione principale del programma è possibile, ad esempio, inizializzare le variabili locali di un determinato modulo. Questo codice di programma verrà eseguito quando si accede a questo oggetto Modulo.

Da notare che tutte le procedure del Modulo Oggetto sono compilate sul Server. Pertanto non sono necessarie direttive di compilazione per procedure e funzioni dell'Object Module. Alcuni oggetti di configurazione non dispongono di moduli oggetto.

Ciò è dovuto alle caratteristiche degli oggetti stessi. Tali oggetti includono Costanti E Registri. Per Costante non esiste un modulo oggetto, ma esiste un modulo molto simile chiamato Modulo Gestore del valore.

IN Modulo Gestore del valore puoi gestire gli eventi di scrittura Costanti e compilando l'elaborazione di verifica.

L'intero contesto del modulo viene eseguito sul Server.

Per i registri esiste un modulo Recordset.

Questo modulo ha anche la capacità di gestire eventi di scrittura ed eseguire controlli di occupazione.

In Object Modules, Value Manager Modules (per costanti) e Recordset Modules (per registri) è possibile descrivere metodi che possono essere resi esportabili e questi metodi saranno accessibili dall'esterno.

Quelli. Oltre a utilizzare i metodi fissi di una classe di oggetto, è possibile creare metodi aggiuntivi per un oggetto nel Modulo Oggetto. Questo modulo dovrebbe descrivere la procedura corrispondente con la parola chiave Esportare.

Successivamente sarà possibile accedere a tale procedura dall'esterno. Inoltre, questo metodo verrà visualizzato nella descrizione comando contestuale. I nuovi metodi nella descrizione comando contestuale sono evidenziati in carattere blu (icona blu P() per le procedure e F() per le funzioni).

Allo stesso modo, puoi creare una nuova proprietà dichiarando una variabile con la parola chiave Esportare. A questo immobile si può accedere anche dall'esterno.

In questo modo è possibile espandere le funzionalità degli oggetti (definire nuovi metodi e nuove proprietà). Tuttavia, le proprietà sono dinamiche e non vengono salvate nel database.

Se è necessario utilizzare una proprietà per un oggetto che verrà archiviato nel database, è necessario creare un attributo dell'oggetto.

Modulo Gestore

Questo modulo esiste per molti oggetti (rubriche, documenti, registri, ecc.). Il modulo viene aperto tramite il menu contestuale dell'oggetto oppure tramite Tavolozza Proprietà o attraverso la finestra di modifica.

Nel Modulo Manager puoi sovrascrivere alcuni eventi standard, ad esempio in ElaborazioneRicezioneSelezioneDati, quando un elemento viene selezionato dalla directory, è possibile eseguire alcuni filtri o controlli aggiuntivi.

Inoltre, puoi creare metodi aggiuntivi nel Modulo Manager e indicare che sono metodi di esportazione. In questo caso è possibile accedere a queste modalità dall'esterno.

Per eseguire questa chiamata è necessario ottenere il tipo di dati Gestore di directory.

La differenza tra i metodi di esportazione del Modulo Manager e del Modulo Oggetto è che per accedere al metodo del Modulo Oggetto, è necessario prima ottenere l'oggetto stesso (cioè ottenere in qualche modo un collegamento e poi convertire questo collegamento in un oggetto) .

Successivamente saranno disponibili le variabili e i metodi di esportazione del modulo oggetto. Per il Modulo Gestore la chiamata è più semplice, ad esempio:
Directory.Controparti.NomeMetodo

Si tratta di due ricorsi diversi. Convertire da riferimento a oggetto (metodo OttieniOggetto) è un'azione abbastanza seria per il sistema, poiché quando si riceve un oggetto vengono letti assolutamente tutti i dati di questo oggetto, il che può richiedere molto tempo.

La seconda differenza è questa Modulo oggetto chiamato nel contesto di un elemento specifico. Di conseguenza, possiamo supporre che sia applicabile per un dato elemento (nella maggior parte dei casi, questa è esattamente la logica utilizzata).

Per quanto riguarda il Modulo Manager, descrive alcune azioni comuni per un gruppo o per tutti gli elementi di una directory o di qualche documento. Ad esempio, se devi stampare un elemento di una directory, puoi utilizzare il modulo oggetto.

Ma nel Modulo Manager è possibile creare un meccanismo più universale che stamperà, tra le altre cose, un gruppo di elementi.

Inoltre, l'accesso all'oggetto Modulo risulta comunque un'azione più lunga. Pertanto, è preferibile risolvere questo problema nel modulo di gestione.

Questo conclude la nostra conoscenza dei moduli nella configurazione del sistema 1C:Enterprise. Se riassumiamo brevemente tutto quanto sopra, la conclusione è la seguente conclusione:

• Un modulo software è una parte della configurazione che può contenere solo testo nel linguaggio 1C integrato
• I moduli software sono classificati in base ai tipi discussi in questo articolo. Ciascuna vista è determinata dal suo posizionamento e dal contesto del programma disponibile.
• La struttura del modulo è composta da diverse sezioni, disposte in una determinata sequenza. La composizione delle sezioni è determinata dal tipo di modulo.

Si noti inoltre che abbiamo deliberatamente omesso un tipo di modulo, vale a dire il modulo di comando. Non è niente di straordinario e ti invitiamo a familiarizzare con le sue funzionalità.

Finora abbiamo considerato tutto il codice del nostro programma separatamente dalla soluzione applicativa e, di regola, lo abbiamo scritto in una nostra piccola configurazione di prova. Sei consapevole che “non puoi semplicemente andare” e iniziare a modificare il codice di una configurazione standard? NO? Poi nel prossimo articolo vi spiegheremo tutto!

Oggi esamineremo i moduli comuni, cosa sono, perché sono necessari e come utilizzarli. È possibile inserire funzioni utilizzate in diversi documenti in un modulo comune. Ad esempio, calcolando l'importo nella parte tabellare del documento.

Prendiamo ad esempio la nostra vecchia configurazione, che utilizzavo negli articoli precedenti. Sono presenti due documenti: Arrivo delle merci al magazzino e Rilascio delle merci al magazzino. Entrambi i documenti dispongono di procedure che calcolano l'importo in una riga tabellare.

Ogni documento contiene lo stesso codice per il calcolo dell'importo.

Procedura MaterialiPriceOnChange(Elemento)
Riga TabularPart = Elements.Materials.CurrentData;
TabularPartLine.Amount = TabularPartLine.Quantity * TabularPartLine.Price;
Fine della procedura

Oggi lo sposteremo in un modulo comune e lo chiameremo dal documento.

Creiamo un modulo generale per il calcolo dell'importo

E quindi iniziamo, prima devi creare un modulo comune. Per fare ciò, vai nel configuratore, cerca la voce Moduli generali, clicca col tasto destro e aggiungine di nuovi, scrivi il nome WorkWithDocuments. Inseriamo il seguente codice al suo interno.

Assicurati inoltre di selezionare le caselle accanto a Client (applicazione gestita) e Server nella finestra delle proprietà.

Ora devi modificare leggermente il codice nel modulo del modulo documento. A sinistra nella configurazione cerchiamo il documento Arrivo Merci, espandiamo la finestra alla finestra Moduli, facciamo doppio clic su Modulo Documento e nella finestra del modulo che si apre andiamo alla scheda Modulo in basso. Abbiamo questo codice

Questa procedura funziona quando si modifica la Quantità nella parte tabellare del documento Entrata Merci e calcola l'importo.

&SuClient



Fine della procedura

E questa procedura inizia a funzionare quando il Prezzo cambia nella parte tabellare del documento Entrata Merci e calcola l'importo.

&SuClient

Riga TabularPart = Elements.Materials.CurrentData;
TabularPartLine.Amount = TabularPartLine.Quantity * TabularPartLine.Price;
Fine della procedura

Sostituiscilo con questo

&SuClient
Procedura MaterialiQuantityOnChange(Elemento)
Riga TabularPart = Elements.Materials.CurrentData;

Fine della procedura
&SuClient
Procedura MaterialiPriceOnChange(Elemento)
Riga TabularPart = Elements.Materials.CurrentData;
WorkWithDocuments.CalculateSum(TabularPartRow);
Fine della procedura

Come hai notato, cambia solo una riga; a prima vista può sembrare che una riga sia stata sostituita da un'altra. Ma non dimenticare che questo è un esempio. Infatti, la quantità di codice può essere molto maggiore se, ad esempio, hai eseguito calcoli utilizzando una formula complessa, nel qual caso il codice verrà notevolmente ridotto.

Facciamo lo stesso per il documento Rilascio della merce dal magazzino, eseguiamo e controlliamo la funzionalità del codice. Quindi tu ed io abbiamo realizzato il primo modulo comune, spero che il mio articolo possa essere utile a qualcuno.

I moduli comuni sono responsabili della memorizzazione di procedure e funzioni chiamate da altri punti del sistema 1C. È considerata buona pratica inserire il codice richiamato più volte in una procedura in un modulo comune. Questa regola è universale per tutte le configurazioni, quindi qualsiasi sviluppatore 1C dovrebbe essere in grado di lavorare con questi oggetti di configurazione. Per fare ciò è necessario comprendere tutte le sfumature ed essere in grado di utilizzare correttamente le opportunità offerte dalla piattaforma.

Creazione di un modulo comune in 1C

Dopo aver creato una funzione in uno dei moduli dell'oggetto, era necessario utilizzare un algoritmo simile in un altro posto. La cosa migliore da fare qui è trasferire il codice in un modulo comune, ma prima è necessario crearlo. Per fare ciò, dobbiamo andare al configuratore e trovare la scheda "Generale" nell'albero di configurazione. Quindi seleziona "Moduli generali" e utilizza il pulsante a forma di più bianco sul cerchio verde.

Le proprietà del modulo comune aggiunto si apriranno sulla destra e dobbiamo capire cosa significa ciascuna di esse. Possono avere direzioni diverse, quindi, prima di allestire un nuovo oggetto, è consigliabile decidere cosa immagazzinare lì. Semmai in futuro sarà possibile modificare le proprietà in base ai compiti:

• "Globale". Questo flag è impostato se il modulo è destinato a memorizzare procedure e funzioni che devono essere chiamate senza specificare il nome del modulo. Naturalmente devono essere esportabili e i loro nomi devono essere univoci nel contesto dell’intero contesto globale. Non differiranno nell'uso dalle funzioni standard della piattaforma;
• "Cliente". Dipende dalle impostazioni del sistema e regola se le procedure del modulo possono essere eseguite lato client;
• "Server". Sono contrassegnati i moduli generali, all'interno dei quali sono previsti algoritmi da posizionare per l'esecuzione sul server;
• "Unione esterna". Le procedure del modulo con questa proprietà attivata potranno essere eseguite attraverso il collegamento di una sorgente esterna;
• "Chiamata del server". Responsabile di consentire alle procedure dal modulo di chiamare il server durante l'esecuzione sul client;
• "Privilegiato". L'abilitazione di questa impostazione consentirà di non verificare i diritti di accesso durante l'esecuzione del codice di procedura del modulo. È possibile chiamare un modulo comune con questa impostazione solo sul server. Le impostazioni del client e della connessione esterna verranno ripristinate;
• "Riutilizzo". Può assumere i seguenti valori: “Non utilizzare”, “Per tutta la durata della sessione”, “Per tutta la durata della chiamata”. Quando si richiama più volte una procedura, il sistema può utilizzare i dati precedentemente calcolati all'interno della procedura (chiamata) o durante la durata dell'intera sessione (lancio 1C). Dovresti fare molta attenzione con questa impostazione, poiché possono verificarsi errori a causa dell'uso errato di tali moduli.

Ci sono situazioni in cui è necessario creare un modulo comune con chiamate di procedura sul server e sul client con differenze nell'algoritmo. Le direttive del preprocessore con controllo vengono utilizzate per delimitare il codice. Di conseguenza, ci sarà un codice per la chiamata al server e un altro per la chiamata al client.
Procedura AlgorithmServerClient() Export #If ThinClient Then // il codice viene eseguito se la chiamata alla procedura proviene dal client ShowUserAlert("Sul client"); ElseIf Server Then // il codice viene eseguito se la chiamata alla procedura proviene dal server VariableServer = "Server call"; #TheEndIfTheEndProcedure

Un esempio di trasferimento del codice su un modulo 1C comune

Consideriamo una situazione in cui abbiamo due eventi nel modulo del documento che coinvolgono una procedura per moltiplicare quantità e prezzo nella sezione tabellare. Questo è un algoritmo abbastanza comune, poiché si trova in molti documenti di approvvigionamento e vendita. Trasferiamo il codice della procedura in un modulo comune, che dovrà essere prima creato per poter utilizzare questo codice in altri documenti.

Poiché per il nostro compito abbiamo solo bisogno di una chiamata dal client e non abbiamo bisogno dei dati dal database, impostiamo solo il flag "Client". Se desideri utilizzare lo stesso modulo in futuro per calcoli più complessi, seleziona "Server" nelle proprietà. La fase preparatoria è completata e possiamo passare alla scrittura del codice.

Creiamo una procedura di esportazione nel modulo e trasferiamo lì l'algoritmo per il calcolo dell'importo dalla procedura nel modulo del modulo. La stringa della sezione della tabella verrà utilizzata come parametro di procedura in input. Nel modulo del modulo documento, cambiamo le chiamate di procedura nello stesso modulo in una chiamata di procedura dal modulo generale.

Frammento 1

Frammento 2

All'avvio del sistema non noteremo la differenza, ma questa struttura del codice è molto più comoda da leggere e mantenere. Naturalmente, in questo esempio, la quantità di codice non può mostrare tutti i vantaggi. Nel caso di un algoritmo complesso per decine di oggetti di configurazione, il guadagno nella quantità di codice e nella sua struttura influenzerà anche la velocità del sistema. Inoltre, gli sviluppatori esperti di 1C consigliano di non descrivere gli algoritmi nei moduli del modulo, ma di inserirli in moduli generali configurati correttamente.

Quando sviluppi moduli generali, dovresti tenere conto delle regole generalmente accettate per la loro creazione:

• Collocare procedure e funzioni relative a funzionalità simili in un modulo comune separato;
• Il nome del modulo dovrebbe riflettere la sua appartenenza al contesto (Client, Server) ed evitare parole comuni (gestori, procedure, ecc.);
• Separare la logica del server interno dell'applicazione e la logica del client per l'interfaccia;
• Fai attenzione quando crei un modulo condiviso globale. Non dover fare riferimento ad una procedura attraverso il nome del modulo può creare confusione, soprattutto se il sistema è supportato da più team di sviluppo.

I moduli creati correttamente ti aiuteranno a navigare nella struttura della configurazione e ad apportare miglioramenti molto più velocemente. Se vedi l'opportunità di rendere universale una funzione utile e inserirla in un modulo comune, allora fallo. In futuro, tu e i tuoi colleghi sarete grati per questa decisione.