Nedtrappning graciöst i avsaknad av ett gränssnitt

Eftersom en kontroll kanske inte stöder något annat gränssnitt än IUnknownmåste en container försämras på ett korrekt sätt när den påträffar frånvaron av något visst gränssnitt.

Man kan ifrågasätta nyttan av en kontroll med bara IUnknown. Tänk dock på de fördelar som en kontroll får från en containers visuella programmeringsmiljö (till exempel VB) när containern identifierar objektet som en kontroll:

• En knapp för objektet visas i en verktygslåda.
• Man kan skapa ett objekt genom att dra det från verktygslådan till ett formulär.
• Man kan ge objektet ett namn som känns igen i den visuella programmeringsmiljön.
• Samma namn i (3) ovan kan användas omedelbart för att skriva annan kod för kontroller i samma formulär (eller till och med ett annat formulär).
• Containern kan automatiskt tillhandahålla kodinmatningspunkter för alla händelser som är tillgängliga från objektet.
• Containern tillhandahåller ett eget användargränssnitt för egenskapssurfning för alla tillgängliga egenskaper.

När ett objekt inte identifieras som en kontroll förlorar det potentiellt alla dessa mycket kraftfulla och fördelaktiga integreringsfunktioner. I Visual Basic 4.0 är det till exempel mycket svårt att verkligen integrera vissa slumpmässiga objekt som inte är en kontroll i fullständig mening, men som fortfarande kan ha egenskaper och händelser. Eftersom Visual Basic 4:s uppfattning om en kontroll är mycket restriktiv får objektet inte någon av integreringsfunktionerna ovan. Men även en kontroll med IUnknown, där kontrollens livslängd avgör förekomsten av en resurs, bör kunna få de integreringsfunktioner som beskrivs ovan.

Eftersom de aktuella verktygen kräver en stor uppsättning kontrollgränssnitt för att få någon fördel, leder kontrollerna i allmänhet till överimplementering, så att de innehåller mer kod än de verkligen behöver. Styrningar som kan vara 7K kan bli 25K, vilket är ett stort prestandaproblem inom områden som Internet. Detta har också lett till uppfattningen att man bara kan implementera en kontroll med ett verktyg som CDK på grund av komplexiteten i att implementera alla gränssnitt, och detta får konsekvenser när en stor DLL som OC30.DLL krävs för en sådan kontroll, vilket ökar arbetsuppsättningen. Om inte alla gränssnitt krävs, öppnar detta upp många utvecklare för att skriva mycket små och lätta kontroller med rak OLE eller med andra verktyg samt, vilket minimerar kostnaderna för varje kontroll.

Det är därför som den här bilagan identifierar en kontroll som ett objekt med ett CLSID och ett IUnknown--gränssnitt. Även med inget annat än IUnknown bör en container med en programmeringsmiljö kunna tillhandahålla åtminstone funktioner #3 och ) registerpost, den får #1 och #2. Om objektet tillhandahåller IConnectionPointContainer- (och IProvideClassInfo allmänhet) för vissa händelseuppsättningar får det #5, och om det stöder IDispatch- för egenskaper och metoder får det #6 samt bättre kodintegrering i containern.

I korthet bör ett objekt kunna implementera så lite som IDispatch och en händelseuppsättning som exponeras via IConnectionPointContainer för att få alla dessa visuella funktioner ovan.

Med detta i åtanke beskriver följande tabell vad en container kan göra om det inte finns något möjligt gränssnitt. Observera att endast dessa gränssnitt visas som containern kommer att hämta direkt via QueryInterface. Andra gränssnitt, som IOleInPlaceActiveObject, erhålls på annat sätt.

Gränssnitt	Innebörden av gränssnittsfrånvaro
IViewObject2	Kontrollen har inga visuella element som den kommer att rita upp sig själv, så den har inga bestämda gränser att tillhandahålla. Vid körning försöker containern helt enkelt inte att rita något när det här gränssnittet saknas. Under designtiden måste containern åtminstone rita någon form av standardrektangel med ett namn i den för en sådan kontroll, så att en användare i en visuell programmeringsmiljö kan markera objektet och kolla in dess egenskaper, metoder och händelser som finns. Att hantera frånvaron av IViewObject2 är viktigt för bra stöd för visuell programmering.
IOleObject	Kontrollen behöver överhuvudtaget ingen webbplats och deltar inte heller i någon förhandling om layout för inbäddade objekt. All information (till exempel kontrollutbredningar) som en container kan förvänta sig av det här gränssnittet bör fyllas i med standardvärden som tillhandahålls av containern.
IOleInPlaceObject	Kontrollen blir inte aktiv på plats (som en etikett) och försöker därför inte att aktivera på detta sätt. Aktiveringen är eventuellt begränsad till dess egenskapssidor.
IOleControl	Kontrollen har inga mnemonics och ingen användning av omgivande egenskaper och det spelar ingen roll om containern ignorerar händelser. I avsaknad av det här gränssnittet anropar containern bara inte dess metoder.
IDataObject	Kontrollen innehåller inga egenskapsuppsättningar eller visuella återgivningar som kan cachelagras, så containern skulle välja att cachelagras någon standardpresentation i avsaknad av det här gränssnittet (stöd för CF_METAFILEPICT, specifikt) och inaktivera eventuella egenskapsuppsättningsrelaterade funktioner.
IDispatch	Kontrollen har inga anpassade egenskaper eller metoder. Containern behöver inte försöka visa några kontrollegenskaper i det här fallet och bör inte tillåta anpassade metodanrop som containern inte känner igen som tillhörande sina egna utökade kontroller (som kan stödja metoder och egenskaper). Eftersom utökade kontroller vanligtvis delegerar vissa IDispatch- anrop till kontrollen bör en utökad kontroll inte förvänta sig att kontrollen har IDispatch alls.
IConnectionPointContainer	Kontrollen har inga händelser, så containern behöver inte tänka på att hantera några.
IProvideClassInfo IProvideClassInfo2	Kontrollen har antingen inte typinformation eller specifika händelser, eller måste containern få åtkomst till kontrollens typinformation via kontrollens registerposter. Förekomsten av det här gränssnittet är en optimering.
ISpecifyPropertyPages	Kontrollen har inga egenskapssidor, så om containern har något användargränssnitt som anropar dem bör containern inaktivera användargränssnittet.
IPerPropertyBrowsing	Kontrollen har inget visningsnamn, inga förutbestämda strängar och värden och ingen egenskap för sidmappning. Det här gränssnittet används nästan alltid för att generera användargränssnitt för containrar, så sådana gränssnittselement skulle inaktiveras i avsaknad av det här gränssnittet.
IPersist*	Kontrollen har inget beständigt tillstånd att tala om, så containern behöver inte bekymra sig om att spara några kontrollspecifika data. Containern sparar naturligtvis sin egen information om kontrollen i sin egen form eller sitt eget dokument, men själva kontrollen har inget att bidra till den informationen.
IOleCache IOleCache2	Objektet stöder inte cachelagring. En container kan fortfarande ha stöd för cachelagring genom att bara skapa en datacache med hjälp av CreateDataCache.

Relaterade ämnen

Behållare