Struttura del modulo

1C: Enterprise 8.2 /
Per gli sviluppatori /
Convenzioni del codice

Sommario

1.1. Nel modulo del programma (moduli generali, moduli di oggetti, moduli di gestione oggetti, moduli di moduli, comandi, ecc.) Nel caso generale le seguenti sezioni possono essere presenti nel seguito sequenza :

Alcune sezioni possono essere presenti solo in moduli di un certo tipo. Ad esempio, i gestori di eventi per gli elementi del modulo possono essere presenti solo nei moduli del modulo e la sezione della descrizione della variabile e la sezione di inizializzazione non possono essere definite in moduli generali non globali, moduli di gestione degli oggetti, set di record, valori costanti e modulo di sessione.

Il requisito di dividere il codice del modulo in sezioni ha lo scopo di aumentare la leggibilità del codice e semplificare l'introduzione di modifiche al codice da parte di autori diversi ( dagli sviluppatori ) come nello sviluppo collettivo e nel perfezionamento delle soluzioni applicative per implementazioni specifiche.

1.2. Sezioni modello (vuoto per copia) per moduli comuni:

////////////////////////////////////////////////// ////////////////////////////// // // // //////////// ////////////////////////////////////////////////// ////////////// //////////////////////////////////// //////////////////////////////////////////// // // INTERFACCIA SOFTWARE // ////////////////////////////////////////////////// //////////////////////////// // PROCEDURE E FUNZIONI DEL SERVIZIO

  • La sezione "Interfaccia del programma" contiene procedure e funzioni di esportazione destinate ad essere utilizzate da altri oggetti di configurazione o altri programmi (ad esempio, tramite una connessione esterna).
  • La sezione "Procedure e funzioni di utilità" contiene le procedure e le funzioni che compongono l'implementazione interna di un modulo comune. Nei casi in cui il modulo comune fa parte di alcuni funzionale sottosistemi che includono diversi oggetti metadati, questa sezione può contenere anche procedure e funzioni di esportazione del servizio destinate solo a essere richiamate da altri oggetti di questo sottosistema.
    Per i moduli comuni in blocco, si consiglia di dividere questa sezione in sottosezioni, in base all'attributo funzionale. Le sottosezioni sono precedute da un commento, che si consiglia di pubblicare in modo simile. Per esempio:

////////////////////////////////////////////////// ////////////////////////////// // Aggiornamento della base di informazioni

1.3. Modello per la progettazione di sezioni per moduli oggetto, gestori, set di record, trattamenti, report, ecc.:

////////////////////////////////////////////////// ////////////////////////////// // INTERFACCIA SOFTWARE ////////////// // ////////////////////////////////////////////////// ////////////// // PROCESSORI DI EVENTI //////////////////////////////// //////////////////////////////////////////////// // // PROCEDURE E FUNZIONI DI SERVIZIO

  • La sezione "Interfaccia del programma" contiene procedure e funzioni di esportazione destinate all'uso in altri moduli di configurazione o altri programmi (ad esempio, tramite una connessione esterna). Non è necessario inserire in questa sezione funzioni e procedure di esportazione che devono essere richiamate esclusivamente dai moduli dell'oggetto stesso, dalle sue forme e dai suoi comandi. Ad esempio, le procedure per popolare la parte della tabella di un documento chiamata dall'elaborazione del riempimento nel modulo oggetto e dal modulo del documento nel gestore dei comandi del modulo non sono l'interfaccia del programma del modulo oggetto, poiché sono chiamati solo nel modulo stesso e dalle forme dello stesso oggetto. Dovrebbero essere posizionati nella sezione "Procedure e funzioni di utilità".
  • La sezione "Gestori di eventi" contiene gestori di eventi per il modulo dell'oggetto ( Prizavisi , PRO , ecc.)
  • La sezione "Procedure e funzioni di utilità" ha lo stesso scopo dei moduli generali.

1.4. Modello di progettazione della sezione per moduli modulo:

