csak az eredményekért

a határidők szigorú betartása

Átláthatóság

projekt kivitelezés

műszaki támogatás ajándékba

Programozás, fejlesztések, konzultációk az 1C-ről

Hogyan dolgozunk

1. Telefonon megbeszéljük a problémát. Jelenlétében távoli hozzáférés- megjelenik a számítógép képernyőjén.

2. A munkát rubelben értékeljük, ha a projekt nagy, ha nem - a hozzávetőleges óraszám.

3. Elvégezzük a munkát.

4. A programjában munkát vállal, ha hiányosságok vannak, azokat kijavítjuk.

5. Számlát állítunk ki, Ön fizet.

Munka költsége

1. Minden munka 3 kategóriába sorolható: konzultáció, tipikus konfiguráció frissítése, új jelentés kidolgozása vagy programozása, feldolgozás, gombok stb.

3. 10 óra feletti munkára előzetesen műszaki feladatot készítünk a munka leírásával és költségével. A munka a TOR Önnel történő jóváhagyása után kezdődik.

Technikai támogatás

1. Ha a korábban elfogadott munkákban hibát talál, 3 hónapon belül ingyenesen kijavítjuk.

2. Törzsvásárlóink ​​részére a munkánk során tapasztalt hiányosságokat egy éven belül díjmentesen kijavítjuk.

Programok vállalkozása irányításához.

Vásároljon 1C:Enterprise

Mi vagyunk az 1C hivatalos forgalmazója, különféle termékeket vásárolhat tőlünk szoftver termékekés engedélyeket. A „doboz” vásárlása mellett segítünk a program beállításában, tanácsadásban, alapbeállítások elvégzésében.

• Könyvelés
• Áruház automatizálás
• Nagyker
• Segítség a telepítéshez és kezdeti beállítás a csomag tartalmazza!
• Konfigurációk finomhangolása a megrendelő igényei szerint, új modulok fejlesztése a szükséges funkciók hiányában a standard konfigurációban.

1c számvitel	1C: Kereskedelmi menedzsment	1C: Kiskereskedelem	1C: Bérszámfejtés és emberi erőforrás menedzsment
3300 rubeltől.	6700 rubeltől.	3300 rubeltől.	7400 rubeltől.

Szerver biztosítása.

Azonnali beállítási szerver + 1C.

Nincs szerver? Mindegy, mi kiválasztunk és gyorsan beállítunk egy szervert a "felhőben". Kis összegért nagyon megbízható megoldást kap.

• Elérhetőség 24/7
• Nem szükséges megtartani a sajátját rendszergazda(a megtakarítás fedezi a szerver költségeit).
• Az 1C gyors telepítése és telepítése a szerverre, 3 nap múlva már teljesen működőképes rendszere lesz.
• Bármikor költözhet helyi szerver ha a megoldás nem kielégítő.

SMS az 1C-től

Szeretné, ha az ügyfelek időben értesülnének az akciókról és kedvezményekről? Az ügyfelek nem térnek vissza? Testreszab SMS küldése egyenesen 1C-ből!

Cégünk gyorsan be tudja állítani az SMS küldését ügyfeleinek közvetlenül az 1C-ből. Példák automatizálható eseményekre:

• Hála a vásárlásért és a bónuszok azonnali felhalmozódásáért a következő vásárlás után.
• Bónuszok felhalmozása a kártyára ajándékként születésnapra/egy másik fontos vagy ünnepnapra.
• Raktári értesítés.
• Az ajándékutalvány lejárata.
• Értesítés az előleg beérkezéséről és az árufoglalásról.
• Cím és útiterv az üzlethez/irodához, telefonszámok.
• Stb.

A beállítást az 1C-ben szakembereink vagy alkalmazottaink végezhetik el. A tarifákkal az SMS-tarifák oldalon tájékozódhat.

• Garancia SMS kézbesítés, csak a kézbesített SMS-ekért vesznek fel pénzt.
• Minden SMS-hez külön számlázás.
• Egyenleg pótlása különféle módokon.
• Bármikor megtekintheti az összes elküldött SMS előzményét.
• A feladó neve a címzett telefonján található numerikus szám helyett.

