Quindi in 1C ci sono libri di consultazione. Ad esempio, un elenco di merci (nomenclatura). Lì indicheremo un elenco di beni venduti dalla nostra organizzazione.

Con l'aiuto di tale directory possiamo organizzare un listino prezzi per i clienti e un rapporto sulle vendite per la direzione.

I prodotti sono diversi. Ad esempio, prodotti e chimica. Cosa dovremmo fare se il manager ci chiede di fare un rapporto: quanti soldi abbiamo guadagnato dai prodotti e quanto dalla chimica?

Facilmente! - risponderemo. È necessario aggiungere una directory di Tipi di prodotti e aggiungere i seguenti dettagli nella directory Nomenclatura. Ora, quando introduciamo un nuovo prodotto, dovremo selezionare il tipo di prodotto.

Tuttavia, le ragazze non sono contente di questa innovazione: dopotutto, ora devono compilare un intero campo aggiuntivo e hanno già molto lavoro e non hanno tempo per fare nulla. E in generale! - dicono - abbiamo 900 tipi di prodotti, e solo 50 tipi di prodotti chimici! Anche uno sciocco può vedere che il tipo di prodotto predefinito dovrebbe essere prodotti.

Grande! – noteremo. E cosa fare?

Costanti 1C

Per modificare le costanti, si apre il modulo delle costanti predefinite. Ogni campo di questo modulo è una costante.

Esistono due modi per aggiungere un modulo costante:

• Fare clic con il tasto destro sul ramo Costanti 1C e selezionare la voce di menu Crea modulo costante
• Aggiungi un modulo al ramo Generale/Moduli generali e nella procedura guidata seleziona il tipo di modulo – Modulo costante.

È possibile visualizzare (e selezionare) la forma delle costanti come segue:

• Inserisci le proprietà di configurazione (fai clic con il pulsante destro del mouse sul ramo principale superiore della configurazione, che i programmatori di solito chiamano "Testa") e utilizza la proprietà Forma base delle costanti.

Il modulo delle costanti differisce in quanto l'attributo principale del modulo è del tipo “ConstantsSet”. Ciò consente di scrivere le costanti 1C non individualmente, ma immediatamente come un insieme.

A proposito, un attributo del modulo diventa “primario” se è specificato nella proprietà Data nelle proprietà del modulo.

In un programma in linguaggio 1C, puoi accedere a qualsiasi costante in modo facile e semplice:

Valore = Constants.NecessaryConstant.Get(); //Leggere
Constants.NecessaryConstant.Set(Valore); //scrivi

Parametri della sessione 1C

Quindi il problema è risolto in modo semplice e con grazia: creiamo una costante in cui memorizzeremo il tipo di prodotto predefinito.

Quando si crea un nuovo prodotto, il programma in linguaggio 1C in OnOpenForm() imposterà il valore del campo Tipo Prodotto su quello assegnato nella costante. Ecco!

Adesso il programma funziona, ma non ci fermiamo qui! Certo, siamo bravi programmatori, vogliamo che il programma non solo funzioni, ma funzioni anche velocemente!

Dove sono memorizzate le costanti 1C? Nel database, in una tabella speciale. Ogni volta che l'operatore crea un nuovo prodotto, entrerà nel server e leggerà il valore della costante 1C. E se gli operatori fossero 200? È ottimale?

Cosa fare allora?

E qui ricordiamo i parametri della sessione 1C. Si tratta di valori come costanti che vengono compilati nel momento in cui 1C si avvia in modalità Enterprise e sono immediatamente disponibili sul client. In altre parole, questa è una sorta di cache lato client.

Inoltre, se in una costante possiamo memorizzare un elenco solo in un archivio di valori, possiamo già decomprimerlo in un parametro di sessione 1C, sebbene non sarà dinamico, sarà del tipo FixedArray.

I parametri di sessione 1C si trovano anche nella finestra di configurazione, situata nel ramo Generale/Parametri sessione 1C.

