API programozás. Mik azok az API-k és mire valók?

Az API határozza meg a program (modul, könyvtár) által biztosított funkcionalitást, míg az API lehetővé teszi, hogy elvonatkoztassunk attól, hogy pontosan hogyan valósul meg ez a funkció.

Ha egy programot (modult, könyvtárat) fekete doboznak tekintünk, akkor az API a doboz felhasználója számára elérhető „fogantyúk” halmaza, amelyet forgathat és húzhat.

A szoftverkomponensek API-kon keresztül kölcsönhatásba lépnek egymással. Ebben az esetben a komponensek általában hierarchiát alkotnak - a magas szintű komponensek az alacsony szintű komponensek API-ját használják, ők pedig a még alacsonyabb szintű komponensek API-ját.

Az adatátviteli protokollok erre az elvre épülnek. A szabványos Internet protokoll (OSI hálózati modell) 7 réteget tartalmaz (a bitcsomagok átvitelének fizikai rétegétől az alkalmazási protokollok, például a HTTP és IMAP protokollok rétegéig). Mindegyik réteg az előző adatátviteli réteg funkcióit használja, és viszont biztosítja a szükséges funkcionalitást a következő rétegnek.

Fontos megjegyezni, hogy a protokoll fogalma jelentésében közel áll az API fogalmához. Mindkettő a funkcionalitás absztrakciója, csak az első esetben adatátvitelről, a másodiknál ​​pedig számítógépes alkalmazások építéséről beszélünk.

A függvény- és osztálykönyvtár API leírást tartalmaz aláírásokatÉs függvények szemantikája.

Alkalmazásprogramozási felület (API) szoftver interfész rendszerek közötti interakció, amely lehetővé teszi:

  • Hozzáférés a vállalati üzleti szolgáltatásokhoz
  • Információcsere rendszerek és alkalmazások között
  • Egyszerűsítse a vállalatok, partnerek, fejlesztők és ügyfelek közötti interakciót

Nyílt API stratégia

Az API-stratégia a következőket tartalmazza:

  • Üzleti termékek fejlesztése meglévő API-k alapján
  • Belső szolgáltatások nyújtása fejlesztőknek
  • API bevételszerzési modellek a többcsatornás interakció kiépítéséhez és a nyereség növeléséhez

Az Open API koncepció megvalósítása segíti az üzleti élet átalakulását, integrálását a piaci szereplők rugalmas projektökoszisztémájába, feltételeket teremt az új ötletek folyamatos generálásához és a vállalati adattömbök kezelésénél többletérték létrehozásához.

Az integrációs megoldások piaca az API-k fejlődésével összefüggésben fejlődik – az EDI-től és a SOAP-tól a Web 2.0-ig, amely elindította a nyilvános API-k korszakát. Az ilyen interfészek száma a következő 3 évben több mint 50-szeresére nőhet, és elérheti az 1 milliót. Ez az omnichannelnek köszönhető: az ügyfelekkel való interakció csatornáinak velük együtt kell változniuk. A fogyasztók számának és az adatok mennyiségének folyamatos növekedése az API-gazdaság kialakulásához vezetett, amely segít innovatív üzleti modellek létrehozásában a vállalati eszközök és szolgáltatások nyílt felületeken alapuló használatához.

Funkció aláírása

Funkció aláírása- egy általános funkciódeklaráció része, amely lehetővé teszi a műsorszolgáltatók számára a funkció azonosítását többek között. A különböző programozási nyelveknek eltérő elképzeléseik vannak egy függvény aláírásáról, ami szintén szorosan összefügg a funkciótúlterhelés lehetőségeivel ezekben a nyelvekben.

Néha megkülönböztetnek hívó aláírásÉs végrehajtási aláírás funkciókat. A hívásaláírást általában a függvényhívás szintaktikai struktúrájából állítják össze, figyelembe véve az adott függvény hatókörének aláírását, a függvény nevét, a hívás aktuális argumentumtípusainak sorrendjét és a függvény típusát. eredmény. Az implementációs aláírás általában tartalmaz néhány elemet a függvénydeklaráció szintaktikai struktúrájából: egy függvényhatókör-specifikátort, annak nevét és formális argumentumtípusok sorozatát.

Például a C++ programozási nyelvben egyszerű funkció A fordító egyedileg felismeri a neve és az argumentumtípusok sorozata alapján, amely ezen a nyelven a függvény aláírását jelenti. Ha egy függvény egy bizonyos osztály metódusa, akkor az osztály neve is szerepelni fog az aláírásban.

Azt is meg kell jegyezni, hogy a programozó gyakran több különböző API-val rendelkezik ugyanazon eredmény eléréséhez. Ezenkívül az egyes API-kat általában alacsonyabb absztrakciós API-szoftver-összetevők segítségével valósítják meg.

Például: ha látni szeretné a „Hello, world!” sort a böngészőben. Mindössze annyit kell tennie, hogy hozzon létre egy HTML dokumentumot minimális címmel és egy egyszerű törzsben, amely tartalmazza ezt a sort. Mi történik, ha a böngésző megnyitja ezt a dokumentumot? A böngészőprogram átadja a fájlnevet (vagy egy már megnyitott fájlleírót) a HTML dokumentumokat feldolgozó könyvtárnak, amely viszont az API segítségével operációs rendszer elolvassa ezt a fájlt és megérti a szerkezetét, a szabványos grafikus primitívek könyvtárának API-ján keresztül olyan műveleteket hív meg, mint az „ablak törlése”, „írás a kiválasztott betűtípussal Hello, world!”, ezekkel a műveletekkel a grafikus könyvtárat A primitívek kapcsolatba lépnek az ablak interfész könyvtárával a megfelelő kérésekkel, már ez a könyvtár is kapcsolatba lép az operációs rendszer API-val olyan kérésekkel, mint „tegyük ezt a videokártya pufferébe”.

Sőt, szinte minden szinten valójában több lehetséges alternatív API létezik. Például: a forrásdokumentumot nem HTML-ben írhatnánk, hanem LaTeX-ben, és bármilyen böngészőt használhatnánk a megjelenítéshez. A különböző böngészők általában más-más HTML-könyvtárat használnak, ráadásul az egészet (általánosságban) különböző primitív könyvtárak használatával és különböző operációs rendszereken lehet lefordítani.

A meglévő többszintű API-rendszerek fő kihívásai tehát a következők:

  • Nehézségek a programkód egyik API-rendszerről a másikra történő átvitelében (például az operációs rendszer megváltoztatásakor);
  • A funkcionalitás elvesztése alacsonyabb szintről magasabb szintre váltáskor. Nagyjából elmondható, hogy minden API „réteg” bizonyos szabványos műveletek végrehajtásának megkönnyítésére szolgál. Ugyanakkor nagyon nehézzé, vagy alapvetően lehetetlenné válik néhány más, alacsonyabb szintű API által biztosított művelet végrehajtása.

Alap API-típusok

Belső API-k

  • Az API-hozzáférés csak a belső fejlesztőkre korlátozódik
  • A pályázatok a vállalati alkalmazottaknak szólnak

Üzleti illesztőprogramok:

  • Fejlesztési következetesség
  • Költségcsökkentés
  • Fokozott fejlesztési hatékonyság

Partner API-k

  • Csak API-k állnak rendelkezésre limitált készletüzleti partnerek
  • Az alkalmazások a végfelhasználók és az üzleti felhasználók számára készültek

Üzleti illesztőprogramok:

  • A fejlesztési folyamat automatizálása
  • Partnerkapcsolatok fejlesztése
  • A partnerekkel való interakció folyamatának optimalizálása

Nyilvános API-k