Teremtés felület a felhasználó a program működéséhez, kiszolgálásához szükséges Delphi komponensek kiválasztására szorítkozik a komponensek palettájáról felület menedzsment, valamint felület információk megjelenítése, és az Űrlapra történő átvitele a későbbi elrendezéssel.

A létrehozott felhasználói felületnek szabványos, a felhasználók által ismert elemeket kell használnia, és maximális kényelmet kell nyújtania. Mindezt végső soron egy olyan kritérium határozza meg, mint az interfész hatékonysága - a maximális eredmény minimális erőfeszítéssel.
Alkotás alapelvei felhasználóbarát felület ismert. mint a legtöbb Általános elvek alkotás közben felhasználói felületek három fő szempontot lehet figyelembe venni:

1. A programnak segítenie kell a feladat végrehajtását, nem pedig a feladattá válnia.
2. Amikor a programmal dolgozik, a felhasználó ne érezze magát bolondnak.
3. A programnak úgy kell működnie, hogy a felhasználó ne tartsa bolondnak a számítógépet.

Első elv- ez az interfész úgynevezett "transzparenciája". A felhasználói felületnek intuitívnak, könnyen megtanulhatónak kell lennie, és nem szabad olyan problémákat okoznia a felhasználónak, amelyeken a folyamat során meg kell küzdenie. Használjon szabványos, túlzott díszítőelemek nélküli, ismert, használt használatot hasonló programokat menedzsment technikákat, és eléri a teljesítménykritériumokat első elv.

Második elv elhanyagolásban rejlik intellektuális képességek felhasználókat. Saját tapasztalatomból tudom, hogy a felhasználók gyakran nemcsak nem tudják, hogyan kell számítógépen dolgozni, hanem egyszerűen félnek bármit is megtenni. Ezért a felhasználói felületnek a lehető legbarátságosabbnak kell lennie.
Sőt, a felhasználók félelmei gyakran jogosak, mert a program és maga a számítógép költsége nem hasonlítható össze például egy sok éves erőfeszítéssel létrehozott adatbázis költségével. Éppen ezért a programozónak a felhasználói felület létrehozásakor mindig be kell építenie a programba a "bolond védelmet" - a hibás műveletektől és a hibás adatok bevitelétől. De egyes programozók túlságosan elragadtatják ezt a védelmet, túlságosan tolakodóvá teszik, és ennek eredményeként a program működése a híres "lépés balra, jobbra lépés menekülésnek számít"-hoz hasonlít! És amit egy programozó egy probléma megoldásaként hoz létre, az maga kezd problémákat okozni.
Ahhoz második elv nem szükséges megengedni, hogy a program „korrigálja” a felhasználó cselekedeteit, és jelezze, hogy pontosan mit tegyen helyette, szűk keretek közé terelve. Nem szabad túlságosan elragadtatni magát a tájékoztató jellegű üzenetek, különösen a párbeszédes üzenetek megjelenítésével, mivel ez elvonja a felhasználó figyelmét a munkáról. És jobb, ha lehetőséget biztosítunk a felszólítások teljes letiltására.

Harmadik elv az, hogy a lehető legnagyobb "szellemi" képességekkel rendelkező programot készítsünk. A gyors fejlődés ellenére számítógépes technológia, az elterjedt programok is csak nagyon feltételesen nevezhetők mesterséges intelligenciával rendelkezőnek. Megjelenítésükkel zavarják a felhasználói élményt párbeszédpanelek hülye kérdésekkel, amelyek a legegyszerűbb helyzetekben is fejtörést okoznak. Ennek eredményeként a felhasználók szívükben felkiáltanak: "Hát, ez az autó hülye!"
Engem személy szerint idegesítenek szinte mindenki állandó kérdései. szövegszerkesztők arról, hogy mentsük-e a módosított szöveget, bár az eredeti és a jelenlegi szöveg egyetlen karakterrel sem különbözik. Igen, beírtam valamit, de aztán visszaadtam mindent, tényleg lehetetlen kitalálni! Meg kell néznem, hogy nem rontottam-e el valamit.