Non è sufficiente aggiungere un parametro di sessione 1C, perché se non viene compilato il programma mostrerà un errore.

La compilazione (impostazione) dei parametri della sessione 1C deve essere eseguita all'avvio di 1C in modalità Enterprise. Fare clic con il tasto destro sul ramo superiore della configurazione (i programmatori lo chiamano "Testa") e selezionare la voce di menu Apri modulo sessione.

Il modulo potrebbe già avere una funzione SettingSessionParameters(). Se non ce n'è ancora uno, seleziona questo evento nell'elenco a discesa corrispondente. Ecco un esempio di impostazione del valore di un parametro di sessione 1C:

SessionParameters.RequiredParameter = Valore; //registra, una volta all'inizio
Valore = SessionParameters.RequiredParameter; //leggendo, rigorosamente dopo aver scritto.

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 radice.

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 Generale è considerata buona pratica non specificare 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!

Parametri di sessione 1C 8.3— una variabile che memorizza il valore del parametro desiderato per la durata della sessione utente. Essenzialmente, si tratta di una sorta di variabile globale legata alla sessione corrente dell'utente.

Utilizzo dei parametri di sessione in 1C

I parametri di sessione vengono impostati solo a livello di programmazione; non esiste un'interfaccia universale per l'impostazione dei parametri di sessione nel sistema. Solitamente vengono impostati all'avvio del sistema, nel “Modulo Sessione”. Se un parametro non è definito, verrà generato un errore quando si accede ad esso.

Esempio di impostazione di un parametro di sessione 1C

Diamo un'occhiata a un tipico esempio di utilizzo dei parametri di sessione: l'impostazione dell'utente corrente. Prenderò un esempio dalla preparazione per.

Nell'albero dei metadati creeremo un nuovo parametro di sessione - CurrentUser, assegnandogli un tipo - DirectoryLink.Individuals:

Ottieni 267 lezioni video su 1C gratuitamente:

Nel modulo di sessione creeremo una procedura in cui verrà determinato il parametro della sessione corrente:

Codice procedura:

Procedura Impostazione dei parametri di sessione (parametri obbligatori) // cerco fisico persona per nome utente TechUser = Directory. Individui. TrovaPerNome(NomeUtente()) ; //se non lo trova, creane uno nuovo Se TechUser. Vuoto() Quindi NuovoUtente = Directory. Individui. CreaArticolo(); Nuovo utente. Nome = NomeUtente() ; Nuovo utente. Scrivere() ; Utente corrente = Nuovo utente. Collegamento; Finisci se ; //assegna al parametro di sessione CurrentUser un collegamento alla directory delle persone Parametri di sessione. UtenteCorrente = UtenteCorrente; Fine della procedura

La differenza tra i concetti di sessione e connessione in 1C:Enterprise 8

Cosa imparerai da questo articolo?

• La risposta corretta a una delle domande più popolari quando si supera 1C: Esperto
• Scopo e caratteristiche delle connessioni e delle sessioni 1C
• Cosa memorizzano i dati della sessione?

Quali sono le differenze tra una sessione e una connessione? Questa domanda apparentemente semplice sull'esame 1C:Expert confonde molti. Nonostante la notevole esperienza di programmazione, non tutti gli specialisti sono in grado di formulare una risposta chiara e corretta.

In questo articolo forniremo un’analisi dettagliata di questo problema. Innanzitutto, esaminiamo separatamente i concetti di sessione e connessione in 1C:Enterprise. Tieni presente che le informazioni sono rilevanti per le versioni della piattaforma 8.2.x e 8.3.x.

Sessione 1C

Facciamo riferimento alla guida dell'amministratore. Definisce il concetto di sessione come segue:

La sessione definisce l'utente attivo dell'infobase e il flusso di controllo di questo utente.

Possiamo dire che il cluster di server non vede gli utenti, ma vede le sessioni e i dati della sessione. In linea di principio, la console di gestione del cluster non ha una sezione “Utenti”; il cluster interpreta le sessioni come utenti.

