Accedi con Microsoft
Accedi o crea un account.
Salve,
Seleziona un altro account.
Hai più account
Scegli l'account con cui vuoi accedere.

Il contenuto in questo caso può essere applicabile a Northwind 2.0 Developer Edition e Starter Edition. 

VBA (Visual Basic, Applications Edition) è il linguaggio di programmazione usato in tutti i prodotti Office. Vba per la formazione consente di lavorare con tutti i prodotti office (non solo Access).
Quando si cerca la "procedura", cercare esempi specifici di Access e includere Microsoft Access nella ricerca. Spesso le soluzioni per gli altri prodotti Office funzionano, ma non vi è alcuna garanzia. Microsoft Access è un prodotto per adulti; questo significa che ci sono molti esempi là fuori; che è fantastico per te! 

Significa anche che libri più vecchi sulla programmazione di Access sono ancora valide per voi da guardare. Molti dei libri più vecchi sono ancora disponibili nei siti di libri usati a una frazione del loro costo originale. Controlla il sito Web Microsoft per determinare quali versioni di Access sono ancora supportate e vai con quelle.

Fine delle risorse di supporto per Office - Distribuire Office | Microsoft Learn  

Di seguito sono riportati alcuni collegamenti alla documentazione di Access in Microsoft.

I file di Microsoft Access sono file di Office. I file di Office devono trovarsi in un "percorso attendibile" o devono avere il loro "contenuto abilitato". Questi elementi sono considerati "sicuri" perché sono stati creati o provengono da una fonte attendibile. Verificare la presenza di percorsi attendibili ogni volta che si apre un file di Office. Da qui in avanti verrà indicato come Attendibile/Abilitato. NOTA: se una nuova versione dell'applicazione viene rilasciata e aperta da un percorso non attendibile, il processo di abilitazione del contenuto verrà ripetuto.

Altre informazioni sui percorsi attendibili: 

Le macro, le funzioni e le sottocartelle consentono di implementare la logica di business nel database di Access. È importante comprendere l'ambito e la visibilità prima di iniziare.


Gli eventi (ad esempio la selezione di un controllo) nei controlli di una maschera (ad esempio pulsanti, caselle di testo, etichette e così via) attivano altri processi, ad esempio l'aggiunta, l'eliminazione di record o l'apertura di maschere. Questi processi possono essere implementati usando macro o VBA. Northwind Starter Edition usa principalmente macro e alcuni file VBA in cui le macro non sono in grado di eseguire le funzioni necessarie. Northwind Developer Edition usa principalmente VBA. 

Alcuni tipi di controllo hanno procedure guidate predefinite per creare automaticamente una macro. Ad esempio, l'aggiunta di un pulsante di comando a una maschera apre una procedura guidata che offre diverse funzionalità per il pulsante. L'aggiunta di una casella combinata apre una procedura guidata che può essere configurata per trovare un record specifico nella maschera. 

Il riquadro di spostamento è il modo principale per visualizzare e accedere a tutti gli oggetti di database e viene visualizzato sul lato sinistro della finestra di Access per impostazione predefinita. 
Il riquadro di spostamento Northwind è stato personalizzato. È stata creata una categoria personalizzata denominata Northwind Starter 2.0. Questo ci permette di organizzare gli oggetti per area funzionale.

A volte è necessario che una variabile esista dopo che l'oggetto creato esce dall'ambito. Vedere la sezione Ambito e visibilità precedente. Esistono tre modi principali per eseguire questa operazione: Variabili pubbliche, TempVars e Archiviazione dei valori in una tabella locale. Molti sviluppatori usano una combinazione di questi. Ognuno ha i suoi pro e contro.  Altre informazioni su ciascuna di esse qui: 

Variabile pubblica modulo VBA: 

TempVars: 

Archiviazione dei valori nella tabella locale

  • Le variabili pubbliche e le tempvar sono disponibili per la sessione corrente e escono dall'ambito quando l'applicazione viene chiusa. Ma cosa succede se vuoi mantenere variabili specifiche dell'utente in più sessioni? È possibile archiviare questi tipi di valori in una tabella locale. In Northwind 2.0 una di queste variabili viene salvata in una tabella denominata SystemSettings. Il valore nella tabella è ShowWelcome. Questo valore indica ad Access se si vuole visualizzare la schermata iniziale ogni volta che si accede o meno.