Próbálja meg betartani a következő szabályokat:

Szabványos interfész elemek

Ehhez használja a szabványt adott elem komponens interfész. Miután találkozott a programjával, a felhasználó nem vesztegeti az időt az ismerkedésre, hanem azonnal elkezd dolgozni - ez a professzionálisan elkészített program egyik jele.

Kis szerszámpaletta

Próbálj meg nem túl sokat használni nagyszámú különféle alkatrészek. És persze ha egy standard komponenst használunk valahol egy helyen, hasonló esetben használjuk is.

Egyenlő távolság a kezelőszervek között

Az interfész elemeket egymástól azonos távolságra helyezze el. A véletlenszerűen szétszórt alkatrészek egy nem professzionális termék érzetét keltik. És fordítva, a Form gombok, kapcsolók, jelölőnégyzetek és egyéb, a felületet alkotó alkatrészek gondosan kalibrált elhelyezése a minőségi munka jele.

lapok sorrendje. "helyes sorrendben

TabOrder az a sorrend, amelyben a képernyő kurzora a kezelőszervek felett mozog, amikor egy billentyűt lenyomnak Tab. Egy helyesen megírt programban a kurzor mozog, követve a felhasználó programozási logikáját. A program létrehozásakor a programozó gyakran módosítja az összetevőket, egyeseket eltávolít, és szükség szerint hozzáad másokat. Ennek eredményeként a kész programban a kurzor véletlenszerűen átugrik az űrlapon. A program befejezése után ne felejtse el beállítani TabOrder.

Betűtípus kiválasztása

Csak hagyja békén a betűtípusokat. A Delphi saját alapértelmezett betűtípusai minden olyan rendszeren működnek, amelyen a program fut. Csak a fontos elemek kiemeléséhez használjon félkövér betűtípust. Alkalmazás kurzívés főleg aláhúzás, amelyet a felhasználó összetéveszthet egy hiperhivatkozással - rossz formában.

Színválaszték

Ami a felületelemek színeit illeti, csakúgy, mint a betűtípusok esetében, jobb, ha alapértelmezésben szabványosnak tekintjük. A Delphi a Windows rendszerpalettáját használja, ennek megváltoztatásával a felhasználó könnyedén testreszabhatja a színeket.

Alternatív menedzsment

Egy professzionálisan elkészített program ne csak egérrel, hanem billentyűzettel is vezérelhető legyen. Ne legyenek olyan funkciók, amelyek csak egérrel hajthatók végre (a grafikus szerkesztőkben való rajzolás nem számít!). A leggyakrabban használt funkciókhoz "gyorsbillentyűket" kell biztosítani a gyors hozzáférés érdekében.

Interfész építőelemek

Ami a felhasználói felület egyes elemeit illeti, a programmal való felhasználói interakció minősége a következőktől függ:

• az ellenőrző elem megfelelése feladatának;
• az ellenőrzés működésének szabályai.
  Ez az oldal néhány felületelem létrehozásának szabályait tárgyalja.

És most szeretném bemutatni, hogy a Delphi milyen eszközöket kínál az űrlapon lévő összetevők kezeléséhez, ezek egymáshoz viszonyított helyzetét és a kurzor viselkedését egy billentyű lenyomásakor. Tab.

Az összetevők egymáshoz viszonyított megfelelő sorrendbe állítása érdekében először ki kell emelni őket. Egyszerűen húzza az egeret az űrlap azon területére, amely a kiválasztott összetevőket tartalmazza. Vagy tartással Váltás", ugyanazzal az egérrel adja meg az egyes kiválasztandó komponenseket. Ismételt egérkattintás a kiválasztott összetevőre (a "" nyomva tartása közben Váltás") törli a kijelölést.

A kiválasztott összetevők egyetlen egészként kezelhetők - mozgathatók az űrlapon, értékeket rendelhetnek ugyanazokhoz a tulajdonságokhoz, másolhatók (például telepítéshez egy másik űrlapra), akár törölhetők is.