Hozzáférés minden külső fejlesztő számára biztosított. Az alkalmazások a végfelhasználókat célozzák

Üzleti illesztőprogramok:

  • Új szolgáltatások fejlesztése
  • Ökoszisztéma fejlesztés
  • Omnichannel interakció

A leghíresebb API-k

Operációs rendszerek API

GUI API

  • Direct3D (a DirectX része)
  • DirectDraw (a DirectX része)

Windows API - az operációs rendszer funkcióinak halmaza

Az API rövidítés nagyon titokzatosnak, sőt ijesztőnek tűnik sok kezdő programozó számára. Valójában az alkalmazásprogramozási felület (API) csak néhány kész funkciókészlet, amelyet az alkalmazásfejlesztők használhatnak. Általában ez a fogalom egyenértékű azzal, amit korábban gyakrabban szubrutinkönyvtárnak neveztek. Az API azonban általában az ilyen könyvtárak speciális kategóriájára utal.

A végfelhasználó számára szinte minden meglehetősen összetett alkalmazás (MyApplication) fejlesztése során létrejön egy meghatározott belső funkciókészlet, amelyet az adott program megvalósítására használnak, amelyet MyApplication API-nak neveznek. Gyakran azonban kiderül, hogy ezek a funkciók hatékonyan használhatók más alkalmazások létrehozására, beleértve más programozókat is. Ebben az esetben a szerzőknek a termékük reklámozási stratégiája alapján kell eldönteniük a kérdést: megnyitják-e a hozzáférést ehhez a készlethez külső felhasználók számára vagy sem? Ha a válasz igen, akkor a szoftvercsomag leírásában pozitív jellemzőként (de néha plusz pénzért) megjelenik a „A csomag egy nyílt API-függvénykészletet tartalmaz” kifejezés.

Így az API leggyakrabban olyan függvénykészletre utal, amely egy alkalmazás részét képezi, de más programokban is használható. Például az Excel a végfelhasználói felületen kívül rendelkezik egy készlettel is Excel függvények Egy API, amely különösen VB-t használó alkalmazások létrehozásakor használható.

Ennek megfelelően a Windows API egy olyan funkciókészlet, amely magának az operációs rendszernek a részét képezi, és ugyanakkor bármely más alkalmazás számára elérhető, beleértve a VB-vel írottakat is. Ebben a tekintetben a BIOS/DOS rendszermegszakítási készlettel való analógia, amely valójában egy DOS API, teljesen indokolt.

A különbség az, hogy a Windows API funkcióinak köre egyrészt jóval szélesebb a DOS-hoz képest, másrészt nem tartalmazza a számítógépes erőforrások közvetlen kezelésére szolgáló eszközök közül sokat, amelyek korábban a programozók rendelkezésére álltak. OS. Ezen túlmenően a Windows API-hívások szokásos procedurális hívásokkal, a DOS-funkciók hívása pedig egy speciális, Interrupt nevű processzorutasításon keresztül történik.

Miért van szükségünk Win API-ra a VB programozóknak?

Annak ellenére, hogy a VB nagyon sokféle funkcióval rendelkezik, a többé-kevésbé komoly fejlesztések során kiderül, hogy képességeik gyakran nem elegendőek a szükséges problémák megoldásához. Ugyanakkor az újonc programozók gyakran panaszkodnak a VB hiányosságai miatt, és az eszközök cseréjére gondolnak, nem sejtve, hogy számítógépük hatalmas eszközkészlettel rendelkezik, és csak tudniuk kell, hogyan kell használni őket.

A Win API-val való ismerkedés során kiderül, hogy sok beépített VB-függvény nem más, mint a megfelelő rendszereljárások hívása, hanem csak szintaxis formájában valósul meg. ennek a nyelvnek. Ezt figyelembe véve az igény API használat a következő opciók határozzák meg:

  1. API-funkciók, amelyek teljes mértékben beépített VB-függvényként vannak implementálva. Ennek ellenére néha ebben az esetben hasznos az API használatára váltani, mivel ez néha jelentősen javíthatja a teljesítményt (különösen az átadott paraméterek szükségtelen átalakításainak hiánya miatt).
  2. A beépített VB-függvények a megfelelő API-függvénynek csak egy speciális esetét valósítják meg. Ez egy meglehetősen gyakori lehetőség. Például a CreateDirectory API függvény több képességgel rendelkezik, mint a beépített VB MkDir operátor.
  3. Nagyon sok API-függvénynek nincs analógja a VB nyelv jelenlegi verziójában. Például nem törölhet könyvtárat a VB használatával – ehhez a DeleteDirectory funkciót kell használnia.

Azt is hangsúlyozni kell, hogy egyes API-funkciók (részesedésük a Win API-ban nagyon kicsi) számos nyelvi korlát miatt nem hívhatók meg VB-programokból, például a memóriacímekkel való munkaképtelenség miatt. De bizonyos esetekben a nem triviális programozási technikák segíthetnek (különösen ugyanazon címek esetében).

A szerző személyes álláspontja az, hogy a beépített funkciók verzióról verzióra való bővítése helyett a VB-t kellett volna adni. jó leírás a legnépszerűbb API-funkciók. Ugyanakkor azt szeretném tanácsolni a fejlesztőknek, hogy ne várjanak a megjelenésre új verzió fejlett funkciókkal rendelkező eszközöket, és nézze meg közelebbről a meglévő Win API összetételét - valószínűleg a szükséges képességeket már az 1991-ben kiadott VB 1.0 verzióban is megvalósíthatták.

Hogyan lehet megtanulni a Win API-t

Ez nem is olyan egyszerű kérdés, tekintve, hogy a Win32 API funkcióinak számát körülbelül 10 ezerre becsülik (a pontos számot senki sem tudja, még a Microsoft sem).

A VB (4-6 verzió) tartalmaz egy fájlt, amely leírja a Win API-deklarációkat - WIN32API.TXT (a használatáról később bővebben is beszámolunk). De először is, segítségével csak a használt mnemonikus nevek alapján szerezhet információkat egy adott funkció céljáról és paramétereiről, másodszor pedig a fájlban található funkciók listája még korántsem teljes. Egy időben (hét évvel ezelőtt) a VB 3.0-nak voltak speciális súgófájljai, amelyek a Win16 API funkcióit írták le. Azonban már a v.4.0-ban eltűntek ezek a hasznos információk a kényelmes felülettel.

A Win32 API-val kapcsolatos átfogó információk itt találhatók súgórendszer Platform Software Development Kit, amely többek között megtalálható a VB 5.0 és 6.0 Enterprise Edition és az Office 2000 Developer Edition MSDN Library CD-n. A szükséges információk megtalálása és megértése azonban egyáltalán nem egyszerű. Arról nem is beszélve, hogy ott minden leírás a C nyelvvel kapcsolatban van megadva.

A híres amerikai szakértő, Daniel Appleman könyvei általánosan elismertek a világon az API programozás VB környezetben való tanulásában. Dan Appleman sorozata Visual Basic A programozói útmutató a Windows API-hoz (a Win16-hoz, Win32-hez, a VB különböző verzióihoz alkalmazható) 1993 óta a VB-programozók egyik legkelendőbb terméke. Az 1997-ben megjelent Dan Appleman VB 5.0 Programmer’s Guide to the Win32 API című könyvet az USA-ból egy barátja hozta el a szerzőnek, aki egy vidéki kisváros első könyvesboltjában talált rá.

Ez a könyv több mint 1500 oldalas, és lefedi a VB általános API programozási technikáit, valamint több mint 900 funkciót. A mellékelt CD tartalmazza a könyv teljes szövegét és az összeset program példák, és ezen kívül számos további fejezet, amely nem szerepelt a nyomtatott változatban. 1999-ben Dan Appleman kiadott egy új könyvet, a Dan Appleman's Win32 API Puzzle Book and Tutorial for Visual Basic programozókat, amely további 7600 funkcióról tartalmaz információt (bár nem olyan kiterjedt).