Gli sviluppatori spesso devono passare parametri da una maschera a un'altra o da una maschera a un report. Questi parametri trasmettono informazioni importanti, che la funzione chiamata userà per configurarsi. La seconda maschera o il secondo report può ottenere informazioni dalla prima maschera in diversi modi. Ecco un paio di modi: 

  1. La seconda maschera può tornare alla prima maschera per recuperare alcuni valori, probabilmente in un controllo visibile o invisibile.  Ad esempio:
    lngCustomerID = Forms!FirstForm!cboCustomerID 

  2. La prima maschera consente di salvare i valori in variabili globali o in TempVars. Ad esempio:
    g_lngUserID = Me.cboUserID 
    TempVars.Add "UserID", Me.cboUserID 

Il metodo usato spesso in Northwind Developer Edition e nella vita professionale usa l'argomento OpenArgs di DoCmd.OpenForm o OpenReport. Ad esempio:

DoCmd.OpenForm "frmCompanyDetail", OpenArgs:=StringFormat("CompanyID={0} &CompanyTypeID={1}", Me.VendorID, ctVendor)

Qui stiamo combinando due tecniche: (1) l'uso di OpenArgs per passare il VendorID e VendorType e (2) l'uso della funzione StringFormat() per creare, ad esempio, questa stringa: 

CompanyID=5&CompanyTypeID=2 

Questa stringa ha un aspetto molto simile a una stringa di query usata in un browser. Contiene una o più "coppie nome/valore" separate dal carattere e commerciale: 

name1=value1&name2=value2


Il vantaggio di una stringa di questo tipo è che ogni valore ha un nome. Confronta questo con un approccio più semplice in cui si imposta OpenArgs solo su "5,2".  In tal caso, ci vorrebbe del tempo per scoprire cosa significa ogni valore. La denominazione di ogni valore rende la stringa di query "auto-descrittiva", che è una buona procedura di programmazione.

All'estremità ricevente di DoCmd.OpenForm si trova in genere nell'evento orm_Load Form_Open o F e si vuole analizzare la stringa OpenArgs nei relativi componenti.

In Northwind è possibile eseguire questa operazione con la funzione StringToDictionary . Accetta una funzione simile a una querystringa e la analizza nei relativi componenti. Questi componenti vengono quindi archiviati in un oggetto Scripting.Dictionary . Questa operazione richiede l'uso di Strumenti > Riferimenti e l'impostazione di un riferimento a Microsoft Scripting Runtime (scrrun.dll).

Le caratteristiche e i vantaggi dell'oggetto Dictionary includono:  

  • L'ordine degli elementi non è importante

  • Funzioni semplici per aggiungere e rimuovere elementi della raccolta

  • Funzioni di loop over the collection, in modo da poter sapere cosa c'è in esso

  • Funzione Exists che consente di verificare se è disponibile un determinato elemento

L'uso dell'oggetto dizionario viene visualizzato in Northwind. Ad esempio, l'evento Form_Load in frmGenericDialog.

Le macro create con le creazioni guidate Controllo in Access includono raramente la gestione degli errori; Vba created with Control Wizards may be limited to a generic MsgBox Err.Description.

In Northwind 2.0 viene illustrato come migliorarlo quando si usa il codice VBA. Abbiamo implementato il cosiddetto gestore di errori globale. Gli errori che si verificano in una routine chiamano una funzione a livello globale per visualizzare l'errore. Il grande vantaggio in questo caso è che la gestione degli errori è coerente. E se il messaggio deve cambiare (ad esempio, per mostrare anche il numero di errore o per registrare l'errore in un file), deve essere fatto in un'unica posizione. 

clsErrorHandler è il modulo di classe che implementa il codice di gestione degli errori. Un modulo di classe mantiene tutte le funzioni principali e di supporto in un'unica unità, incapsulando così il codice.

La macro AutoExec chiama la funzione Avvio in modStartup. In Starter Edition la funzione crea un'istanza di clsErrorHandler e la salva come variabile globale disponibile per l'uso nell'applicazione. In Dev edition viene usata una classe statica. Vedere i commenti nella parte superiore del modulo di classe.

Infatti, il codice di gestione degli errori nelle procedure è così coerente che è stato possibile crearlo tutto in meno di cinque minuti usando codice VBA specifico che ha fornito a ogni routine il gestore di errori corretto. (Codice non incluso nel modello). Entrambe le edizioni di modelli Northwind 2.0 Starter e Developer sono state inizialmente dotate di questo approccio alla gestione degli errori. 
'

GESTIONE DEGLI ERRORI MIGLIORATA

A partire dalla versione 2.2 di Northwind Developer Edition, il gestore errori è stato migliorato grazie al feedback della community di Access. L'edizione Starter rimane invariata. 