////////////////////////////////////////////////// ////////////////////////////// // HANDLER OF EVENTS OF THE FORM ///////////// ////////////////////////////////////////////////// /////////////// // HANDLERS OF EVENTS OF ELEMENTS OF THE SHAPE OF THE FORM ////////////////////////////// ////////////////////////////////////////////////// // // PROCESSORI DI TAVOLI FORME EVENTI //////////////////////////////////////////// ////////////////////////////////////// // PROCESSORI PER LE SQUADRE DEL MODULO /////// ////////////////////////////////////////////////// /////////////////////// // PROCEDURE E FUNZIONI DEL SERVIZIO

  • La sezione "Gestori di eventi del modulo" contiene le procedure del gestore di eventi del modulo: su creazione di un server , apertura , ecc.
  • La sezione "Gestori di elementi del modulo" contiene le procedure per l'elaborazione degli elementi situati nella parte principale del modulo (tutto ciò che non è correlato alle tabelle nel modulo).
  • Nelle sezioni "Gestori di eventi della tabella moduli <nome tabella moduli>" sono presenti procedure per i gestori della tabella moduli e degli elementi della tabella. Per le procedure del gestore, ogni tabella deve avere una propria partizione.
  • La sezione "Gestori di comandi del modulo" contiene le procedure per i gestori di comandi del modulo (i cui nomi sono specificati nella proprietà Action dei comandi del modulo).
  • La sezione "Procedure e funzioni di utilità" ha lo stesso scopo dei moduli generali.

Vedi anche: Regole per la creazione di moduli modulo

2. Requisiti generali per sezioni di moduli software.

2.1. L'intestazione del modulo è un commento all'inizio del modulo. L'intestazione del modulo fornisce una breve descrizione e condizioni dell'applicazione.
Per esempio:

////////////////////////////////////////////////// //////////////////////////// // // Procedure client e funzioni di uso generale: // - per lavorare con liste in moduli; // - per lavorare con il registro; // - per le azioni di elaborazione utente in corso modifica // multilinea testo , ad esempio commenti nei documenti; // - altro. // //////////////////////////////////////////////// ////////////////////////////////

Per i moduli modulo, si consiglia di inserire una descrizione dei parametri del modulo nell'intestazione.

2.2. Sezione di descrizione delle variabili . I nomi delle variabili sono assegnati in base al generale regole per i nomi delle variabili e il loro uso è descritto nell'articolo. Utilizzo delle variabili globali nei moduli software .

Tutte le variabili del modulo devono essere fornite con un commento sufficiente a comprenderne lo scopo. Si consiglia di inserire il commento nella stessa riga in cui viene dichiarata la variabile.
esempio:

Valuta PEM Esportazione contabile; // Valuta in cui viene tenuta la contabilità Perem Address Supports Export; // Indirizzo e-mail a cui vengono inviati i messaggi di errore

2.3. Interfaccia software Le procedure e le funzioni di esportazione che compongono la sua interfaccia di programmazione sono poste immediatamente dopo la descrizione delle variabili. Tali procedure e funzioni sono destinate all'uso da parte di altri oggetti di configurazione o altri programmi (ad esempio, tramite una connessione esterna), pertanto devono trovarsi in un "punto visibile" nel modulo.

Vedi anche: Descrizione di procedure e funzioni.

2.4.1 Gestori di eventi, comandi ed elementi del modulo . Prima delle procedure e delle funzioni di servizio nel modulo modulo, vengono individuati i gestori di eventi del modulo, nonché i gestori di eventi per i comandi e gli elementi del modulo.

Raccomandazione metodica (consigli utili)

Si consiglia di mettere insieme i gestori di un elemento del modulo, aderendo all'ordine dei loro seguenti nel pannello delle proprietà dell'editor del modulo nel configuratore .

2.4.2. Ogni evento deve avere una propria procedura di gestione. Se le stesse azioni devono essere eseguite quando si verificano eventi in diversi elementi del modulo:

  • creare una procedura (funzione) separata che esegua le azioni necessarie

  • per ciascun elemento del modulo, creare un gestore separato con il nome predefinito

  • chiamare la procedura (funzione) richiesta da ciascun gestore.