Win API és Dynamic Link Library (DLL)

A Win API készlet dinamikus DLL-ek formájában valósul meg. A következő lépésben a DLL-ek VB-környezetben való használatának technológiájáról fogunk beszélni a Win API-ban található könyvtárak példáján keresztül. Ha azonban a DLL-ekről beszélünk, meg kell említeni néhány fontos szempontot.

Ebben az esetben a DLL alatt a bináris dinamikus könyvtárak hagyományos változatát értjük, amelyek közvetlen hozzáférést biztosítanak az alkalmazások számára a szükséges eljárásokhoz - szubrutinokhoz vagy függvényekhez (nagyjából ugyanúgy, mint egy VB projekten belüli eljárások meghívásakor). Az ilyen könyvtárak különböző eszközökkel hozhatók létre: VC++, Delphi, Fortran, kivéve a VB-t (lássuk, mi jelenik meg a 7.0-s verzióban) - ez utóbbi csak ActiveX DLL-eket tud létrehozni, az OLE Automation felületén keresztül érhető el.

A dinamikus könyvtárfájlok általában .DLL kiterjesztéssel rendelkeznek, de ez egyáltalán nem szükséges (Win16 esetén gyakran használták a .EXE kiterjesztést); járművezetők külső eszközök.DRV jelzi.

Amint azt már megjegyeztük, meglehetősen nehéz meghatározni a Windows API-funkciók és az azokat tartalmazó fájlok pontos számát, de ezek mind a rendszerkönyvtárban találhatók. Ebben a tekintetben jobb kiemelni az operációs rendszer kernelében szereplő könyvtárak összetételét és a főbb kiegészítő funkciókkal rendelkező fő könyvtárakat.

És most néhány tipp.

Tipp 1. Győződjön meg arról, hogy DL-hirdetése megfelelően van formázva L-eljárások

A programban a DLL-eljárások hívása pontosan ugyanúgy néz ki, mint a „szokásos” Visual Basic eljárások, például:

Hívja a DllName([argumentumok listája])

A külső DLL függvények (beleértve a Win API-t is) használatához azonban ezeket deklarálni kell a programban a Declare utasítással, amely így néz ki:

A Sub ProcedureName Lib deklarálása _ „LibraryName” _ [([ArgumentList])]

Funkció deklarálása FunctionName _ Lib „LibraryName” _ [([ArgumentList])]

Itt az operátor választható elemei szögletes zárójelben, a változó kifejezések dőlt betűvel vannak feltüntetve, a többi szavak pedig kulcsszavak. A súgórendszer elég jól leírja az operátor szintaxisát, így most csak néhány pontot jegyezünk meg.

hirdetéseket külső funkciók modul Általános nyilatkozatok részében kell elhelyezni. Ha egy űrlapmodulban helyezi el, akkor meg kell adnia a Privát kulcsszót (ez a deklaráció csak ebben a modulban lesz elérhető) - ez korlátozza az összes űrlapmodul eljárást.

A Win32 API készlet csak függvények formájában valósul meg (a Win16 API-nak sok alrutinja volt). Ezek többnyire Long típusú függvények, amelyek legtöbbször a művelet befejezési kódját adják vissza.

A Declare operátor még a DOS idejében jelent meg az MS Basicben, és belső projekteljárások deklarálására is szolgált. A Visual Basicben ez nem szükséges, mivel a belső eljárások deklarációja automatikusan az al- vagy funkciódeklarációjuk. A Basic/DOS-hoz képest az új leírásnak fel kell tüntetnie annak a könyvtárfájlnak a nevét, ahol a szükséges eljárás található. A Wip API könyvtárak a Windows rendszerkönyvtárában találhatók, így elég csak a fájlnevet megadni. Ha egy tetszőleges helyen található DLL-hez fér hozzá, akkor írnia kell teljes útvonal ehhez a fájlhoz.

A Declare utasítás leírása általában elég sok helyet foglal el, és nem fér el egy sorba a kódablakban. Ezért azt javasoljuk, hogy alkalmazzon egy meghatározott sortörési sémát a pályázatok írásakor, például:

Függvény deklarálása GetTempPath _ Lib “kernel32” Alias ​​“GetTempPathA” _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) As Long

Ebben az esetben a leírás összes fő eleme különböző sorokra kerül, így könnyen olvasható.

2. tipp: Legyen különösen óvatos, amikor DLL-funkciókkal dolgozik

A Win API és a különböző DLL-funkciók használata jelentősen bővíti a VB funkcionalitását, és gyakran javítja a program teljesítményét. Ennek ára azonban az alkalmazás megbízhatóságának csökkenésének kockázata, különösen a hibakeresés során.

A VB környezet egyik legfontosabb előnye a programfejlesztési folyamat megbízhatósága: tolmács irányítása alatt működik, programkód elméletileg nem sértheti meg Windows működésés magát a VB-t. Előfordulhat, hogy a programozó nem nagyon vigyáz a paraméterek átadásának helyességére a hívott függvényeknek - hasonló hibákat maga a tolmács könnyen észleli, akár a kódfordítás, akár a végrehajtás során. A legkellemetlenebb esetben a feldolgozási mód egyszerűen megszakad, jelezve, hogy hol és miért történt a hiba.

A Windows API-funkciók vagy más DLL-ek használata közvetlenül megszünteti az adatátvitel és a kódvégrehajtási folyamat VB-környezeten kívüli ellenőrzését. Ezért a külső funkciók elérésében fellépő hiba a VB és az operációs rendszer működésképtelenségéhez vezethet. Ez különösen igaz a programfejlesztés szakaszában, amikor a hibák jelenléte teljesen természetes. Így a rendszer alaprétegének funkcióinak tágabb lehetőségeit kihasználva a programozó felelősséget vállal azok helyes használatáért.

A problémát tovább súlyosbítja az a tény, hogy a különböző programozási nyelvek különböző módokat használnak a paraméterek átadására az eljárások között. (Pontosabban, különböző utak Az átadás az alapértelmezett, mivel sok nyelv több módszert is támogathat.) A Win API-k C/C++ nyelven vannak implementálva, és ennek a rendszernek a paraméterátadási konvencióit használják, amelyek eltérnek a szokásos VB verziótól.

Ezzel kapcsolatban meg kell jegyezni, hogy a VB-be épített API-függvények analógjainak megjelenését éppen az utóbbiak VB szintaxishoz való adaptálása és egy megfelelő adatcsere-vezérlő mechanizmus megvalósítása indokolja. Azt is megjegyezzük, hogy az alkalmazás kísérleti hibakeresésének szakaszában a létrehozás során végrehajtható modul A Native Code (gépi kód) helyett jobb a P-kód fordítási opciót használni. Az első esetben a program egy tolmács irányítása alatt fog futni - a gépi kódhoz képest lassabban, de megbízhatóbb az operációs rendszerre gyakorolt ​​esetleges hibás hatások szempontjából, és kényelmesebb módot biztosít az esetleges hibák azonosítására.

3. tipp: Dan Appleman tíz tippje a robusztus API programozáshoz VB-ben

Az API függvény használata körültekintőbb programozást igényel néhány kevésbé ismert eljáráshívási technikával (a VB-hez képest). A továbbiakban ezekkel a kérdésekkel foglalkozunk. És most bemutatjuk Dan Appleman e témában megfogalmazott tanácsainak összefoglalását (első változatuk még 1993-ban jelent meg) néhány kiegészítésünkkel és megjegyzésünkkel.