Most kattintson a jobb gombbal az egyik összetevőre, és válassza ki a "felbukkanó" menüből Pozíció -> Igazítás... Megjelenik egy párbeszédpanel, amely lehetővé teszi a csoport összetevőinek vízszintes és függőleges helyzetének beállítását. Például a négy gombunkat balra kell igazítanunk, és meg kell győződnünk arról, hogy van köztük ugyanaz a távolság függőlegesen. Ehhez válassza ki a rádiógombokat Vízszintes: bal oldalonés Függőleges: Egyenlő tér.

Egy elem kiválasztása Központ, az alkatrészeket úgy rendezzük el, hogy a középpontjuk vízszintesen vagy függőlegesen ugyanabban a vonalban legyen, és a pont Középre az ablakban az alkatrészeket az ablak közepére mozgatja, akár vízszintesen, akár függőlegesen.

Ugyanebben a menüben a sor Tab O rendelés... párbeszédpanel megjelenését idézi elő, amely szabályozza a kurzor mozgását az interfész elemein keresztül, amikor egy billentyűt lenyomnak Tab. Amikor az Űrlap megjelenik a képernyőn, a kurzor természetesen a párbeszédpanel első sorában található komponensen lesz. És akkor lejjebb kerül a listán. A párbeszédpanelen két kék nyíl „fel” és „le” vezérli a kiválasztott komponens pozícióját. Kiemel szükséges komponens, a nyilak segítségével lépjen a kívánt sorra a listában, és így tovább.

Menüpont kiválasztásakor Vezérlés -> Megjelenik egy almenü két elemmel:

• Előre hoz
• küld vissza

Ezek olyan összetevő metódusok, amelyek programozottan is elérhetők. Button1.SendToBack a gombot a „háttérbe” helyezi, és Button1.BringToFront- előre hoz". Vagyis ha az egyik komponens a másik fölé kerül, ezek a módszerek felcserélik őket. Az esetek, amikor ez alkalmazható, meglehetősen nyilvánvalóak.

Az objektum-orientált programozás (OOP) az osztály fogalma mellett az interfész alapfogalmát is tartalmazza.

Mi az az interfész, és milyen jellemzői vannak a Delphi programozási nyelven való használatának?

Az interfész egy szemantikai és szintaktikai konstrukció a programkódban, amely egy osztály vagy összetevő által nyújtott szolgáltatások meghatározására szolgál (Wikipédia).

Valójában egy interfész meghatározza azon tulajdonságok és metódusok listáját, amelyeket az interfészt megvalósító osztállyal való munka során használni kell, valamint ezek aláírását (név, adattípus, elfogadott paraméterek (eljárásokhoz és függvényekhez), stb.). Így egy interfészt megvalósító osztálynak szükségszerűen minden összetevőjét implementálnia kell. Ráadásul szigorúan az abban leírtak szerint.

Nagyon gyakran az interfészeket absztrakt osztályokkal hasonlítják össze, de az összes hasonlóság ellenére ez az összehasonlítás nem teljesen helyes. Az absztrakt osztályokban legalább a tagok láthatóságának szabályozása elérhető. Ugyanakkor az interfészekhez nincsenek meghatározva hatókörök.

Az interfészek lehetővé teszik az architektúra rugalmasabbá tételét, mivel egységesítik a hozzáférést egy adott funkcionalitáshoz, és lehetővé teszik számos osztályörökléssel kapcsolatos probléma elkerülését (az interfészek örökölhetők egymástól).

A Delphi az interfész kulcsszót használja az interfész deklarálására. Ez ugyanaz a kulcsszó, amely egy kívülről elérhető modulszakaszt határoz meg (között kulcsszavakat felület és megvalósítás). Egy interfész deklarálásakor azonban más szintaxist használunk, hasonlóan az osztályok deklarálásához.

Delphi/Pascal

IMyNewInterface = interfész eljárás InterfaceProc; vége;

IMyNewInterface =interfész eljárás InterfaceProc ; vége ;

Így magának az interfész-deklarációs szintaxisnak nincs alapvető különbsége más programozási nyelvekhez képest (a Pascal-alapú szintaktikai jellemzők nem számítanak). Ugyanakkor az interfészek megvalósításának számos jellemző tulajdonsága van.