Ciò conferma la rappresentazione visiva dell'elemento "Sessioni": l'icona viene visualizzata sotto forma di utenti.

È opportuno chiarire che per utente attivo non si intende necessariamente la connessione client, può anche essere:

• un'istanza dell'applicazione client 1C:Enterprise
• istanza dell'applicazione Web in cui viene eseguito il client Web
• istanza di connessione esterna ottenuta dall'oggetto V83.COMConnector
• 1 istanza di lavoro in background
• 1 chiamata al servizio Web

Dati della sessione

Consideriamo il concetto di dati di sessione. La sessione contiene alcune informazioni come:

• nome della base informativa
• numero di sessione
• nome dell'utente autenticato dell'infobase
• Linguaggio dell'interfaccia
• valori dei parametri di sessione
• deposito temporaneo
• statistiche di sessione
• informazioni sui moduli di domanda gestiti
• alcuni dati della piattaforma interna

Queste informazioni sono chiamate dati di sessione. Inoltre, ogni utente attivo ha i propri dati di sessione e sono rilevanti solo per la durata del suo lavoro. Se l'utente lascia il database (termina la sessione), i dati della sua sessione vengono cancellati.

I dati della sessione vengono archiviati su un cluster di server, il gestore del cluster ne è responsabile e a questo serve il servizio dati della sessione. Per velocizzare il tutto, i dati della sessione vengono memorizzati nella cache dei processi di lavoro e dei Thick Client.

Quando il cluster di server viene riavviato, i dati della sessione verranno conservati. Se l'utente attivo non effettua una sola chiamata al cluster entro 20 minuti e la sessione non viene assegnata alla connessione, la sessione viene eliminata insieme ai suoi dati.

Per mantenere la sessione, il thin client e il client Web accedono al cluster almeno una volta ogni 10 minuti.

Connessione 1C

Ora capiamo il concetto di connessione. Diamo nuovamente un'occhiata alla guida dell'amministratore:

Una connessione è un mezzo per accedere alle sessioni a un cluster di server 1C:Enterprise, contiene un set limitato di dati di connessione e non è identificata con l'utente attivo.

In altre parole, una connessione consente a una sessione di accedere al cluster. In questo caso, il numero di connessioni è limitato e non appena una non è più necessaria per la sessione, viene restituita al pool di connessioni.

Se la sessione non accede al cluster, ovvero l'utente è inattivo, la connessione non gli verrà assegnata. Pertanto, una sessione può esistere senza una connessione.

Va notato che i dati della sessione sono archiviati sul server, quindi se la connessione viene interrotta per meno di 20 minuti, ciò non influirà sulla sessione, poiché la connessione è solo un mezzo di accesso.

Ad esempio, se un cavo di rete viene accidentalmente estratto, l'utente non riceverà un messaggio di errore se collega il cavo entro 20 minuti. In questo caso, alla sessione verrà assegnata una nuova connessione e continuerà l'esecuzione. L'utente non si accorgerà nemmeno del problema, tranne forse per un leggero freeze.

Le connessioni vengono utilizzate anche per comunicare tra processi del cluster, ovvero i processi di lavoro (rphost) comunicano con il gestore del cluster (processo rmngr) utilizzando le connessioni anziché le sessioni.

Differenze tra connessioni e sessioni

Per descrivere la differenza principale tra questi concetti, daremo un'analogia.

Diciamo che la sessione è un passeggero e la connessione è un taxi. Quando un passeggero deve tornare a casa (la sessione deve connettersi al server), chiama un taxi (alla sessione viene assegnata una connessione dal pool di connessioni).

Se, arrivato a casa, il passeggero vuole andare di nuovo al lavoro, ma il taxi è già partito (dopo la connessione, la connessione è stata interrotta), il passeggero chiama un nuovo taxi e fa i suoi affari (a lui viene assegnata una nuova connessione la sessione).