Ad esempio, sbagliato:

& Procedura OnClient per i parametri di selezione di ExecutingApplication (elemento) = New Compliance (); Selezione delle opzioni Incolla ("Per autore", Per autore); Selezione delle opzioni: Incolla ("Executive", Executive); Imposta selezione elenco (Elenco, Opzioni di selezione); KonetsProtsedury E sulla procedura client per la creazione cambiando (elemento) in esecutivo cambiando (non definito); KonetsProtsedury

correttamente:

& Procedura OnClient per PerformIndicator (Item) SetSelection (); Termina procedura e procedura cliente per autore Modifica (elemento) Installa selezione (); EndProcedures & OnServer Procedure SetSelection () Parametri di selezione = New Compliance (); Selezione delle opzioni Incolla ("Per autore", Per autore); Selezione delle opzioni: Incolla ("Executive", Executive); Imposta selezione elenco (Elenco, Opzioni di selezione); KonetsProtsedury

Questo requisito è dovuto al fatto che la logica delle procedure del gestore eventi non è prevista per l'uso nel codice del modulo, ma viene chiamata direttamente dalla piattaforma. Mescolare questi due scenari in una procedura complica inutilmente la sua logica e riduce la sua robustezza (invece di uno scenario di chiamata previsto - su un evento dalla piattaforma - il codice di procedura deve contare su altre chiamate dirette dal codice).

2.5. I gestori di eventi per i moduli oggetto e il gestore oggetti vengono posizionati dopo l'esportazione, ma prima delle procedure di utilità e delle funzioni del modulo.

Raccomandazione metodica (consigli utili)

Si consiglia di posizionare i gestori, aderendo all'ordine dei seguenti nella descrizione del linguaggio incorporato.

2.6. Le procedure di utilità e le funzioni del modulo che non sono gestori di eventi, ma che costituiscono l'implementazione interna di un modulo, sono collocate nel modulo accanto ai gestori di eventi.

Nei casi in cui un modulo comune fa parte di un sottosistema funzionale che include diversi oggetti metadati, questa sezione può contenere anche procedure e funzioni di esportazione del servizio che devono essere richiamate solo da altri oggetti di questo sottosistema.

Si consiglia di mettere insieme procedure e funzioni correlate tra loro per natura o logica del lavoro. Non è consigliabile raggruppare esplicitamente le procedure e le funzioni del modulo in server, client e funzioni senza contesto, poiché tale ordinamento "tecnologico" complica la comprensione della logica del modulo, distogliendo l'attenzione dello sviluppatore sui dettagli della sua implementazione.

2.7. La sezione di inizializzazione contiene istruzioni che inizializzano le variabili del modulo o dell'oggetto (modulo). Per esempio:

Indirizzo di supporto = "[email protected]"; // Indirizzo per contattare il supporto tecnico Perform Initialization ();

Altri materiali sull'argomento:
aggiorna il database . gestori di eventi . interfaccia software . gestori . procedure . sagoma . testata . fine della procedura . funzioni . interfaccia . descrizione . appunti . da copiare . sezione . scambio . forma . un oggetto . l'elemento . configurazione . configurazione . documento

Materiali dalla sezione: 1C: Enterprise 8.2 / Sviluppatori / Accordi durante la scrittura di codice

Altri materiali sull'argomento:

Descrizione di procedure e funzioni

Funzionalità di ridimensionamento per l'oggetto selezionato

Trasferimento di configurazioni sulla piattaforma 1C: Enterprise 8.2 sulla piattaforma 1C: Enterprise 8.3 senza modalità di compatibilità con la versione 8.2

Nomi di procedure e funzioni

Utilizzo della modalità privilegiata


Troviamo: la struttura del modulo 1c è , procedure e funzioni di servizio , modulo, procedura di chiamata del modulo manager 1c 8 2, come chiamare una procedura da un altro modulo 1c, intestazione del modulo inglese, 1c da un modulo di elaborazione procedura del modulo di chiamata, 1c 8 2 chiamare una procedura dal modulo manager, 1


1C: Enterprise 8