A helyzet az, hogy a Delphi interfészt eredetileg a COM technológia támogatására vezették be. Ezért az IInterface interfész, amely a Delphiben az összes többi interfész őse (a TObject egyfajta analógja), már három alapvető módszert tartalmaz a technológiával való munkavégzéshez: QueryInterface, _AddRef, _Release. Ennek eredményeként, ha egy osztály valamilyen interfészt implementál, akkor azokat a metódusokat is meg kell valósítania. Még akkor is, ha ezt az osztályt nem COM-mal való együttműködésre tervezték.

Az IIinterface interfész ezen tulajdonsága miatt a Delphiben az interfészek használata a legtöbb esetben nyilvánvalóan nem használt funkciók hozzáadásához vezet az osztályhoz.

Létezik egy TInterfaceObject könyvtárosztály, amely már tartalmazza ezeknek a metódusoknak az implementációját, és ha onnan öröklődik, nincs szükség saját maga implementálni. De mivel a Delphi nem támogatja a többszörös osztályöröklést, használata gyakran csak további bonyolultságot okoz a már szükséges funkciók tervezésében és megvalósításában.

Mindez oda vezetett, hogy az interfészek adta lehetőségek ellenére gyakorlati felhasználásuk a Delphiben szinte nem haladta meg a COM-mal való együttműködést.

Mivel főként ezzel a technológiával működnek, az interfészek, vagy inkább a funkcionalitás és az építészeti megszorítások, amelyeket hibátlanul adnak hozzá, nem igazolják magukat más problémák megoldása során.

Emiatt sok Delphi programozó még mindig nem rendelkezik hatékony és rugalmas eszközzel az alkalmazásarchitektúra fejlesztéséhez.

Ez a cikk a fórumokon feltett kérdéseken alapul: "Hogyan tudok visszaadni egy karakterláncot DLL-ből?", "Hogyan adhatok át és adhatok vissza egy rekordtömböt?", "Hogyan adhatok át űrlapot egy DLL-nek?".

Hogy ne a fél életedet azzal töltsd, hogy kitaláld – ebben a cikkben mindent egy ezüsttányérra teszek.

A cikk témái már nem egyszer érintettek ebben a blogban különböző mértékben, de ebben a cikkben ezeket egy kupacba gyűjtöttük, indoklást adunk. Röviden, egy linket erre a cikkre lehet dobni azoknak, akik fejlesztik a DLL-t.

Fontos jegyzet: cikket el kell olvasni egymás után. A kódpéldák csak mint példák, a cikk minden lépésében (pontjában) a példák kódja új részletekkel egészül ki. Például a cikk legelején nincs hibakezelés, a "klasszikus" metódusok fel vannak tüntetve (például GetLastError használata, sdtcall konvenciók stb.), amelyeket a cikk során megfelelőbbekre cserélnek. Ez azért van így, mert az "új" ("szokatlan") tervek nem vetnek fel kérdéseket. Ellenkező esetben minden egyes példához be kell illeszteni egy megjegyzést az alábbi formában: "erről az alábbi bekezdésben van szó, de arról - ebben itt." Mindenesetre a cikk végén található egy link egy kész kódra, amely a cikkben elmondottakat figyelembe véve íródott. Csak vedd és használd. És a cikk elmagyarázza, miért és miért. Ha nem érdekli a "miért és miért" - görgessen a végére a következtetéshez és egy hivatkozáshoz a példa letöltéséhez.

Az egyik és a legtöbb erősségeit A Delphi programozási környezet a nyitott architektúrája, aminek köszönhetően a Delphi egyfajta metaprogramozást tesz lehetővé, lehetővé téve a "programozási környezet programozását". Ez a megközelítés az alkalmazásfejlesztési rendszerek minőségileg új szintjére emeli a Delphi-t, és lehetővé teszi további beágyazását eszközöket amelyek támogatják az alkalmazásrendszerek létrehozásának szinte minden szakaszát. A lehetőségek ilyen széles skálája nyílik meg a Delphiben megvalósított, úgynevezett nyílt interfészek koncepciójának köszönhetően, amelyek az IDE (Integrated Development Environment) és a külső eszközök közötti kapocsként szolgálnak.