1. Emlékezzen ByVal. A legtöbb gyakori hiba Az API és DLL függvények elérésekor elkövetett hibás használat kulcsszó ByVal: az emberek vagy elfelejtik telepíteni, vagy éppen ellenkezőleg, akkor telepítik, amikor nincs rá szükség.

Ezek a példák a ByVal operátor paraméterátadásra gyakorolt ​​hatását mutatják be

Paraméter típusa ByVallal ByVal nélkül
Egész szám Egy 16 bites egész szám kerül a verembe A 16 bites egész szám 32 bites címe a verembe kerül
Hosszú Egy 32 bites egész szám kerül a verembe A 32 bites egész szám 32 bites címe a verembe kerül
Húr A karakterlánc a C-ben használt formátumra konvertálódik (adat és egy lezáró null byte). 32 bites cím új sor a veremre lökve A zsinórhoz tartozó VB fogantyút a veremre tolják. (Az ilyen leírókat maga a Windows API soha nem használja, és csak a kifejezetten VB-hez implementált DLL-ekben ismeri fel őket.)

Itt emlékeztetni kell arra, hogy a paraméterek átadása bármely programozási rendszer, beleértve a VB-t is, két fő módon hajtható végre: hivatkozással (ByRef) vagy értékkel (ByVal). Az első esetben a változó címét adják át (ezt az opciót alapértelmezés szerint használják a VB-ben), a másodikban - az értéke. Az alapvető különbség az, hogy referencia segítségével az átadott paraméter megváltozott értéke visszakerül a hívó programba.

Ennek megértéséhez végezzen kísérletet a következő programokkal:

Dim v As Integer v = 2 MyProc(v) MsgBox hívása “v = “ & v Sub MyProc (v As Integer) v = v + 1 End Sub

Amikor ezt a példát futtatja, egy üzenetet fog kapni, amelynek változó értéke egyenlő 3. A tény az, hogy ebben az esetben a hívó programban fizikailag létrehozott v változó címe átadásra kerül a MyProc szubrutinnak. Most módosítsa az eljárás leírását erre

Sub MyProc (ByVal v As Integer)

Ennek eredményeként a teszt végrehajtásakor v = 2-t kapunk, mivel csak a változó kezdeti értéke kerül át az eljárásba - a rajta végrehajtott műveletek eredménye nem kerül vissza a hívó programba. Az érték szerinti átviteli mód a Call operátor segítségével is módosítható az alábbiak szerint:

Sub MyProc (v As Integer) ... Call MyProc((v)) ‘ (v) - a zárójelek érték szerint jelzik az átviteli módot.

A belső VB eljárások elérésekor azonban tilos a ByVal kulcsszó használata a Call utasításban – helyette zárójeleket használunk. Ennek megvan a magyarázata.

Klasszikus esetben (C, Fortran, Pascal) a ByRef és a ByVal módok közötti különbség attól függ, hogy pontosan mi kerül az adatcsere verembe - a változó címe vagy értéke. A Basic történetileg a ByVal szoftveremuláció egy változatát használja - mindig van egy cím a veremben, de csak akkor, amikor az érték áthalad, ehhez ideiglenes változó jön létre. A két lehetőség (Classic és Basic) megkülönböztetésére a ByVal mód leírásának különböző módjai vannak. Ne feledje, hogy a ByVal mód emulálása VB-ben nagyobb programmegbízhatóságot biztosít: a referenciaforma összekeverésével a programozó csak azt kockáztatja, hogy a változó korrigált értéke kerül visszaadásra (vagy nem kerül vissza) a hívó programba. A „klasszikus” változatban az ilyen tévedés végzetes hibához vezethet egy eljárás végrehajtása során (például amikor a memóriacím helyett például nullával egyenlő változót használunk).

A DLL-függvények a „klasszikus” elvek szerint vannak implementálva, és ezért kötelező leírást igényelnek arról, hogy az egyes argumentumokkal hogyan történik az adatcsere. Ezt a célt szolgálják a Declare leíráson keresztüli függvénydeklarációk (pontosabban az átadott argumentumok listája). A Windows API függvénynek vagy DLL-nek a paraméterek legáltalánosabb módja a ByVal kulcsszó használata. Ezenkívül megadható mind a Declare operátorban, mind közvetlenül a függvény meghívásakor.

A helytelen paraméterátadás következményei könnyen megjósolhatók. Ha nyilvánvalóan érvénytelen címet kap, GPF (General Protection Fault) üzenetet fog kapni. Ha a függvény egy érvényes címnek megfelelő értéket kap, akkor az API-függvény idegen területre lép (például a Windows kernelbe) az ebből következő katasztrofális következményekkel.

2. Ellenőrizze az átadott paraméterek típusát. Az átadott paraméterek helyes száma és típusa egyaránt fontos. Szükséges, hogy a Declare-ban deklarált argumentumok egyezzenek az API függvényben várt paraméterekkel. A paraméterátadásban előforduló hiba leggyakoribb esete a NULL és a nulla hosszúságú karakterlánc közötti különbség – ne feledje, hogy ezek nem ugyanazok.

3. Ellenőrizze a visszaküldés típusát.

A VB meglehetősen toleráns a függvényvisszaadási típusú eltérésekkel szemben, mivel a numerikus értékek általában regisztereken keresztül, nem pedig veremen keresztül kerülnek visszaadásra. A következő szabályok segítenek meghatározni az API függvény által visszaadott helyes értéket:

  • Azokat a DLL-függvényeket, amelyek nem adnak vissza értéket (a 'C'-ben a void-hoz analóg) VB Sub-ként kell deklarálni.
  • Egy egész értéket (Integer vagy Long) visszaadó API függvény definiálható alként vagy függvényként, amely a megfelelő típusú értéket adja vissza.
  • Egyik API-függvény sem ad vissza lebegőpontos számokat, de egyes DLL-ek visszaadhatják az ilyen típusú adatokat.

4. Nagy körültekintéssel használja az „As Any” konstrukciót. Számos Windows API-funkció képes paraméterek elfogadására különféle típusokés használja az As Any konstrukciót (a típusértelmezés a többi átadott paraméter értékétől függően történik).

Ebben az esetben jó megoldás lehet, ha egy függvény több álnevét (Alias) használjuk úgy, hogy két vagy több deklarációt hozunk létre ugyanahhoz a függvényhez, és mindegyik deklaráció egy adott típusú paramétert ad meg.

5. Ne felejtse el inicializálni a karakterláncokat. A Win API-ban számos olyan függvény található, amely az adatokat paraméterként átadott karakterlánc-pufferekbe való betöltésével ad vissza információkat. A programodban látszólag mindent megtehetsz helyesen: ne feledkezz meg a ByVal-ról, helyesen adj át paramétereket a függvénynek. A Windows azonban nem tudja ellenőrizni, hogy mekkora a sorhoz lefoglalt memória mérete. A sor méretének elég nagynak kell lennie ahhoz, hogy minden benne elhelyezhető adat elférjen benne. A szükséges méretű puffer lefoglalásáért a VB programozó felelős.

Meg kell jegyezni, hogy a 32 bites Windowsban karakterláncok használatakor a konverzió Unicode-ról (kétbájtos kódolás) ANSI-ra (egybájtos kódolás) és vissza történik, figyelembe véve a nemzeti rendszerbeállításokat. Ezért a pufferek lefoglalásához néha kényelmesebb bájttömböket használni a karakterlánc-változók helyett. (Erről lentebb bővebben.)

