Code schrijven in Office-oplossingen

Er zijn enkele aspecten van het schrijven van code in Office-projecten die verschillen van andere typen projecten in Visual Studio. Veel van deze verschillen zijn gerelateerd aan de manier waarop de Office-objectmodellen worden blootgesteld aan beheerde code. Andere verschillen zijn gerelateerd aan het ontwerp van Office-projecten.

Van toepassing op: De informatie in dit onderwerp is van toepassing op projecten op documentniveau en VSTO-invoegtoepassingsprojecten. Zie Functies die beschikbaar zijn per Office-toepassing en projecttype.

Beheerde code en Office-programmering

De belangrijkste technologie die het maken van een geïntegreerde Microsoft Office-oplossing mogelijk maakt, is Automation, dat deel uitmaakt van de COM-technologie (Component Object Model). Met Automation kunt u code gebruiken om softwareobjecten te maken en te beheren die beschikbaar worden gemaakt door elk toepassings-, DLL- of ActiveX-besturingselement dat ondersteuning biedt voor de juiste programmatische interfaces.

Begrijpen van primaire interop-assembly's

Microsoft Office-toepassingen maken veel van hun functionaliteit beschikbaar voor Automation. U kunt echter geen beheerde code (zoals Visual Basic of C#) rechtstreeks gebruiken om Office-toepassingen te automatiseren. Als u Office-toepassingen wilt automatiseren met beheerde code, moet u de primaire interopassembly's (PIA's) van Office gebruiken. Met de primaire interoperabiliteitsassembly's kan beheerde code communiceren met het COM-objectmodel van de Office-toepassingen.

Elke Microsoft Office-toepassing heeft een PIA. Wanneer u een Office-project in Visual Studio maakt, wordt automatisch een verwijzing naar de juiste PIA toegevoegd aan het project. Als u de functies van andere Office-toepassingen uit het project wilt automatiseren, moet u handmatig een verwijzing naar de juiste PIA toevoegen. Zie voor meer informatie Hoe: Office-toepassingen richten op via primaire interop-assemblages.

Primaire interoperabiliteitsassembly's gebruiken tijdens de ontwerpfase en runtime

U moet de Office-PIA's hebben geïnstalleerd en geregistreerd in de algemene assemblycache op uw ontwikkelcomputer om de meeste ontwikkelingstaken uit te voeren. Zie Een computer configureren voor het ontwikkelen van Office-oplossingen voor meer informatie.

De Office-PIA's zijn niet vereist op computers van eindgebruikers om Office-oplossingen uit te voeren die gericht zijn op .NET Framework 4 of hoger. Zie Ontwerp en maak Office-oplossingen voor meer informatie.

Typen gebruiken in primaire interoperabiliteitsassembly's

De Office-PI's bevatten een combinatie van typen waarmee het objectmodel van de Office-toepassingen en aanvullende infrastructuurtypen worden weergegeven die niet rechtstreeks in uw code moeten worden gebruikt. Zie Overzicht van klassen en interfaces in de primaire assembly's van Office voor een overzicht van de typen in de Office-PIA's.

Omdat de typen in de Office-PIA's overeenkomen met typen in de COM-objectmodellen, verschilt de manier waarop u deze typen gebruikt vaak van andere beheerde typen. De manier waarop u methoden aanroept met optionele parameters in een primaire assembly van Office, is bijvoorbeeld afhankelijk van de programmeertaal die u in uw project gebruikt. Zie de volgende onderwerpen voor meer informatie:

Programmamodel van Office-projecten

Alle Office-projecten bevatten een of meer gegenereerde klassen die het toegangspunt voor uw code bieden. Deze klassen bieden ook toegang tot het objectmodel van de hosttoepassing en toegang tot functies zoals deelvensters acties en aangepaste taakvensters.

Inzicht in de gegenereerde klassen

In projecten op documentniveau voor Excel en Word lijkt de gegenereerde klasse op een object op het hoogste niveau in het objectmodel van de toepassing. De gegenereerde ThisDocument klasse in een Word-documentproject biedt bijvoorbeeld dezelfde leden als de Document klasse in het Word-objectmodel. Zie Aanpassingen op documentniveau op programmaniveau voor meer informatie over de gegenereerde klassen in projecten op documentniveau.

VSTO-invoegtoepassingsprojecten bieden een gegenereerde klasse met de naam ThisAddIn. Deze klasse lijkt niet op een klasse in het objectmodel van de hosttoepassing. In plaats daarvan vertegenwoordigt deze klasse de VSTO-invoegtoepassing zelf en biedt leden die u kunt gebruiken voor toegang tot het objectmodel van de hosttoepassing en toegang tot andere functies die beschikbaar zijn voor VSTO-invoegtoepassingen. Zie Programma-VSTO-invoegtoepassingen voor meer informatie.

Alle gegenereerde klassen in Office-projecten omvatten Startup en Shutdown gebeurtenis-handlers. Om aan de slag te gaan met het schrijven van code, voegt u doorgaans code toe aan deze gebeurtenis-handlers. Als u uw VSTO-invoegtoepassing wilt initialiseren, kunt u code toevoegen aan de Startup gebeurtenis-handler. Als u resources wilt opschonen die worden gebruikt door uw VSTO-invoegtoepassing, kunt u code toevoegen aan de Shutdown gebeurtenis-handler. Zie Gebeurtenissen in Office-projecten voor meer informatie.

Toegang tot de gegenereerde klassen tijdens runtime

Wanneer een Office-oplossing wordt geladen, wordt met Visual Studio Tools voor Office Runtime elk van de gegenereerde klassen in uw project geïnstitueerd. U kunt deze objecten openen vanuit elke code in uw project met behulp van de Globals klasse. U kunt de Globals klasse bijvoorbeeld gebruiken om code in de ThisAddIn klasse aan te roepen vanuit een gebeurtenishandler van een lintknop in een VSTO-invoegtoepassing.

Zie Globale toegang tot objecten in Office-projecten voor meer informatie.

Overwegingen met betrekking tot namespaces in Office-oplossingen

U kunt de standaardnaamruimte (of hoofdnaamruimte in Visual Basic) van een Office-project niet wijzigen nadat u het project hebt gemaakt. De standaardnaamruimte komt altijd overeen met de projectnaam die u hebt opgegeven bij het maken van het project. Als u de naam van uw project wijzigt, wordt de standaardnaamruimte niet gewijzigd. Zie Application Page, Project Designer (C#) en Application Page, Project Designer (Visual Basic) voor meer informatie over de standaardnaamruimte in projecten.

De naamruimte van hostitemklassen in C#-projecten wijzigen

Hostitemklassen (bijvoorbeeld de ThisAddIn, ThisWorkbookof ThisDocument klassen) hebben hun eigen naamruimten in Visual C# Office-projecten. De naamruimte voor hostitems in uw project komt standaard overeen met de projectnaam die u hebt opgegeven toen u het project maakte.

Als u de naamruimte van de hostitems in een Visual C# Office-project wilt wijzigen, gebruikt u de naamruimte voor de eigenschap Hostitem . Zie Eigenschappen in Office-projecten voor meer informatie.

Ondersteunde programmeertalen in Office-projecten

De Office-projectsjablonen in Visual Studio ondersteunen alleen de programmeertalen Visual Basic en Visual C#. Daarom zijn deze projectsjablonen alleen beschikbaar onder de Visual Basic - en Visual C# -knooppunten van het dialoogvenster Nieuw project in Visual Studio. Zie Voor meer informatie : Office-projecten maken in Visual Studio.

Taalkeuze en Office-programmering

Microsoft Office en Visual Basic for Applications (VBA) zijn ontwikkeld om samen te werken om de werkstroom van toepassingsaanpassing te optimaliseren. Visual Basic heeft enkele van deze ontwikkelingen overgenomen. Visual Basic ondersteunt bijvoorbeeld optionele parameters, wat betekent dat u minder code kunt schrijven wanneer u bepaalde methoden aanroept in de primaire interopassembly's van Microsoft Office dan wanneer u Visual C# gebruikt.

Programma met Visual Basic versus Visual C# in Office-oplossingen

U kunt Office-oplossingen maken met behulp van Visual Basic of Visual C#. Omdat de Microsoft Office-objectmodellen zijn ontworpen om te worden gebruikt met Microsoft Visual Basic for Applications (VBA), kunnen Visual Basic-ontwikkelaars comfortabel werken met de objecten die worden weergegeven door de Microsoft Office-toepassingen. Visual C#-ontwikkelaars kunnen de meeste van dezelfde functies gebruiken als Visual Basic-ontwikkelaars, maar er zijn enkele gevallen waarin ze extra code moeten schrijven om de Office-objectmodellen te kunnen gebruiken. Er zijn ook enkele verschillen tussen basisprogrammeerfuncties in Office-ontwikkeling en beheerde code die is geschreven in Visual Basic en C#.

Belangrijkste verschillen tussen Visual Basic en Visual C#

In de volgende tabel ziet u belangrijke verschillen tussen Visual Basic en Visual C# in Office-ontwikkeling.

Feature	Description	Visual Basic-ondersteuning	Ondersteuning voor Visual C#
Optionele parameters	Veel Microsoft Office-methoden hebben parameters die niet vereist zijn wanneer u de methode aanroept. Als er geen waarde wordt doorgegeven voor de parameter, wordt een standaardwaarde gebruikt.	Visual Basic ondersteunt optionele parameters.	Visual C# ondersteunt in de meeste gevallen optionele parameters. Zie Optionele parameters in Office-oplossingen voor meer informatie.
Parameters doorgeven per verwijzing	Optionele parameters in de meeste primaire interopassembly's van Microsoft Office kunnen worden doorgegeven met een waarde. In sommige primaire interoperabiliteitsassembly's moeten optionele parameters die referentietypen accepteren echter worden doorgegeven via verwijzing. Voor meer informatie over waarde- en verwijzingstypeparameters, zie Argumenten door waarde en door referentie doorgeven (Visual Basic) en Parameters doorgeven (C#-programmeerhandleiding).	Er is geen extra werk nodig om parameters via referentie door te geven. De Visual Basic-compiler geeft de parameters automatisch door via verwijzing wanneer dat nodig is.	In de meeste gevallen geeft de Visual C#-compiler, wanneer dat nodig is, de parameters automatisch door als referentie. Zie Optionele parameters in Office-oplossingen voor meer informatie.
Geparameteriseerde eigenschappen	Sommige eigenschappen accepteren parameters en fungeren als read-only functies.	Visual Basic ondersteunt eigenschappen die parameters accepteren.	Visual C# ondersteunt eigenschappen die parameters accepteren.
Late binding	Late binding omvat het bepalen van de eigenschappen van objecten tijdens de uitvoeringstijd, in plaats van variabelen te converteren naar het objecttype tijdens de ontwerpfase.	Visual Basic voert late binding uit wanneer Option Strict is uitgeschakeld. Wanneer Option Strict is ingeschakeld, moet u objecten expliciet converteren en typen in de System.Reflection naamruimte gebruiken om toegang te krijgen tot leden die te laat zijn gebonden. Zie Late binding in Office-oplossingen voor meer informatie.	Visual C# voert late binding uit in projecten die gericht zijn op .NET Framework 4. Zie Late binding in Office-oplossingen voor meer informatie.

Belangrijkste verschillen tussen office-ontwikkeling en beheerde code

In de volgende tabel ziet u belangrijke verschillen tussen Office-ontwikkeling en beheerde code die is geschreven in Visual Basic of Visual C#.

Feature	Description	Ondersteuning voor Visual Basic en Visual C#
Matrixindexen	De ondermatrix van verzamelingen in Microsoft Office-toepassingen begint met 1. Visual Basic en Visual C# maken gebruik van matrices op basis van 0. Zie de programmeergids Matrices (C#) en Matrices in Visual Basic voor meer informatie.	Als u het eerste item van een verzameling in het objectmodel van een Microsoft Office-toepassing wilt openen, gebruikt u de index 1 in plaats van 0.

Feedback

Is deze pagina nuttig?

Last updated on 2025-12-12