Ez a cikk a Delphi nyílt felületeire összpontosít, és áttekintést nyújt az általuk nyújtott szolgáltatásokról. A Delphi hat nyilvános interfészt határoz meg: Eszközfelület, Tervezőfelület, Szakértői felület, Fájlfelület, Szerkesztőfelület és Verzióvezérlő felület. Nem valószínű, hogy e cikk keretein belül részletesen kitérnénk és illusztrálnánk mindegyik lehetőségét. A Delphi forrásszövegei segítenek a vizsgált kérdések alaposabb megértésében, mivel a fejlesztők részletes megjegyzésekkel látták el őket. A nyilvános felületeket képviselő osztálydeklarációk a megfelelő modulokban találhatók a ...\Delphi\Source\ToolsAPI könyvtárban. A Tervezési felület (DsgnIntf.pas modul) lehetőséget biztosít tulajdonságszerkesztők és komponensszerkesztők létrehozására.

A tulajdonság- és komponens-szerkesztők külön tárgyalásra érdemes témát képeznek, ezért csak arra gondolunk, hogy a tulajdonságszerkesztő szabályozza az Object Inspector viselkedését, amikor megpróbálja megváltoztatni a megfelelő tulajdonság értékét, és a komponensszerkesztő akkor aktiválódik, amikor dupla kattintás bal egérgombbal az űrlapon elhelyezett komponens képére. A Version Control Interface (VCSIntf.pas modul) verzióvezérlő rendszerek létrehozására szolgál. A 2.0-s verziótól kezdve a Delphi támogatja az Intersolv PVCS integrált verzióvezérlő rendszert, így a legtöbb esetben nem szükséges saját rendszert fejleszteni. Emiatt figyelmen kívül hagyjuk a Verzióvezérlő felületet is. A File Interface (FileIntf.pas modul) lehetővé teszi az IDE működő fájlrendszerének újradefiniálását, amely lehetővé teszi a fájlok tárolásának saját módjának megválasztását (például az adatbázis-kiszolgáló Memo mezőiben). Az Edit Interface (EditIntf.pas modul) hozzáférést biztosít a forrásszöveg pufferhez, amely lehetővé teszi a kód elemzését és generálását, a kurzor pozíciójának meghatározását és megváltoztatását a kódszerkesztő ablakban, valamint a forrásszöveg szintaxis kiemelésének vezérlését.

A speciális osztályok interfészt biztosítanak az űrlapon elhelyezett komponensekhez (összetevő típusának meghatározása, hivatkozások lekérése szülő- és gyermekkomponensekre, tulajdonságok elérése, fókusz átadása, törlés stb.), magához az űrlaphoz és a projekt erőforrásfájljához. A Szerkesztőfelület lehetővé teszi az úgynevezett modul értesítők azonosítását is, amelyek meghatározzák az eseményekre adott reakciókat, mint például a modul forráskódjának megváltoztatása, az űrlap módosítása, a komponens átnevezése, a modul mentése, átnevezése vagy törlése, a projekt erőforrásának módosítása. fájl stb. Az Eszközfelület (ToolIntf. pas modul) biztosítja a fejlesztők számára a megszerzéséhez szükséges eszközöket Általános információ az IDE állapotáról és az olyan műveletek végrehajtásáról, mint a projektek megnyitása, mentése és bezárása, és egyedi fájlokat, modul létrehozása, információszerzés az aktuális projektről (modulok és űrlapok száma, neve stb.), regisztráció fájlrendszer, interfészek szervezése az egyes modulokhoz stb. A modul-értesítőkön kívül az eszközinterfész bővítmény-értesítőket is definiál, amelyek értesítenek olyan eseményekről, mint például fájlok és projektek megnyitása/bezárása, projekt asztali fájljának betöltése és mentése, projektmodulok hozzáadása/kizárása, csomagok telepítése/eltávolítása, projekt összeállítása, és a moduláris értesítőkkel ellentétben a bővítmény-értesítők lehetővé teszik bizonyos események végrehajtásának megszakítását.