Leggyakrabban a Win API függvények lehetővé teszik a definiálást maximális méret Blokk. Különösen néha ehhez egy másik API-függvény meghívására van szükség, amely „megmondja” a blokk méretét. Például a GetWindowTextLength lehetővé teszi a GetWindowText függvény által visszaadott ablakcím megtartásához szükséges sor hosszának meghatározását. Ebben az esetben a Windows biztosítja, hogy ne ess túlzásokba.

6. Ügyeljen arra, hogy az Explicit opciót használja.

7. Gondosan ellenőrizze a paraméterértékeket és a visszatérési értékeket. VB-nek van jó lehetőségeket a típusellenőrzésről. Ez azt jelenti, hogy amikor érvénytelen paramétert próbál átadni egy VB függvénynek, a legrosszabb, ami történhet, az, hogy hibaüzenetet kap a VB-től. De ezt a mechanizmust sajnos nem működik hozzáféréskor Windows funkciók API.

A Windows 9x javított paraméter-ellenőrzést kínál a legtöbb API-funkcióhoz. Ezért a hiba jelenléte az adatokban általában nem okoz végzetes hibát, de annak megállapítása, hogy mi okozta, nem is olyan egyszerű.

Az alábbiakban azt javasoljuk, hogy használjon többféle módszert az ilyen típusú hibák elhárítására:

  • Használja a lépésenkénti hibakeresési módot vagy a Debug.Print parancsot minden gyanús API függvényhívás ellenőrzéséhez. Ellenőrizze a hívások eredményét, hogy megbizonyosodjon arról, hogy minden normális, és a funkció megfelelően befejeződött;
  • használjon Windows hibakeresőt, például a CodeView-t és a Windows hibakereső verzióját (a Windows SDK-ban érhető el). Ezek az eszközök képesek észlelni a paraméterhibákat, és legalább meghatározni, hogy melyik API-függvény okozza a hibát;
  • Használjon további, harmadik féltől származó eszközöket a paramétertípusok és értékeik érvényességének ellenőrzéséhez. Az ilyen eszközök nem csak a paraméterhibákat találják meg, de még a VB kód azon sorára is rámutatnak, ahol a hiba történt.

Ezenkívül ellenőrizni kell az API függvény végrehajtásának eredményét.

8. Ne feledje, hogy az egész számok VB-ben és Windowsban nem ugyanazok. Először is érdemes szem előtt tartani, hogy az „Integer” kifejezés VB-ben 16 bites számot jelent, míg a Win 32 dokumentációjában 32 bites számot. Másodszor, az egész számok (Integer és Long) a VB-ben előjeles mennyiségek (vagyis egy számjegyet használnak előjelként, a többit a szám mantisszájaként), a Windowsban csak nem negatív számokat használnak. Ezt a körülményt szem előtt kell tartani, amikor az átadott paramétert a segítségével alakítja ki aritmetikai műveletek(például számítsa ki a címet valamilyen bázis és eltolás összegzésével). A szabványos VB aritmetikai függvények erre nem alkalmasak. Külön megbeszéljük, hogy mit kell tenni ebben az esetben.

9. Ügyeljen a függvénynevekre. A Win16-tal ellentétben az összes Win32 API-függvény neve érzékeny a kis- és nagybetűk pontos használatára (Win16-ban ez nem volt így). Ha valahol kisbetűt használ a nagybetű helyett, vagy fordítva, akkor szükséges funkciót nem találják meg. Szintén kövesse helyes használat A vagy W utótag a karakterlánc-paramétereket használó függvényekben. (Erről bővebben lásd alább.)

10. Mentse gyakran munkáját. A DLL-ek és a Win API-k helytelen használatával kapcsolatos hibák a VB-környezet, és esetleg az egész operációs rendszer vészhelyzeti leállításához vezethetnek. Győződjön meg arról, hogy a megírt kódot elmenti a tesztfutás előtt. A legegyszerűbb, ha a projekt VB környezetben történő elindítása előtt beállítjuk a projektmodulok automatikus rögzítésének módját.

Az előző tanács elolvasása után azt gondolhatja, hogy a Win API-funkciók használata kockázatos. Ez bizonyos mértékig igaz, de csak a VB által biztosított biztonságos programozáshoz képest. Ám ügyes használattal és a lehetséges buktatók ismeretével ez a kockázat minimális. Ezenkívül gyakran egyszerűen lehetetlen teljesen elhagyni a Win API használatát - továbbra is szükség lesz rájuk bármilyen komoly fejlesztéshez.

Ezenkívül korábban említettük a DLL-ek széles osztályának buktatóit. A Win API esetében minden sokkal egyszerűbb, hiszen a funkciók elérési formája egyértelműen egységes. A következő főbb pontokat kell szem előtt tartani:

  1. A Win32 API függvényei már csak ilyenek: függvények, azaz Function típusú eljárások (a Win16 API-ban sok alrutin volt). Ezek mind Long típusú függvények, így leírásukat a következő formában írjuk: Függvénynév deklarálása ... As Long ‘függvénytípus _ kifejezetten definiálva van

    Declare Function name& ‘ A _ függvénytípust az utótag határozza meg

    Az API függvény hívása így néz ki:

Eredmény& = ApiName& ([ ArgumentList]
  1. Leggyakrabban egy függvény visszatérési értéke a művelet befejezési kódja. Ráadásul a nullától eltérő érték ebben az esetben a normál befejezést, a nulla pedig hibát jelent. Általában (de nem mindig) tisztázni lehet a hiba természetét a GetLastError függvény meghívásával. A függvény leírása így néz ki: A GetLastError& Lib „kernel32” függvény deklarálása ()

    FIGYELEM! Ha VB-ben dolgozik, jobb az Err objektum LastDLLError tulajdonságát használni a minősített hibakód értékének lekéréséhez, mivel a VB néha alaphelyzetbe állítja a GetLastError függvényt az API meghívása és a program végrehajtásának folytatása között.

    A GelLastError által visszaadott kódot az API32.TXT fájlba írt konstansok segítségével értelmezheti, amelyek nevei ERROR_ utótaggal kezdődnek.

    A legtöbb tipikus hibák a következő kódokkal rendelkezik:

    • ERROR_INVALID_HANDLE = 6& - érvénytelen leíró
    • ERROR_CALL_NOT_IMPLEMENTED = 120& - olyan függvény meghívása a Windows 9x rendszerben, amely csak Windows NT esetén érhető el
    • ERROR_INVALID_PARAMETER = 87& - hibás paraméterérték

    Sok függvény azonban visszaadja néhány kért paraméter értékét (például az OpenFile a fájlkezelő értékét adja vissza). Ilyen esetekben a hibát valamilyen más speciális Return& érték határozza meg, leggyakrabban 0 vagy –1.

  2. A Win32 API-k szigorúan rögzített módokat használnak a legegyszerűbb adattípusok átvitelére. a) ByVal...As Long

    Az argumentumátadás legalább 80%-a hosszú változók használatával történik. Vegye figyelembe, hogy az érv Mindig mellé a ByVal kulcsszó, és ez többek között azt jelenti, hogy egyirányú adatátvitel történik - a VB programtól az API funkcióig.

    B) ByVal...As String

    Ez a fajta adatátvitel is gyakran előfordul, és az érveléssel is Mindig ByVal vonatkozik. API függvény meghívásakor a string címe beíródik a verembe, így ebben az esetben kétirányú adatcsere lehetséges. A húrokkal végzett munka során számos veszélyre figyelni kell.

    Az első, hogy egy karakterlánc memóriafoglalása a hívó programban történik, tehát ha az API függvény kitölti a karakterláncokat, akkor a hívás előtt létre kell hozni egy megfelelő méretű karakterláncot. Például a GetWindowsDirectory függvény visszaadja a Windows könyvtár elérési útját, amely definíció szerint nem lehet hosszabb 144 karakternél. Ennek megfelelően a függvény meghívásának valahogy így kell kinéznie:

    WinPath$ = Space$(144) ' lefoglal egy _ 144 karakteres karakterláncot Eredmény& = GetWindowsDirectory& (WinTath$, 144) _ ' töltse ki a puffert ' Eredmény& - a karakterek tényleges száma a _ könyvtárnévben WinPath$ = Left$(WinPath , Eredmény&)

    A második probléma az, hogy API függvény hívásakor a forrás karakterlánc valamilyen belső reprezentációra konvertálódik, a függvényből való kilépéskor pedig fordítva. Ha a Win16 napjaiban ez a művelet csak egy nulla bájt sor végére való hozzáadásából állt, akkor a Win32 megjelenésével ez hozzáadódott a kétbájtos Unicode kódolás ANSI-vé történő átalakításához és fordítva. (Ezt részletesen tárgyaltuk a „String változókkal való munkavégzés jellemzői VB-ben”, ComputerPress 10’99 és 01’2000 cikkben). Egyelőre jegyezzük meg, hogy a ByVal ... String konstrukcióként csak karakteradatokkal cserélhetsz karakterláncokat.

    B) ...mint bármelyik

    Ez azt jelenti, hogy valamilyen memóriapuffer cím kerül a verembe, amelynek tartalmát például az API függvény értelmezi, a többi argumentum értékétől függően. Az As Any azonban csak a Declare utasításban használható – egy adott függvény meghívásakor egy adott változót kell argumentumként definiálni.

    D) ... UserDefinedType-ként

    Ezt a kialakítást gyakran használják akkor is, ha valamilyen struktúra használatával adatcserére van szükség (általában mindkét irányban). Valójában ez a konstrukció egyfajta konkrét megvalósítása az As Any átviteli űrlapnak, csak arról van szó, hogy ebben az esetben a funkció fix struktúrára van konfigurálva.

    Az adatstruktúra formáját az adott API függvény határozza meg, ennek helyes leírása és lefoglalása a hívó programban a programozó felelőssége. Ez a design Mindig használt nélkül szavak ByVal, azaz ebben az esetben hivatkozással történő átvitel történik - a változó címét a verembe írják.