In sostanza, il gestore errori nella versione precedente (2.0 - rilasciato ad aprile 2023) è:

Public Sub HandleError(…)
    MsgBox Err.Description
End Sub


Nella versione 2.2 viene aggiornato a:

Public Sub HandleError (…, Optional ByVal IsEventProcedure As Boolean = False)
    If Not IsEventProcedure Then
        Err.Raise lngError, strErrSource
    End If
    MsgBox Err.Description
End Sub


Per capire perché è stata apportata questa modifica, vediamo prima cosa rende il codice eseguito:

  • La macro AutoExec chiama la routine Startup, che esegue alcune inizializzazioni prima di aprire la prima maschera.

  • L'utente interagisce con l'applicazione, ad esempio quando si apre una maschera o si fa clic su un pulsante, causando l'avvio di routine evento come Form_Load e cmdPrintInvoice_Click.
    '

Oltre alle routine evento, le applicazioni hanno subroutine e funzioni, principalmente in moduli, e tale codice viene chiamato dalle routine evento. Queste procedure sono denominate procedure "standard".

Nella versione 2.0 di Northwind, le procedure standard gestiscono i propri errori con i messaggi, ma in qualche modo non notificano alla routine evento chiamante che si è verificato un errore. Se la routine evento contiene codice successivo che deve essere eseguito indipendentemente dall'errore precedente gestito dalla routine chiamata, questo può risultare negativo. Certo, è possibile sostituire la subroutine con una funzione che restituisce un risultato positivo o negativo e codificare la routine evento di conseguenza, ma questa non è sempre un'opzione.

In Northwind versione 2.2 le procedure standard non gestiscono i messaggi di errore, ma, usando Err.Raise, segnalarli di nuovo alla routine evento chiamante. La routine evento chiamante visualizza quindi l'errore generato e riprende in Exit_Handler. Questo è meglio, perché consente alla procedura di chiamata di concludere con grazia.

Per usare il codice Northwind versione 2.2, le routine evento devono passare a HandleError un terzo argomento che indica che il chiamante è una routine evento. Northwind Dev Edition è stato aggiornato per farlo.

Un modulo del gestore di errori ancora più potente avrebbe il supporto per le procedure di "push e popping" su uno "stack" (matrice). Il primo elemento sarà sempre la routine evento, quindi l'argomento aggiuntivo non è necessario. Questa implementazione va oltre gli obiettivi di Northwind Dev Edition.

La funzione MRU o Usati di recente è un elenco degli ordini e degli ordini di acquisto usati di recente. È consigliabile tornare spesso a questi elementi per inserirli nel prossimo stato. Gli elenchi di mrU sono spesso visualizzati nei prodotti Office come un elenco dei file usati di recente che è consigliabile riaprire.

nell'edizione Northwind Dev, per implementare la caratteristica MRU (che non esiste nell'edizione Starter) è necessario prima di tutto stabilire gli elementi seguenti: 

  1. Tabella in cui memorizzare le informazioni mru.

  2. Codice per aggiornare la tabella quando viene aperto un ordine o un ordine fornitore.

  3. Codice per aggiornare l'elenco a discesa MRU sulla barra multifunzione.

  4. Codice per caricare l'elemento quando viene selezionato un elemento MRU dalla barra multifunzione.

Esaminiamo ognuno di questi aspetti in modo più dettagliato. 


1. Tabella in cui memorizzare le informazioni MRU.

La struttura della tabella MRU vale la pena di rivedere, in particolare i suoi indici. Si noti che esiste un indice duplicato SortIdx per facilitare l'ordinamento rapido degli elementi MRU nell'elenco a discesa della barra multifunzione, nonché un indice univoco per applicare la regola aziendale che per ogni utente un elemento può verificarsi una sola volta. Ad esempio, se si apre due volte lo stesso ordine, non vengono creati due record nella tabella MRU.


La tabella sfrutta il fatto che tutti i campi PK (chiave primaria) correlati a MRU nel database sono Numerazione automatica, quindi il tipo di dati Intero lungo può essere usato per PKValue.

2. Codice per aggiornare la tabella quando viene aperto un ordine o un ordine.

In NW2 abbiamo scelto di aggiungere all'elenco MRU solo quando è stato creato un nuovo record, non quando ne è stato aggiornato di nuovo uno esistente. Potremmo certamente spostare la chiamata AddToMRU da Form_AfterInsert a Form_AfterUpdate per supportarla.

Le routine AddToMRU ed DeleteFromMRU vengono implementate in modGlobal, ovvero un modulo standard le cui routine pubbliche sono visibili da qualsiasi maschera.