Ezen túlmenően az eszközfelület lehetővé teszi a Delphi IDE főmenüjének elérését, lehetővé téve további elemek beágyazását. A szakértői felület (ExptIntf.pas modul) az alapja a szakértői tanácsadók létrehozásának - szoftver modulok, beágyazva az IDE-be annak funkcionalitásának bővítése érdekében. A szakértő példája a Delphi Database Form Wizard, amely egy űrlapot generál az adatbázistábla tartalmának megtekintésére és módosítására. Miután meghatároztuk a szakértői osztályt, meg kell győződnünk arról, hogy a Delphi „tanul” a szakértőnkről. Ehhez regisztrálni kell a RegisterLibraryExpert eljárás meghívásával, paraméterként átadva neki a szakértői osztály egy példányát. Illusztrációként készítsünk egy egyszerű szakértőt az esStandard stílusban, amely a megfelelő Delphi menüpont kiválasztásakor üzenetet jelenít meg, hogy fut. Amint a fenti táblázatból látható, az esStandard stílus hat módszert igényel a felülbíráláshoz:

A szakértő „aktiválásához” a Component/Install Component... menüpontot kell kiválasztani, a Tallózás párbeszédablakban ki kell választani a szakértőt tartalmazó modult (esetünkben exmpl_01.pas), kattintani az OK gombra, majd a fordítást követően a dclusr30.dpk csomagot a Delphi főmenüjében a Súgó részében, a Simple Expert 1 elemnek kell megjelennie, kiválasztásakor a „Standard Expert started!” tájékoztató üzenet jelenik meg. Továbbra is rejtély, hogy a Delphi miért teszi a szakértő menüpontot a Súgó részbe. Ha nem tetszik, hogy a Delphiben bárhol megjelenik a menüpont, és nem ott, ahol szeretné, a következő lehetőség lehetséges: hozzon létre egy kiegészítő stílusszakértőt, amely kiküszöböli a menüpont automatikus létrehozását, és adja hozzá a menüpontot „manuálisan” a Tool Interface segítségével. Ez lehetővé teszi, hogy tetszőleges módon beállítsa az új elem helyét a főmenüben.

Menüpont hozzáadásához a TIToolServices osztályt - az eszközfelület alapját -, valamint a TIMainMenuIntf, TIMEnuItemIntf osztályokat használjuk, amelyek interfészeket valósítanak meg az IDE főmenüjéhez és elemeihez. A TIToolServices osztály ToolServices példányát maga az IDE hozza létre inicializáláskor. Vegye figyelembe, hogy a Delphi főmenühöz és annak elemeihez tartozó felületek kiadása a fejlesztő felelőssége. Útközben bonyolítsuk kicsit az Expert Advisor funkcionális terhelését: menüpontjának aktiválásakor tanúsítványt ad ki a ben megnyitott projekt nevéről. Ebben a pillanatban a környezetben: Ebben a példában a központi helyet az AddIDEMenuItem funkció foglalja el, amely egy menüponttal egészíti ki a Delphi IDE főmenüjét. Paraméterként átadja az új menüpont szövegét, azonosítóját, annak az elemnek az azonosítóját, amely elé az új menüpontot beilleszti, a kulcs szimbolikus ábrázolását, amely együtt Ctrl billentyű-ra használható fel gyors hozzáférés az új elemhez, és az új elem kiválasztásának megfelelő eseménykezelőt. Új menüponttal bővült a Nézet rész az Órák elem előtt.

