Az aszinkron programozás korlátozása az Excel-objektummodellre

Összefoglalás

Az Excel-objektummodell (OM) folyamatban lévő aszinkron programozása hibákhoz és helytelen alkalmazásállapothoz vezethet.  Az OM közvetlen aszinkron programozása nem támogatott.

Az Excel-objektummodell nem nyújt automatikus védelmet az egyidejűségi vagy újrabemeneti problémák ellen, ha egy makróban vagy bővítménymegoldásban aszinkron eseményekből hívják meg őket, ezért a hívónak szerializálnia és kezelnie kell ezeket a feltételeket, mielőtt meghívja az OM-t az aszinkron visszahívásokból (például időzítőeseményekből) vagy háttérszálakból. Az optimális biztonság érdekében javasoljuk, hogy az ilyen feladatok várják meg, amíg a főszál tétlen lesz, mielőtt megpróbálják megszakítani a felhasználói tevékenységet egy új automatizálási feladattal. Ezt a makró-/bővítménytípustól és a megoldásban használt programozási nyelvtől függően többféleképpen is megteheti.

További információ

A Microsoft Excel egy programozási objektummodellt (OM) támogat a fejlesztők számára az Excel működésének automatizálására és szabályozására. Az OM-t eredetileg Visual Basic for Applications (VBA) makrókhoz tervezték, de a legtöbb bővítménytípus, például a Component Object Model (COM) bővítmények, a felügyelt (.NET) bővítmények, a Visual Studio Tools for Office (VSTO) dokumentum- és alkalmazásszintű testreszabásai, valamint egyéb folyamaton belüli bővítmények és vezérlők is használják.

Az eredeti kialakításban az OM azon a feltételezésen alapul, hogy az OM meghívása felhasználói művelet alapján történik, például amikor egy felhasználó makrót futtat, egy makróhoz/bővítményhez társított felhasználói felületi elemre kattint, vagy az Excel közvetlenül meghívja egy felhasználó által definiált munkalapfüggvényhez stb., vagy egy külső vezérlő teljes alkalmazásautomatizálása során használja.  Az Excel automatizálására tett kísérletek, miközben a felhasználó használja, komplikációkat okozhatnak, és olyan hibákat vagy állapotproblémákat eredményezhetnek, amelyek alááshatják a programot. Az Excel által a felhasználók által végzett műveletek és függvények sokfélesége miatt, amelyek közül sok egy makró/bővítmény hívásához vagy egy olyan számítási eseményhez vezethet, amely meghívhatja az ilyen bővítményeket, az Excel nem akadályozza meg az OM-hívásokat a felhasználói műveletek (vagy számítások) végrehajtása közben.  Ez negatív hatással lenne a termék azon képességére, hogy a legrugalmasabb módon használjon makrókat/bővítményeket.  Bár az Excel mindent megtesz annak érdekében, hogy védelmet nyújtson a felhasználók és az OM-hívó közötti egyidejű tevékenységekkel szemben, nem tud védekezni az olyan példányok ellen, amelyeket egy makró/bővítmény önmagában vezet be.

Vannak esetek, amikor egy program olyan külső forrásokból szeretne információt beszerezni, amelyek aszinkron módon futnak az Excelben, és az OM használatával próbál frissíteni valamit az Excelben, vagy adatokat szeretne beszerezni az Excelből, hogy eldöntse, mi a teendő az aszinkron eseménysel.   Ha egy program olyan, nem felhasználói felületről indított műveletből próbálja használni az OM-t, amelyet az Excel nem dolgoz fel – ilyen például egy időzítő visszahívása vagy egy háttérszál közvetlen eseménye, vagy az Excel számára ismeretlen külső forrásból küldött vagy közzétett üzenetre válaszul –, akkor előfordulhat, hogy az OM nem megfelelő állapotban van a hívások kezelésére abban az időben. Az OM nem akadályozza meg a hívást, és egyes hívások működésnek tűnhetnek, de ez a művelet kockázatos.  Egyidejűségi hibákat okozhat, vagy újratelepítést okozhat a főszálon, ami hibákhoz, állapotproblémákhoz, könyvsérülésekhez és/vagy alkalmazáskivételekhez (összeomlásokhoz) vezethet a programban.