Példa egy API függvény meghívására

Illusztráljuk a fentieket a kettő használatának példáján hasznos funkciókat fájlokkal való munkavégzés - lopen és lread, amelyek leírása a következő:

Az lopen Lib függvény deklarálása „kernel32” _ Alias ​​„_lopen” (_ ByVal lpFileName As String, _ ByVal wReadWrite As Long) Funkció lread Lib „kernel32” deklarálása _ Alias ​​„_lread” (_ ByVal hFile As Long lpBuffer mint bármely, _ ByVal wBytes As Long) Amíg

A VB-ben analógjaik - jelen esetben pontosak - az Open és Get operátorok (bináris módhoz). Azonnal figyeljünk az Alias ​​kulcsszó használatára a függvény deklarációjában - pontosan ez az eset, amikor nem lehet nélküle. A tényleges függvénynevek a könyvtárban aláhúzással kezdődnek (tipikus C nyelvi stílus), ami nem megengedett a VB-ben.

A fájl megnyitási művelete így nézhet ki:

Const INVALID_HANDLE_VALUE = -1 ' helytelen _ leíró érték lpFileName$ = "D:\calc.bas" ' fájlnév wReadWrite& = 2 ' olvasási-írási mód hFile& = lopen(lpFájlnév$, wReadWrite&) _ ' = ha megadja a fájlleírást INVALID_HANDLE_VALUE Ezután _ ' hiba a fájl megnyitásakor ' adja meg a hibakódot CodeError& = Err.LastDllError 'CodeError& = GetLastError _ ' ez a konstrukció nem működik Vége, ha

Itt két pontra kell figyelni:

  • a függvény értékeként a fájlleíró értékét kapjuk. A hiba –1 értéknek felel meg;
  • Pontosan ebben az esetben nem működik a GetLastError függvény meghívása - a finomított hibaérték megszerzéséhez az Err objektumhoz fordultunk (fentebb egy ilyen helyzet lehetőségéről beszéltünk).

A fájl tartalma ezután olvasható, de ez feltételezi, hogy a programozónak valamennyire ismernie kell a fájl szerkezetét (ahogyan az tetszőleges bináris fájlokkal való munka során is történik). Ebben az esetben az lread függvény meghívása így nézhet ki:

Dim MyVar As Single wBytes = lread (hFile&, MyVar, Len(MyVar) ' valós szám beolvasása, 4 bájt ' wBytes a ténylegesen beolvasott adatok száma, ' -1 hiba... Írja be: MyStruct x As Single i As Integer End Type Dim MyVar As MyStruct wBytes = lread (hFile&, MyVar, Len(MyVar)) ' olvasott adatstruktúra, 6 bájt

Kérjük, vegye figyelembe még egyszer: a függvény második argumentuma hivatkozással, a többi értékkel kerül átadásra.

Dim MyVar As String MyVar = Space$(10) ‘változó lefoglalása 10 karakterre wBytes = lread (hFile&, ByVal MyVar, Len(MyVar)) ‘ karakterlánc olvasása, 10 karakter

Itt látható egy fontos különbség az előző példához képest - a karakterlánc változóhoz szükségszerűen a ByVal kulcsszó is társul.

Egy tömbben lévő fájl tartalmának beolvasása (az egyszerűség kedvéért egy egydimenziós bájttömböt használunk) a következőképpen történik:

Dim MyArray(1-től 10-ig) As Byte wBytes = lread (hFile&, MyArray(1), _ Len(MyArray(1))* 10) ‘ 10 tömbelem beolvasása

A tömb első elemének argumentumként történő megadásával a tömb számára fenntartott memóriaterület kezdetének címét adjuk át. Nyilvánvalóan a tömb bármely töredékét kitöltheti a következő módon:

WBytes = lread (hFile&, MyArray(4), _ Len(MyArray(1))* 5) ‘ tömbelemek olvasása 4-től 8-ig

5. tipp: Használja a Gears aliasátés paraméterek Mint bármelyik

Itt az előző példa alapján feltárjuk Dan Appleman negyedik tippjének lényegét.

Amikor az lread függvénnyel dolgozik, ne feledje, hogy amikor egy karakterlánc-változó használatával éri el, akkor a ByVal kulcsszót kell használnia (ellenkező esetben illegális műveletről kap üzeneteket). Saját védelme érdekében készíthet további speciális leírást ugyanannak a függvénynek, hogy csak karakterlánc-változókkal működjön:

Funkció deklarálása: lreadString Lib „kernel32” _ Alias> „_lread” (_ ByVal hFile As Long, ByVal lpBuffer As String, _ ByVal wBytes As Long) As Long

Amikor ezzel a leírással dolgozik, már nem kell megadnia ByVal-t, amikor kapcsolatba lép:

WBytes = lreadString(hFile&, MyVarString, _ Len(MyVarString)) ‘

Úgy tűnik, hogy a Declare operátor szintaxisa lehetővé teszi, hogy hasonló speciális leírást készítsen egy tömbhöz:

Az lreadString Lib „kernel32” alias „_lread” függvény deklarálása (_ ByVal hFile As Long, lpBuffer() As Byte, _ ByVal wBytes As Long) As Long

A fellebbezés azonban

WBytes = lreadArray(hFile&, MyArray(), 10)

elkerülhetetlenül végzetes programhibához vezet.

Ez annak a beszélgetésnek a folytatása, amely a karakterlánc-változók feldolgozásának sajátosságairól szól a Visual Basic-ben: a VB kétbájtos Unicode kódolást, a Win API egybájtos ANSI-t használ (és a C-ben elfogadott formátummal - nulla bájttal a végén) . Ennek megfelelően a karakterlánc-változók argumentumként történő használatakor a Unicode-ról ANSI-re történő átalakítás mindig automatikusan végrehajtódik API-függvény (pontosabban DLL-függvény) meghívásakor, ill. inverz konverzió visszatéréskor.

A levonás ebből egyszerű: A karakterlánc-változók használhatók karakteres adatok cseréjére, de nem használhatók tetszőleges bináris információk cseréjére (mint az a VB 16 bites verzióinál történt). Ez utóbbi esetben célszerű egy egydimenziós bájttömböt használni.

Mint tudják, a String típus használható egyéni struktúra leírására. Ezzel kapcsolatban emlékeznie kell a következőkre:

  • Szigorúan tilos a következő konstrukció használata a Win API eléréséhez: Írja be: MyStruct x As Single s As String ‘változó hosszúságú karakterlánc végtípus

    Változó hosszúságú karakterlánc esetén a struktúra részeként egy karakterlánc-leírót adunk át, aminek minden következménye programvégrehajtási hiba formájában jelentkezik.

  • Rögzített hosszúságú karakterláncot használhat szerkezeti elemként: Írja be: MyStruct x As Single s As String*8 ‘ fix hosszúságú karakterlánc End Type

Ebben az esetben a megfelelő kódolási konverziót hajtják végre.

És egy utolsó megjegyzés: semmilyen körülmények között ne használjon karakterlánc-változók tömbjét (fix és változó hosszúságúak egyaránt), amikor API-függvényt érünk el. Ellenkező esetben az „illegális művelet” megjelenése garantált.

Valószínűleg olyan helyzetbe kerül, amikor saját DLL-függvényeket kell írnia. Ennek szükségessége elkerülhetetlenül felmerül, ha vegyes programozási technológiát használ - két vagy több programozási nyelv használatával egy alkalmazás megvalósításához.

Ezzel kapcsolatban megjegyezzük, hogy a vegyes programozás meglehetősen gyakori egy meglehetősen összetett alkalmazás megvalósításához. Valóban minden nyelvnek (pontosabban egy nyelven alapuló programozási rendszernek) megvannak a maga erősségei és gyenge oldalai, ezért érdemes a megoldáshoz különböző eszközöket kihasználni különböző feladatokat. Például VB - felhasználói felület létrehozásához, C - rendszererőforrásokhoz való hatékony hozzáféréshez, Fortran - numerikus algoritmusok megvalósításához.

A szerző véleménye a következő: minden komoly programozáshoz legalább két eszközben jártasnak kell lennie a fejlesztőtől. Természetesen a világos munkamegosztás modern körülményei között még két rendszerben is nagyon nehéz kiváló szakértőnek lenni, ezért logikusabb a „fő- és segédnyelvek” séma. Itt az az elképzelés, hogy a „kiegészítő” nyelv felületes ismerete (meglehetősen egyszerű eljárások megírása) nagyban javíthatja a „fő” nyelv használatának hatékonyságát. Vegyük észre, hogy a VB ismerete, legalább segédként, ma már szinte kötelező követelmény egy profi programozó számára. Egyébként a DOS korában az Assembler alapjainak ismerete rendkívül kívánatos volt minden programozó számára, beleértve a Basic-et is.

Így vagy úgy, még csoportmunkában is, amikor minden programozó a saját konkrét feladatával foglalkozik, a projekt minden résztvevőjének fogalma kell legyen a különböző nyelveken elérhető eljárási felület jellemzőiről. És tudd, hogy sok programozási rendszer (beleértve a VB-t is) az alapértelmezett interfészen kívül más, fejlett hozzáférési módszereket is lehetővé tesz, amelyek lehetővé teszik az interfész egy másik nyelvhez való igazítását.

Az eljárásközi interfész tanulmányozásakor ügyeljen a következő lehetséges buktatókra:

  • A különböző nyelvek eltérő konvenciót alkalmazhatnak az azonosítók írására. Például gyakori az aláhúzás használata az eljárásnév elején, ami nem megengedett a VB-ben. Ez a probléma könnyen megoldható az Alias ​​kulcsszó használatával a Declare utasításban (lásd a 2.3 példa tippet).
  • Az átadott argumentumok verembe írásának eltérő sorrendje használható. Például a DOS idejében (őszintén bevallom, nem tudom, hogy néz ki most Windows környezet), C argumentumokat írt a lista végétől, más nyelvek (Fortran, Pascal, Basic) - az elejétől.
  • Alapértelmezés szerint a paraméterek átadásának különböző elvei vannak használatban - referencia vagy érték alapján.
  • Különféle elvek a karakterlánc-változók tárolására. Például C-ben (valamint Fortranban és Pascalban) egy karakterlánc hosszát a végén lévő null byte határozza meg, de a Basic-ben a hosszt kifejezetten a karakterláncleíróba írják. Természetesen szem előtt kell tartani a felhasználás lehetőségét különböző kódolások karakterek.
  • Átadáskor többdimenziós tömbök Nem szabad megfeledkezni arról, hogy a többdimenziós struktúrák egydimenzióssá alakítására különféle lehetőségek állnak rendelkezésre (az első indextől vagy az utolsótól kezdve, a kétdimenziós tömbök vonatkozásában - „sorok szerint” vagy „oszlopok szerint”).

Mindezeket figyelembe véve a következő ajánlások fogalmazhatók meg:

  • Használja a legegyszerűbb, bevált módszereket az argumentumok DLL-függvényeknek való átadására. A Win API-hoz elfogadott szabványok meglehetősen alkalmasak modellként.
  • Soha ne adja át a karakterlánc-változók tömbjét.
  • Legyen nagyon óvatos, amikor egyszerű karakterlánc-változókat és többdimenziós tömböket ad át.
  • Ügyeljen arra, hogy speciálisan ellenőrizze az argumentumokat a meghívott eljárásnak és vissza továbbító mechanizmus működését. Írjon egy speciális tesztet az adatátvitel ellenőrzésére. Külön-külön ellenőrizze, hogy minden argumentum megfelelően lett-e átadva. Ha például több argumentummal rendelkező eljárása van, először ellenőrizze, hogy az egyes paraméterek helyesen lettek átadva az egyargumentumos beállításnál, és csak ezután a teljes listánál.

De mi van akkor, ha a DLL függvény már meg van írva például Fortranban, de a bemeneti felülete nem nagyon illeszkedik a fenti VB szabványokba? Itt van két tanács. Először: írjon egy teszt DLL-függvényt, és próbálja meg vele megtalálni a kívánt hívást a VB programból próba és hiba segítségével. Másodszor: írjon egy adapter eljárást ugyanabban a Fortranban, amely egyszerű interfészt biztosít a VB és a DLL függvény között az egyszerű adatszerkezetek összetettekké alakításával (például konvertáljon egy többdimenziós bájttömböt string tömbbé).

Tehát: használjon DLL függvényeket. De légy éber...

ComputerPress 9"2000

Kezdjük az alapokkal: mi az API? A rövidítés az Application Programming Interface vagy az alkalmazásprogramozási interfész rövidítése. Úgy tűnik, hogy a név önmagáért beszél, de jobb, ha megfontol egy részletesebb magyarázatot.

Mint már említettük, az API mindenekelőtt egy interfész. Olyan interfész, amely lehetővé teszi a fejlesztők számára, hogy kész blokkokat használjanak egy alkalmazás létrehozásához. Fejlesztés esetén mobil alkalmazások az intelligens otthonokkal való munkavégzésre szolgáló könyvtár API-ként működhet - minden árnyalat a könyvtárban van megvalósítva, és csak hozzáférhet ehhez az API-hoz a kódjában.

Webes alkalmazások esetén az API a szabványos HTML-től eltérő formátumban is visszaadhatja az adatokat, így kényelmesen használható saját alkalmazások írásakor. A harmadik fél nyilvános API-i leggyakrabban két formátum egyikében szolgálnak ki adatokat: XML vagy JSON. Ha úgy dönt, hogy API-t készít az alkalmazásához, ne feledje, hogy a JSON sokkal tömörebb és könnyebben olvasható, mint az XML, és az XML formátumú adatokhoz való hozzáférést biztosító szolgáltatások fokozatosan elhagyják az utóbbit.

API webes alkalmazásokban példákkal

Egy alkalmazás – például a Github – rendelkezik saját API-val, amelyet más fejlesztők használhatnak. Az, hogy hogyan fogják használni, az API által biztosított képességektől és attól függ, hogy mennyire működik jól a fejlesztők fantáziája. A GitHub API lehetővé teszi például, hogy információkat szerezzen a felhasználóról, avatarjáról, olvasóiról, adattárairól és sok más hasznos és érdekes információról.

Hasonló módon kérést küldhet bármilyen nyelven, beleértve a Ruby nyelvet is. A kérelemre adott válasz hozzávetőlegesen a következő információkat tartalmazza:

( "bejelentkezés" : "Freika" , "id" : 3738638, "avatar_url" : "https://avatars.githubusercontent.com/u/3738638?v=3", "gravatar_id" : "" , "url" : "https://api.github.com/users/Freika", "html_url" : "https://github.com/Freika" , "followers_url" : "https://api.github.com/users/Freika/followers", "following_url" : "https://api.github.com/users/Freika/following(/other_user)", "gists_url" : "https://api.github.com/users/Freika/gists(/gist_id)", "starred_url" : "https://api.github.com/users/Freika/starred(/owner)(/repo)", "subscriptions_url" : "https://api.github.com/users/Freika/subscriptions", "organizations_url" : "https://api.github.com/users/Freika/orgs", "repos_url" : "https://api.github.com/users/Freika/repos", "events_url" : "https://api.github.com/users/Freika/events(/privacy)", "received_events_url" : "https://api.github.com/users/Freika/received_events", "type" : "User" , "site_admin" : false , "name" : "Evgeniy" , "company" : "" , "blog" : "http://frey.su/" , "location" : " Barnaul" , "email" : "" , "hireable" : true , "bio" : null, "public_repos" : 39, "public_gists" : 13, "followers" : 15, "following" : 21, "created_at" : "2013-03-01T13:48:52Z" , "updated_at" : "2014-12-15T13:55:03Z" )

Amint a fenti blokkból látható, a válasz tartalmazza a bejelentkezést, az avatart, a webhelyen és az API-ban lévő profil linkjét, a felhasználói állapotot, a nyilvános adattárak számát és egyéb hasznos és érdekes információkat.

Az API önmagában nem elég

Egy teljes értékű API létrehozása az alkalmazáshoz csak a csata fele. Hogyan kell hozzáférni az API-hoz? Hogyan férhetnek hozzá a felhasználók?

Az első dolog, ami eszünkbe jut, az a szokásos HTTP-kérések sorozata a fogadás érdekében szükséges információ, és ez a rossz válasz. A legkézenfekvőbb módszer ebben az esetben nem a legkényelmesebb és egyszerűbb. Sokkal ésszerűbb lenne egy speciális könyvtár létrehozása a felülettel való munkavégzéshez, amely leírja az összes szükséges módot az API-n keresztüli információ fogadására és küldésére.

Mondjunk még egyszer egy példát a Github segítségével: ennek a kiváló szolgáltatásnak az API-jával való együttműködéshez (és felülete kiterjedt lehetőségeket biztosít), számos könyvtárat hoztak létre különböző nyelveken, például az Octokit gem. Az ilyen könyvtárak dokumentációjában (és a példaként megadott gyöngyszemben) minden érdeklődő fejlesztő megtalálhatja az összes szükséges módot, hogy információkat kapjon a Githubtól, és visszaküldje azokat a szolgáltatás API-n keresztül.

Ezért, ha saját API-t hoz létre, fontolja meg esetleg könyvtárak létrehozását, amelyek a leggyakoribb nyelveken működnek vele. És készüljön fel arra, hogy az Ön alkalmazása iránti kereslet bizonyos szintjén valaki más létrehozhatja saját könyvtárát az API-val való együttműködéshez. Ez jó.

Hasznos Linkek

A következő cikkekben arról fogunk beszélni, hogyan lehet helyesen létrehozni egy API-t, biztosítani annak biztonságát és korlátozni bizonyos információkhoz való hozzáférést.

Sandbox

besorozott 2012. november 26-án 13:59-kor

Mi az API

  • Faszoba *

Üdvözlet!
Ebben a cikkben megvizsgáljuk, mi az API, hol, hogyan és mire használják. Azt is megvizsgáljuk, hogyan használható az API a webes fejlesztésekben, és hogyan könnyítheti meg a webprogramozó életét.

Kezdjük tehát a meghatározással. Az API (Application Programming Interface) egy programozási felület, egy interfész alkalmazások létrehozására. Érthetőbben fogalmazva, az API egy kész kód, amely megkönnyíti a programozó életét. Az API-t azért hozták létre, hogy a programozó kész kód (például függvények) használatával megkönnyítse az alkalmazás írását. A jól ismert, JavaScriptben írt jQuery is egyfajta API. Ha konkrétan ezt a példát nézzük, a jQuery sokkal könnyebbé teszi a kódírást. Amit 30 sorban meg lehet tenni normál JavaScript eszközökkel, az 5-6 sorban van leírva a jQuery segítségével. Ha általánosságban nézzük az API-kat, nagyon sok olyan szolgáltatást találhatunk, amelyek fejlesztési megoldásokat nyújtanak. A leghíresebb ma a code.google.com szolgáltatás, amely mintegy ötven különböző API-t biztosít! Ez magában foglalja az Android-alkalmazások létrehozására szolgáló felületet, az AJAX-szal való munkavégzéshez szükséges különféle API-kat, valamint a különféle alkalmazás-API-kat, amelyek egyszerűen tetszés szerint testreszabhatók.

Végül is van értelme saját magunk kódot írni? Miért kell azon dolgozni, ami már elkészült? Van-e értelme visszautasítani az ingyenes megoldásokat (és valójában az ingyenes segítséget)? webfejlesztés? Ha ezekre a kérdésekre NEM-mel válaszolt, úgy gondolja, hogy megértette az API lényegét.

De szeretnék foglalni is. Kezdő fejlesztők NE használjanak félkész megoldásokat, mert a jövőben nem fognak megbirkózni a valódi problémával. Ezért, ha Ön kezdő webprogramozó, akkor ne használjon félkész termékeket! Tanulj meg a saját fejeddel gondolkodni, építs fel különféle algoritmusokat a programozás lényegének megértéséhez. Azt is mondom, már mindenkit megszólítva, hogy az API-k nem kész megoldások, hanem egy környezet, felület a saját projektek létrehozásához. Ugye nem eszel fagyasztott szeletet a boltból? Előbb megsütöd őket, igaz? Ez a hasonlat nagyon világosan megragadja az API lényegét.

Általában elmondtam, mi az API, hol és hogyan használják, és ami a legfontosabb, miért. Jó szórakozást a tanuláshoz webes programozásés egyre nagyobb mélységeinek megértése!

Címkék: api

Ez a cikk nem kommentálható, mivel a szerzője még nem teljes jogú tagja a közösségnek. A szerzővel csak azután lehet kapcsolatba lépni, hogy megkapta



Betöltés...
Top