Most pedig ismerkedjünk meg a bejelentőkkel. Adjunk meg egy beépülő értesítést, amely nyomon követi a projektek zárásának/nyitásának pillanatait, és ennek megfelelően módosítja a nevet tároló mezőt aktív projekt(Az előző példához képest nem változott metódusok megvalósítását a rövidség kedvéért mellőzöm): Az értesítő megvalósításához definiáltuk a TAddInNotifier osztályt, amely a TIAddInNotifier leszármazottja, és felülírtuk a FileNotification metódust. Az IDE minden alkalommal meghívja ezt a metódust, amikor olyan esemény következik be, amelyre a bővítmény-bejelentő képes válaszolni (minden ilyen eseményt a megfelelő TFileNotification típusú konstans jelöl). A TAddInNotifier osztály Expert mezőjét használják Visszacsatolás szakértővel (TAddInNotifier.FileNotification módszer). A szakértői megsemmisítőben a bejelentő nyilvántartása törlésre kerül, és a bejelentő megsemmisül. Most pedig szemléltessük a moduláris jelzők használatát. Hozzunk létre egy bővítmény-szakértőt, amely üzeneteket generál a projektfájl mentésének minden egyes műveletéről (a rövidség kedvéért nem adjuk meg a már ismert metódusok megvalósítását): Ebben a példában a bővítmény-szakértő figyeli a projektek megnyitása/zárása.

Minden alkalommal, amikor egy projektet megnyitnak, a projektfájlnak megfelelő modul-bejelentő regisztrálásra kerül. A megvalósítás szempontjából a moduláris értesítők hasonlóak a bővítményértesítőkhöz: meghatározunk egy TModuleNotifier osztályt, amely a TIModuleNotifier leszármazottja, és felülírjuk a Notify és ComponentRenamed metódusait. Az IDE meghívja a Notify metódust, ha a modulhoz kapcsolódó bizonyos események bekövetkeznek; ezen a módszeren belül egy adott eseményre adott reakciót határozzák meg. A ComponentRenamed metódus akkor hívódik meg, ha a modul űrlapon lévő összetevő neve megváltozik. Felhívjuk figyelmét, hogy ezt a metódust nem használjuk, de felül kell írnunk, különben a komponens nevének megváltozásakor az alaposztály absztrakt metódusa kerül meghívásra, ami beláthatatlan következményekkel jár.

A modul értesítő regisztrálása valamivel bonyolultabb, mint egy értesítő bővítmény: először megkapjuk a modul interfészt (TIModuleInterface), majd a modul interfész segítségével regisztráljuk az értesítőt. A projekt lezárásakor a modul értesítőjének regisztrációja törlődik (ismét a TIModuleInterface használatával), és a bejelentő megsemmisül. Befejezésül bemutatjuk, hogyan határozhatja meg a kurzor pozícióját a kódszerkesztő ablakban. Hozzunk létre egy Expert Advisor-t, amely a megfelelő menüpont kiválasztásakor egy üzenetet jelenít meg, amely az aktív fájl nevét és a benne lévő kurzor pozícióját tartalmazza (csak a példához nélkülözhetetlen metódusok megvalósítását adjuk meg): A kurzor pozíciójának meghatározásához a következő interfészsort kell megkapnunk: modul interfész (TIModuleInterface); kódszerkesztő felület (TIEditorInterface); modul nézet felület a szerkesztő ablakban (TIEditView).

Ha a szakértő menüpont kiválasztásakor a forrásszövegű aktív fájl (*.pas) aktív, akkor egy üzenet jelenik meg, amely tartalmazza az aktív fájl nevét és a benne lévő kurzor aktuális pozícióját. Ha az aktív fájl nem passz fájl, nem ad ki üzenetet. A TIToolServices osztály GetCurrentFile metódusa az aktív fájl nevének lekérésére szolgál. Ezzel befejeztük a nyilvános interfészek használatának módjairól szóló vitánkat. A CD-ROM tartalmazza az összes példa forráskódját. A CD-ROM tartalmaz egy bonyolultabb és kibővített példát is, amely egy kiegészítő szakértőt tartalmaz, amely lehetővé teszi a felhasználó számára a Delphi-modulok forráskódjának könyvjelzők közé helyezését. A Bookmark Expert telepítéséhez és használatához egy gyors útmutatót a bkmrks97.htm fájl tartalmazza. Tehát ebben a cikkben a nyilvános felületeket általánosságban tárgyaljuk, és példákat adunk használatukra. A nyílt felületek forráskódjainak köszönhetően ismét könnyen megértheti az Önt érdeklő részleteket. Reméljük, hogy a lehetőségek sokasága biztosított nyitott felületek, több merész és hasznos ötletet ad.