AddToMRU (come suggerisce il nome) aggiunge il nuovo elemento alla tabella MRU e, facoltativamente, lo taglia nuovamente, eliminando il record meno recente, se è cresciuto oltre le dimensioni massime (MAX_MRU_COUNT). L'ultimo passaggio è probabilmente il meno noto agli sviluppatori di Access: l'elenco a discesa della barra multifunzione deve essere aggiornato e che viene eseguito chiamando InvalidateControl. Questo è un segnale alla barra multifunzione per eseguire nuovamente il processo di inizializzazione. 

3. Codice per aggiornare l'elenco a discesa MRU sulla barra multifunzione. 

Al momento dell'avvio e dopo la chiamata a InvalidateControl , viene eseguito un set complesso di funzioni per popolare la barra multifunzione.  Queste procedure sono chiamate dal codice XML della barra multifunzione nella tabella uSysRibbons , che in parte dice:

<group id="gCurrentStatus" label="MRU">
    <box id="bxMRU" boxStyle="vertical">
        <dropDown id="ddMRU"
                  getItemCount="ddMRU_GetItemCount"
                  getItemLabel="ddMRU_GetItemLabel"
                  getSelectedItemIndex="ddMRU_GetSelectedItemIndex"
                  getItemID="ddMRU_GetItemID"
                  onAction="ddMRU_OnAction"
                  screentip="Most Recently Used Objects">
        </dropDown>
    </box>
</group>

Queste quattro funzioni di callback popolano l'elenco a discesa. Si noti che questa è molto la stessa idea come descritto qui per le caselle combinate standard.

Se si annulla il commento delle righe Debug.Print in modRibbonCallback e si riavvia l'applicazione, la finestra immediata presenta una sequenza simile alla seguente: 

ddMRU_GetItemCount    ddMRU    6 
ddMRU_GetItemLabel    ddMRU    0      Order 60, Proseware, Inc.
ddMRU_GetItemID       ddMRU    0       2 
ddMRU_GetItemLabel    ddMRU    1      Order 62, Best For You Organics Company
ddMRU_GetItemID       ddMRU    1       4 
ddMRU_GetItemLabel    ddMRU    2      Order 63, Wide World Importers
ddMRU_GetItemID       ddMRU    2       5 
ddMRU_GetItemLabel    ddMRU    3      Order 66, Proseware, Inc.
ddMRU_GetItemID       ddMRU    3       8 
ddMRU_GetItemLabel    ddMRU    4      Order 67, Best For You Organics Company
ddMRU_GetItemID       ddMRU    4       9 
ddMRU_GetItemLabel    ddMRU    5      Order 68, Adatum Corporation
ddMRU_GetItemID       ddMRU    5       10 
ddMRU_GetSelectedItemIndex  ddMRU    0


In Access viene prima chiamata una routine che restituisce il numero di elementi da caricare nell'argomento ByRef di ddMRU_GetItemCount. Questo è anche il momento in cui si apre la query nella tabella MRU e memorizzarla nella cache perché sta per essere utilizzata più volte. 

La barra multifunzione chiama quindi ripetutamente due procedure per ottenere i valori ID ed Etichetta per l'elenco a discesa a due colonne. 

Infine, chiama una procedura per disover quale elemento deve essere selezionato. (Nel nostro caso, è il primo.) 

4. Codice per il caricamento di un elemento quando l'elemento MRU è selezionato dalla barra multifunzione.

Come per qualsiasi altro elemento della barra multifunzione, la proprietà OnAction nel codice XML della barra multifunzione specifica una funzione di callback da usare per eseguire l'azione:

onAction="ddMRU_OnAction"

Questa procedura viene implementata in modRibbonCallback. Usa nuovamente il recordset già aperto per trovare il record con l'elemento selezionato, quindi, a seconda di TableName richiesto, apre la maschera corrispondente, passando il valore PK da caricare.

Serve aiuto?

Vuoi altre opzioni?

Esplorare i vantaggi dell'abbonamento e i corsi di formazione, scoprire come proteggere il dispositivo e molto altro ancora.

Le community aiutano a porre e a rispondere alle domande, a fornire feedback e ad ascoltare gli esperti con approfondite conoscenze.

Queste informazioni sono risultate utili?

Come valuti la qualità della lingua?
Cosa ha influito sulla tua esperienza?
Premendo Inviare, il tuo feedback verrà usato per migliorare i prodotti e i servizi Microsoft. L'amministratore IT potrà raccogliere questi dati. Informativa sulla privacy.

Grazie per il feedback!

×