A makró-/bővítménytervezőnek ügyelnie kell arra, hogy ne használjon ilyen programozási technikákat (időzítők, et.al.), vagy gondoskodnia kell az ilyen kódok megfelelő kezeléséről, hogy ők maguk is megakadályozzák az egyidejűségi és újrabeírási problémákat az Excel OM használata előtt. Az aszinkron programozás használata az OM-hez a probléma elleni védelem nélkül nem támogatott, és az ilyen műveletek által okozott sérülések vagy összeomlások nem minősülnek "hibáknak" az Excelben. Ezek inkább a makró/bővítmény tervezési hibáinak minősülnek, mivel az egyidejűséget és az újrakontrasztot az adott helyzetben vezetik be, és mint ilyen, felelős a kódban az ellenük való védelemért.

Ezzel a helyzettel kapcsolatos figyelmeztetést eredetileg az Excel 97 szoftverfejlesztői készletében (SDK) dokumentálták mind a VBA OM, mind az XLL C-API esetében.  A korlátozás az Excel minden verziójára vonatkozik a programozási felület bevezetése óta.  Ahogy a termék idővel bővült, és egyre több funkciót és képességet adott hozzá, az egyidejű vagy ismétlődő műveletek valószínűsége ugyanabban a relatív számítási feladatban nőtt egy adott idő alatt.  Ez új problémának tűnhet, ha valójában nem. A "korábban működő" kód soha nem volt érvényes, ha ilyen helyzetbe ütközik; inkább csak nem "kevesebb" a múltban, így nem szerzett sok figyelmet korábban. Ennek ellenére ismét kiadjuk ezt a figyelmeztetést, amely emlékezteti a fejlesztőket arra a felelősségre, hogy körültekintően kezeljék az aszinkron programozást.  Ne feltételezze, hogy az Excel OM fogja kezelni.

Azok a fejlesztők, akiknek aszinkron információkat kell gyűjteniük és használniuk, és nem engedhetik meg maguknak más eszközök használatát, továbbra is használhatják őket, feltéve, hogy az OM használata előtt védik a kódjukat az egyidejűségi és újrabeírási problémák kezelésére.  Ezt többféleképpen is megteheti, és a makró-/bővítménytervezéstől, a használt programozási nyelvtől és az általános architektúrától függ, hogy milyen megközelítést alkalmaz. A gyakoribb feladatokhoz, például az időzítő visszahívásaihoz az Application.OnTime függvény használatát javasoljuk a UserForm/WinForm/API időzítő helyett. Az OnTime hívása garantáltan a fő szál tétlenségéből történik, ha az OM készen áll új parancsok fogadására, amelyek nem ütköznek a felhasználó által futtatott feladatokkal. Ha külső aszinkron eseményeken alapuló cellákba szeretne adatokat feltölteni, fontolja meg az Real-Time Data (RTD) API használatát az OM használata helyett.  Az RTD ugyanúgy garantáltan megfelelően frissül anélkül, hogy ezek a problémák zavarják a felhasználók interaktivitását.   A háttérszálakat használó felügyelt kódnak vissza kell delegálnia a fő szálra, mielőtt részt vesz az OM-ben.  Az OM használata előtt fontolja meg a WinForms MethodInvoker objektum használatát, hogy delegált függvényt futtasson a felhasználói felületen. Bár ez nem akadályozza meg az összes olyan feltételt, amely hibákhoz vezethet, a legrosszabb esetekre is kiterjed. A teljes védelem érdekében javasoljuk, hogy egy natív kódösszetevőt javasoljon a várólistára helyezett eseményvisszahívásokhoz, majd növelje a delegált visszahívási függvényt tétlen időkben.  A C/C++ programok regisztrálhatnak az üresjárati feladat feldolgozására, hogy kezeljenek egy privát üzenetsort azokhoz a feladatműveletekhez, amelyeket akkor szeretnének végrehajtani, ha nincs felhasználói tevékenység.

Ne feledje, hogy ez a figyelmeztetés olyan helyzetekre vonatkozik, amikor egy makró-/bővítménykód olyan aszinkron eseményekre válaszol, amelyeket akkor vezet be, ha nem modális állapotban van (például a saját párbeszédpaneljén). Így itt nem jelenik meg az időzítők vagy egyéb események, amelyek akkor fordulnak elő, amikor a makró-/bővítménykód szabályozza a fő szálat.  Csak azokban az esetekben, amikor ilyen visszahívásokat kísérelnek meg lekérni, miután a vezérlő visszakerült az Excelbe.  Emellett nem vonatkozik az Excel által kezelt aszinkron eseményekre, például a Windows rendszereseményekre, az OLE Link-frissítésekre, a DDE-hivatkozásfrissítésekre vagy a RTD-re.