Questa analogia mostra chiaramente che una sessione e una connessione non sono la stessa cosa e una sessione può facilmente sopravvivere a un'interruzione della connessione.

Andrej Burmistrov

I parametri considerati in 1C:Enterprise sono presentati come oggetto di metadati. Essenzialmente non è altro che una variabile globale legata alla sessione corrente.

Una variabile globale è uguale a qualsiasi altra variabile, ma la sua particolarità è che è possibile accedervi da qualsiasi punto del programma e, nel caso di un parametro di sessione, funziona solo all'interno della sessione corrente.

Perché il parametro di sessioneè un oggetto di metadati, ha alcune caratteristiche:

• Potrebbe essere di un certo tipo. I tipi consentiti sono determinati dalla piattaforma. L'elenco è piuttosto esteso, ma anche se l'elenco non contiene ciò di cui hai bisogno, puoi sempre serializzare il valore e memorizzarlo in un parametro come una stringa.

• I diritti su di esso, come su qualsiasi altro oggetto di metadati, possono essere limitati dai ruoli (sia di scrittura che di lettura). Tuttavia, esiste una particolarità nell'utilizzo in RLS, ma questa verrà discussa di seguito.
• Ha un limite alla quantità di dati che possono essere inseriti in formato serializzato. Il loro volume non deve superare i 4 GB.

Se il tipo di parametro di sessione è:

• Array fisso
• Collezione fissa
• Struttura fissa

Quindi il valore dell'elemento di raccolta potrebbe essere Non definito.

L'area principale dei parametri è l'uso dei loro valori nelle query RLS (Record Level Access Restriction).

Ad esempio, dobbiamo impostare una condizione per l'utente corrente nella richiesta RLS. Per fare ciò, impostiamo il parametro di sessione "CurrentUser" e impostiamo il valore dal codice della lingua integrato:

SessionParameters.CurrentUser =<значение>

Tabella.Utente = &Utentecorrente

Quando si utilizza il parametro session in questo modo, i permessi di lettura per il parametro non vengono presi in considerazione, ma puoi provare a ottenere il loro valore dal linguaggio integrato:

UtenteCorrente = SessionParameters.UtenteCorrente;

È possibile impostare un parametro di sessione, ovvero il suo valore, solo a livello di programmazione e solo sul server. Per fare ciò, dovrai chiamare una procedura server dal client. Quando si accede ad un parametro di sessione (impostazione, ricezione), se il parametro non è inizializzato, verrà richiamata la procedura Impostazione dei parametri di sessione nel modulo della sessione. Questa procedura ha un parametro Parametri richiesti– un array di identificatori di parametri di sessione impostati. Impostazione dei parametri di sessione chiamato anche quando si stabilisce una connessione con l'infobase prima di chiamare tutti gli altri gestori. In questo caso Parametri richiesti sarà uguale Non definito.

Si consiglia di utilizzare l'inizializzazione ritardata (pigra), ovvero inizializzare i parametri di sessione su richiesta e non all'avvio del sistema, poiché non tutti i parametri di sessione sono richiesti direttamente all'avvio del sistema. L'inizializzazione pigra viene eseguita in questo modo:

Procedura ImpostazioneSessionParameters(SessionParametersNames) Se SessionParametersNames non è definito Allora Se ParametroName = "CurrentUser" Allora SessionParameters.CurrentUser = ; ElseIf NomeParametro = "CurrentOrganization" ThenSessionParameters.CurrentOrganization = ; // eccetera. finisci se; finisci se; EndProcedurevalore>valore>>

Poiché il parametro session è associato alla sessione, non potrai accedere al parametro session da un metodo in esecuzione in background perché sarà una sessione diversa. Questa sfumatura può sorprendere, quindi è meglio prepararsi in anticipo, passando il valore desiderato come parametro del metodo e inizializzandolo dal parametro di sessione all'inizio della procedura.