TRIppleEffect osztály olyan effektus létrehozására, amely hullámfodrozódást helyez a vizuális objektumok textúrájára.
A hullámosság középpontja a tulajdonságban van megadva Központ. A hullámosság egyéb jellemzői a tulajdonságok segítségével testreszabhatók Amplitúdó(Amplitúdó), Képarány, És Fázis(Fázis). A hullámok számát a tulajdonság határozza meg Frekvencia(Frekvencia).
A következő táblázat a hatások eredményeit mutatja TRIppleEffect az űrlapon elhelyezett PNG-fotóhoz (az objektum segítségével). A hullám közepe a kép közepén van. Egyéb tulajdonságok TRIppleEffect alapértelmezett értékeikkel használják ( Amplitúdó = 0,1, Képarány = 1,5, Frekvencia = 70, Fázis = 0).
Ebben az oktatóanyagban néhány alapvető képeffektust fog használni egy FireMonkey alkalmazásban.
1. lépés: Alkalmazza az effektust a képre.
A FireMonkey alkalmazásban egy képeffektus alkalmazása egy képre egyszerű folyamat. Csak hozzon létre egy komponenst, amely tartalmazhat képet, majd alkalmazza az egyik képeffektust.
Hozzon létre egy új FireMonkey alkalmazást ( Fájl > Új > FireMonkey asztali alkalmazás > HD FireMonkey alkalmazás).
Helyezze az alkatrészt az űrlapra.
Válassza ki az összetevőt az eszköztáron.
Helyezze el a TImage-et az űrlapon a konstruktorban.
Látható, hogy az összetevő nincs az űrlaptervező közepén. Amint az ábrán látható, szükséges, hogy a képterület mérete a lehető legnagyobb legyen. Ehhez válassza ki az összetevőt a tervező űrlapon, majd módosítsa a tulajdonságokat Igazítsa V alClient az Objektumfelügyelőben, így az összetevő mérete megegyezik az űrlap régió ügyfélméretével.
Válassza ki azt a képet, amelyre az effektust alkalmazni szeretné. A komponens a képet egy tulajdonságban tárolja bittérkép. Válassza ki az ingatlant bittérkép az objektumellenőrben, és használja Szerkesztés... kép kiválasztásához.
Most Ripple Effect megjelenik az ablakban szerkezet.
Egy hatás alkalmazásához egy másik összetevő gyermekeként kell meghatározni. Ebben az esetben, RippleEffect1 gyermekként kell meghatározni Kép1. Ehhez húzza RippleEffect1és helyezze rá Kép1 a szerkezeti panelen.
2. lépés: Alkalmazzon animációs effektust a RippleEffect-re.
Kiemel Ripple Effect a panelen szerkezet.
Jelöljön ki egy ingatlant Fázis az Object Inspectorban, és futtassa a parancsot Hozzon létre új TFloatAnimációt a legördülő menüből.
Győződjön meg arról, hogy FloatAnimation1 gyermekelemként definiálva RippleEffect1.
Tulajdonságok módosítása FloatAnimation1 az alábbi:
És végül adjunk hozzá egy esemény eljárást OnMouseMove Nak nek .
A FireMonkey az „új Delphi” alaptechnológiája. Kérem, mondja el nekünk ennek az alapvetően új könyvtárnak a céljait, képességeit és technikai vonatkozásait. Egy idő után, visszatekintve, mennyire volt kemény és indokolt, hogy elutasította a szupernépszerű VCL továbbfejlesztését?
Ezt választották a Delphi technológia fejlesztésének fő irányának egy konkrét cél elérése érdekében - többplatformos fejlesztés egy környezetből, egyetlen forráskód bázison, és a fejlesztők radikális átképzése nélkül. A mára klasszikussá vált és rendkívül népszerű VCL keretein belül ez lehetetlen volt, a WinAPI-val való kapcsolata túl szoros volt, mondhatni „genetikai szinten”.
A VCL komponensek nem rendelkeztek "absztrakt" réteggel a funkcionális szint között az interfész és leképezési mechanizmusaik tekintetében. Funkcionális szint- hogyan viselkedik vezérlőként, milyen eseményekre reagál, milyen felhasználói interakciót biztosít. Kijelző- a platform-orientált renderelési módszerek raszteres objektumok és vektorprimitívek által alkotott képként való meghívása. A FireMonkey kezdetben azt az elvet alkalmazta, hogy a vezérlést szigorúan két részre osztotta: „viselkedési” és „vizuális” részre.
Vsevolod Leonov, Embarcadero Technologies
Az első egészében nem is a VCL alapjait fogja megismételni, hanem az objektum-orientált programozás lényegét. A komponens egy osztály, az összetevő osztályok hierarchiát alkotnak, ahol a családok és a modulok megkülönböztethetők. Egy komponens osztályának nem sok köze van ahhoz, hogy hogyan készül.
A vizuális "kép" dinamikusan formálódik, nincs bekódolva a komponens osztályba. A FireMonkey képe vagy „stílusa” az alkalmazás indításakor betöltődik egy összetevőbe. Van valamiféle funkcionális keretünk az alkatrészhez, és a "héj" vagy "burkolat" változtatható, de miért? Ezért a FireMonkey alkalmazások minden platformon hitelesnek tűnnek – Windows 7, Windows 8, Mac OS, iOS és a közeljövőben Androidon. A hagyományos monolitikus VCL osztálystruktúra ezt nem tudta biztosítani.
Itt a technológiai megközelítés kiemelt szerepet játszik. Elvileg felveheti a VCL-könyvtárat, és „megtömheti” a WinAPI-t az összes többi lehetséges platformhívással. Az összetevők egy nagyon korlátozott részhalmazán ez továbbra is megtehető, de a VCL több száz összetevőt tartalmaz, így ez a megközelítés egyszerűen „megölheti” a VCL-t. Úgy döntöttek, hogy nem érintik meg a VCL-t, és új funkciókat fejlesztenek ki az új platformon - FireMonkey. Ez a technológia még egy bizonyos technikai eleganciával is rendelkezik - a projekt összeszerelésekor egy adott platformra Delphi környezet Az IDE csatlakoztatja a szükséges fordítót, és az interfész komponensei megkapják a platform stílusát.
A felhasználó számára ez egy kattintás az egérrel és ugyanaz a forráskód, a Delphi számára pedig a fejlesztők sok éves kemény munkája egy ilyen többplatformos könyvtár létrehozása.
Amikor világossá vált, hogy a FireMonkey különálló új platformként kerül bemutatásra, a megfelelő együttélési stratégiát kellett választani: az Embarcadero semmilyen módon nem akarta negatívan befolyásolni a VCL felhasználókat. Ezért a következő tervet választottuk: A VCL ideológiailag és építészetileg stabil marad a lehető legnagyobb kompatibilitás biztosítása érdekében, miközben megkönnyíti a projektek átállását a modern verziókra. A FireMonkey fejlesztése természetes és párhuzamos utat fog követni, anélkül, hogy vissza kellene tekintenünk a VCL-re.
Ennek a megoldásnak a gyenge pontja a meglehetősen problémás migráció VCL-ről FireMonkey-ra egy projekten belül. Másrészről azonban egy új projekthez a fejlesztő választhatja a FireMonkey-t, hogy biztosítsa az eredményül kapott alkalmazás többplatformos jellegét. Az iOS-támogatással ellátott XE4 megjelenésével máris a Delphi céges környezetben való mobilfejlesztés terén erős versenyelőnyéről beszélhetünk, amely az Androidra tervezett támogatás megvalósítása után tovább nő.
Ezért, mint ilyen, nincs kifejezett „elutasítás” a VCL fejlesztésével kapcsolatban. Új verziókban a Delphi VCL részét is fejlesztik. Ez magában foglalja a 64 bites támogatást, a vizuális komponensek stílusának bevezetését, valamint a rugalmas dinamikus linkek vagy "kötés" mechanizmusának megvalósítását, valamint a FireDAC könyvtár beépítését az adatbázisokkal való munkavégzéshez a VCL projektekben. Csupán arról van szó, hogy a FireMonkey miatti óriási minőségi ugrás hátterében a VCL fejlődése némileg megnyilvánulatlannak tűnik. De bármi is legyen, a VCL a Delphi szerves része, és az is marad még sok éven át. Bár a platformok fejlődése és a dolgok jelenlegi állása az asztali rendszerek és mobileszközök operációs rendszere terén olyan, hogy a jövő egyértelműen a FireMonkeyé.
Az interjúban már szó esett az iOS támogatásáról, meséljünk olvasóinknak mások támogatásáról a legújabb technológiákat a legújabb RAD Studio XE4-ből, például Windows 8 és WinRT, 64 bites rendszerek, MacOS és így tovább. Felsorolnád, mit tud még nyújtani egy újításokkal elkényeztetett modern programozónak?
Valószínűleg a modern programozót nem "rontják el" az innovációk. A nagy projektek esetében minden „innováció” gyakran gigantikus mennyiségű munkává válik.
Például mindenki sokáig várt, sokan azonnal rohantak átvinni a kódjaikat egy új platformra. De kiderül, hogy még a nagyon profi csapatok sem állnak készen erre. A lefordítható 64 bites kód nem azt jelenti, hogy működőképes. A "fiatalság bűnei" kezdtek megjelenni, például a 4 bájtos címméretet feltételező utasítások használata. A tesztek lefolytatásának kultúrájának hiánya, párosulva azzal a technológiai hajlandósággal, hogy ezt a folyamatot rövid időn belül végrehajtsák.
És itt - minél nagyobb a projekt, mondjuk a sorok számával mérve forráskód, a programozók óvatosabbak és kiegyensúlyozottabbak, amikor különféle újításokról van szó, kezdve a „gomb” megjelenésétől a felületen a „szintaktikai cukorig” a fordítóprogramban.
Az egyik ilyen „problémás” teljesítmény az volt Windows kilépés 8. Én személy szerint PC-felhasználóként és csak egy modern informatikusként örülök a Windows 8-nak. Ez azonban bizonyos nehézségeket jelent azoknak a fejlesztőknek, akiknek egy köteg Windows 8 számítógépet küldtek az új operációs rendszer alatti fejlesztéshez szükséges műszaki specifikációkkal.
Igyekeztünk a lehető legkényelmesebb és fájdalommentes módon támogatni a fejlesztést. új felület ezt az operációs rendszert. Ezért mind a VCL, mind a FireMonkey esetében speciális stílusokat vezettek be, és a programozó vagy újraépítheti az alkalmazás felületét, vagy létrehozhat egy új alkalmazást, amely megkülönböztethetetlen lesz a Windows 8 „natív” alkalmazásától. kinézet. Természetesen szükség van "bennszülöttre" Windows támogatás 8 a WinRT miatt. De itt a célok prioritása a modern körülmények között befolyásolja. A Mac OS, iOS, Android a közeljövőben még nem ad lehetőséget arra, hogy a közeljövőben a WinRT teljes körű támogatásáról beszéljünk.
Az Embarcadero stratégiai célja természetesen a többplatformos. A RAD Studio XE4 megjelenése kulcsfontosságú volt, elsősorban az iOS támogatása miatt. A VCL-t használó aktív programozó órákon belül elkezdheti az iOS-re való fejlesztést. Még egy egyszerű mobilalkalmazás is azonnal hatékony projektté alakítható, amely a meglévő infrastruktúrán belül működik. Ne gondolja, hogy ez csak egy új fordító a FireMonkey számára, és egy új stílus, amely illeszkedik az iOS felületéhez.
Ez magában foglalja az új vizuális tervezőt, a különféle formai tényezők beépített támogatását, az adatelérési könyvtárakat, beleértve az új FireDAC-ot, valamint a LiveBindings technológiát a vállalati adatok rugalmas és dinamikus összekapcsolásához. Mindezek az újítások szinkronban jelennek meg – Windows, Mac OS és iOS rendszeren. Műtőszoba Mac rendszer Az operációs rendszer nem fejlődik olyan gyorsan, így nincs olyan probléma, mint a Windows 7-ről a Windows 8-ra való átállás. De voltak retina kijelzők, és ez különös figyelmet igényelt. Mostantól minden Delphi XE4-ben létrehozott MacOS-alkalmazás automatikusan két stílust tartalmaz: "normál" és "nagy felbontású".
Hogy. ugyanannak az alkalmazásnak bármelyikén ugyanolyan minőségű "natív" felülete lehet asztali számítógép az Apple-től.
Az Embarcadero nem akarja "meglepni", "lenyűgözni" vagy akár "szórakoztatni" a fejlesztőket új, innovatív kiadásaival. Éppen ellenkezőleg, az informatikai szféra már tele van különféle meglepetésekkel: új eszközök, új platformok, új felhasználók, új igényeik, új interakciós forgatókönyvek. Adjunk hozzá új szoftverfejlesztési technológiákat, és a programozóknak egyszerűen nem lesz idejük új és meglévő rendszereket létrehozni – csak annyit fognak tenni, hogy egyik környezetből a másikba, egy régi könyvtárból egy újba, egyik nyelvről egy másik.
De nem vallunk minden új elutasítását. Csupán mindennek – a kódnak, az interfésznek, a projektnek, de még a szakmai ismereteknek is – a folytonosságát szeretnénk biztosítani, ahogy új platformok és eszközök jelennek meg. Kijelenthetjük, hogy egy egészségtelen konzervativizmus ellen küzdünk az új platformokkal kapcsolatban, a fejlesztési eszközök egészséges konzervativizmusának rovására. Ne várjon egzotikus termékeket, nem szabványos programozási nyelveket és szokatlan fejlesztőeszközöket az Embarcaderotól.
Nálunk mindig megtalálja a vizuális fejlesztést, a klasszikus nyelveket, a "natív" kódot, és hagyja, hogy az alkalmazásainak ugyanazon bevált klasszikus módon készített célplatformjai újak legyenek.
Ennek a blognak az összefüggésében ez a projekt elsősorban azért érdekes, mert FireMonkey-n valósítják meg, és csodálatosan demonstrálja ennek a platformnak a képességeit. Így a múlt héten megjelent a termék nyilvános bétaverziója. Így a blog olvasói „megérezhetik” az igazán összetettet tűzmajom Alkalmazás.
Néhány szó a programról. Mindenekelőtt meg kell jegyezni, hogy a Sphere jelenlegi verziója egy kicsit másképp van elhelyezve. Igen, néha előfordul...
Új SphereLive Ez nem csak egy újabb hírnök. Először is, ez egy olyan eszköz, amely lehetővé teszi az oktatási folyamat hatékony megszervezését. Lehetővé teszi a távoli előadásokat, privát konzultációkat, egyéni órákat és egyéb hasonló rendezvényeket. Ugyanakkor szinte mindennel fel van szerelve, ami a munkához szükséges. Kezdve egy egyedi fájlátviteli rendszerrel és egy hatékony számlázási alrendszerrel.
Ebben a szakaszban a termék használatának ára meglehetősen demokratikus. Korlátozott számú hallgatóság és kis mennyiségű erőforrás esetén a termék ingyenesen használható.
Természetesen a Sphere használja ki a fő előnyt tűzmajom- cross-platform. Az alkalmazás most elérhető Windows és MacOS kiadásokban. android verzió napról napra várható.
Ennek ellenére számomra a SphereLive elsősorban innovatív termékként érdekes, eredeti megoldások egész sorával. Néha csak a "...hú, hogy csináltad?" A Sphere egyik fejlesztője egyébként aktívan részt vesz a FireMonkey fórumon folyó vitákban. Ez önmagában is ok lehet az alkalmazás letöltésére és a technikai kérdések közvetlen megbeszélésére a szerzővel. Higgye el, van mit látni, van mit tanulni.
TListView az egyik kulcsfontosságú összetevője a mobilalkalmazás-felület kialakításának tűzmajom. Ez az összetevő nem a legkönnyebben használható, gyakran jelentős mennyiségű kódot tartalmaz, de jelentős cselekvési szabadságot biztosít a fejlesztőnek. Természetesen az alkalmazások is használhatják TListBox ahol minden sokkal könnyebb. De TListBox, fix számú rekord megjelenítésére talán jó, adatforrásokból származó adatok megjelenítésére mindenképpen érdemes használni TListView.
A fő különbségek a TListView és a TListBox között a következők:
- TListBoxItem- ellenőrzés, TListViewItem- Nem
- BAN BEN TListBoxItem A Szülő segítségével bármilyen vezérlőt hozzáadhat. BAN BEN TListViewItem- Nem.
- TListViewItem csak a megjelenítési adatokat tárolja
- TListViewItem maga végzi el a tárolt adatok megjelenítését a metóduson keresztül Vakol
- A TListVIewItem tényleges kézi megjelenítése miatt a sebesség megnövekszik és a memóriafelhasználás alacsony (csak a tényleges adatok tárolása)
- Saját létrehozásához TListViewItem, létre kell hoznia egy saját cikkosztályt, implementálnia kell benne a szükséges adatokat (pl. idő), és létre kell hoznia egy helyben szerkesztőt az idő szerkesztéséhez, regisztrálásához stb.
A teljesítmény javításának és a memóriafelhasználás csökkentésének ténye önmagában erős érv a használat mellett TListView. De van más is.
Sokban Android alkalmazásokat, a listák alábbi megvalósítását láttam. Ha rákattint egy listaelemre (Elem, ha ragaszkodik a választott terminológiához), egy bizonyos művelet végrehajtásra kerül. Általában egy új űrlapot hívnak meg az adatok szerkesztéséhez. De ha megnyomja és lenyomva tartja (Hosszú érintés), teljesen más műveletet hajt végre. És ezek az események nem keresztezik egymást. Egyéb Android szavak Az alkalmazások egyértelműen különbséget tudnak tenni a „hosszú nyomás” és a „normál” között. Ezenkívül a lista görgetése során ezen események egyike sem indul el. Jó példa erre a Yandex Mail leveleinek listája.
Először is szeretnék gratulálni a blog minden olvasójának az elmúlt ünnepekhez, és minden jót kívánok a következő évre.
Érthető körülmények miatt hagyományos újévi beszámolót nem készítettem, valamint az évre vonatkozó terveket sem. Ennek ellenére az élet nem áll meg, folyik a munka, zajlanak bizonyos események a Delphi világában. Vállalom, hogy a közeljövőben a karácsonyi ünnepek alatt kimaradt „híreket a Delphi világából” válogatok. Addig is mesélek az új készülékről, amit vásároltam.
A specifikációkat a hivatalos weboldalon találja. A szubjektív benyomás pedig nagyon kellemes. Figyelemre méltó az a tény, hogy a készülék szó szerint tele van a gyártó saját szoftvereivel. Igen, és az eladók egy lenyűgöző szoftverkészletet kaptak ajándékba. Működés közben az okostelefon elég gyors, és teljes mértékben igazolja költségeit (körülbelül 200 dollár). Egyébként az előző GSmart 1362-es telefonomat kb ugyanennyiért vettem 2 éve. De amint azt valószínűleg sejtitek, számomra az volt a fő érdeklődésem, hogy a tűzmajom alkalmazások.
Mielőtt folytatná az időzítőről szóló történetet - két hír.
Először is megjelent az első XE7 frissítés. A hagyomány szerint a regisztrált felhasználók számára elérhető. Megtalálhatja a javított hibák listáját. Meg akartam nézni, hogyan viselkedik az alkalmazás a frissített környezetben. Valójában nem kellett korrekciót végrehajtani, bár a kísérletek terepe maradt.
Második hír. Akció különleges ajánlatok Az Embarcadero meghosszabbítása év végéig:
Nos, most közvetlenül a bejegyzés témájához. Elvileg nem marad más hátra, mint hogy megpróbáljunk egy már elkészített alkalmazást futtatni Androidra. Ehhez azt használjuk, amiről az előző bejegyzésekben írtam. Mégpedig az újat. Hibakeresést végeztem ezen az alkalmazáson Nexus 7, ennek megfelelően hozzáadta az Android 7 hüvelykes táblagép nézetét. A dizájnon csak egy kicsit kellett „csípni”.
Valószínűleg csak a lusták nem írták meg az időzítőt. A mobilplatformok fejlesztési támogatásával összefüggésben pedig az időzítő Delphiben való megírása általában kultikus feladatnak tekinthető. Így hát arra gondoltam, miért ne a fejlődés példájaként tűzmajom Az alkalmazások nem elemzik pontosan az időzítőt. Android alatt természetesen. Természetesen pontosan ez lesz a véleményem a feladatról, amely bár nem különösebben nehéz, mégis megvannak a maga árnyalatai. Talán van észrevétele vagy javaslata, jó lenne megvitatni ezeket a megjegyzésekben. Egyáltalán nem vagyok szakértő az írásban. mobil alkalmazásokígy minden megjegyzésed értékes lesz számomra.
Pontosan az időzítőt fogjuk kifejleszteni, a kifejezés angol értelmében. Ez azt jelenti, hogy a képernyőn megjelenik egy tárcsa és négy gomb - „Start”, „Szünet”, „Leállítás” és „Mégse”. A visszaszámlálás előre halad (azaz az idő növekszik). Azt az opciót, amiben az idő be van állítva és a visszaszámlálás folyik angol terminológiával, a Stop Watch a neve, talán később megpróbálom megvalósítani. Az alkalmazás, amellyel foglalkozni fogunk, funkcionalitásában közelebb áll a stopperhez.
A Delphi XE7 lehetővé teszi, hogy jelentősen leegyszerűsítsük a fejlesztési folyamatot, mivel most már létrehozhatunk és hibakereshetünk egy valódi alkalmazást a Win32 számára, majd egyszerűen hozzáadhatunk űrlapnézeteket a szükséges mobileszközökhöz, és kis módosítással működő mobilt kaphatunk. Alkalmazás. Túl jól hangzik, hogy igaz legyen? Talán. De ezt az állítást is szeretném ellenőrizni a feladat megvalósításával.
Minél gyakrabban kérdezik meg kollégáimat privát beszélgetések során, hogy lehet-e mobilalkalmazásokat fejleszteni tűzmajom vagy inkább prototípus, mint gyártási megoldás?
Azt hiszem, most még a szkeptikusokat is biztosíthatom.
Kebelbarátom és kollégám, Tagir Yumaguzin mesélt a projektről, amiben már régen részt vett. Most, amikor ez a projekt kiadás előtti állapotban van, úgy döntöttünk, hogy ez a leírás érdekes lesz a Delphi közösség számára. Lényegében egy igazán nagy projektről van szó, amelyet az FM-ben valósítottak meg. A Sphere Live projektről beszélünk. A Habrahabr.ru oldalon nemrég jelent meg egy kis cikk a projektről, Alexey Glyzin, a fejlesztési osztály vezetője beleegyezett, hogy többet mondjon el a projektről, figyelembe véve a blogom közönségét.
A.B.– Alexey, általában mi a projektje?
A.G.: – Az ötlet nem egyből és azonnal megjelent. A „Sphere” projekt előtt csapatunk azon a projekten dolgozott, ahol stream audio/video technológiákat valósítottak meg. Később létrehoztuk saját szoftverünket, amely korlátlan számú felhasználóhoz képes volt multimédiás streameket eljuttatni, beleértve a visszajelzéseket is. De szükségünk volt egy számlázási funkcióra.
A pályázatnak több követelménynek is meg kellett felelnie. Először is a konferenciák maximálisan leegyszerűsített szervezése, illetve a résztvevők felé történő közvetítése, amely összeget nem tudjuk megjósolni. Másodszor, a legfontosabb, hogy lehetőséget adjunk ügyfeleinknek, hogy alkalmazásunkkal keresni tudjanak, és csökkentsük a rendszer összetettségét, a cél eléréséhez szükséges eszközök mennyiségét. A kurzusok, webináriumok vagy egyszerűen csak konzultáció egyszerű megszervezése.
Egy kis emlékezés ezzel kapcsolatban FireDAC V jelenlegi verzióDelphi XE6. De először néhány szót arról, hogy hol keressünk választ a vonatkozó kérdésekre tűzmajom. Az oroszul beszélő felhasználók kiváltságos helyzetben vannak itt.
A RAD Studio XE5 világkörüli turné részeként a harkovi eseményre való felkészülés során egy kis problémába ütköztem a SQLite használva FireDAC. Ha kitöltve Windows alkalmazás vigye át az adatbázist az alkalmazással együtt ide Android, Az adatbázis cirill betűs sorai már nem olvashatók (betűk helyett kérdőjelek jelennek meg). Ha azonban közvetlenül az adatbázist tölti ki mobil eszköz, az orosz karaktereket teljesen helyesen olvassák. Adatok az adatbázisból kitöltve harmadik féltől származó alkalmazás, vagy be Delphi más adatelérési összetevőket használó alkalmazás is normálisan jelenik meg. A rali nem talált megoldást, így egy ismert ukrán futballspecialistát kellett idéznem: „Majd kitaláljuk!”
Utóbbival ellentétben a leírt problémát sikerült megbirkóznom. Alapértelmezés szerint, amikor csatlakoztatva van SQLite V FireDAC ANSI karakterlánc formátumot használnak.
Ha erőlteti az Unicode kódot, akkor minden úgy fog működni, ahogy kell. De van egy kellemetlen pillanat is. A sorok formátumának megváltoztatása után újra létre kell hoznia a mezők listáját az összes adatkészletben, valamint újra kell csatlakoztatnia az adatok megjelenítéséért és beviteléért felelős összetevőket. Ezért jobb, ha azonnal gondoskodunk a kódolásról.
A minisorozat korábbi részeiben egy adatbázis létrehozásával, annak felépítésével és a Delphi-ből való csatlakozással foglalkoztunk. Ebben a részben azt javaslom, hogy a legegyszerűbb esettől kezdve foglalkozzunk az adatok táblázatokból történő megjelenítésével.
Az egyszerű táblázatadat-szerkesztő általában egy összetett alkalmazás része. A táblázatok szerkesztéséhez általában külön űrlapot használok. Kezdjük a termékek listájával. Először is létre kell hoznunk egy DataSet-et, hogy elérjük a táblázat adatait. Esetünkben teljesen lehetséges az összetevő használata TADTable. Tegyük be a DataModule-ba és adjuk meg a tulajdonság értékét kapcsolat. A tulajdonságszerkesztőben táblázat neve megjelenik a táblázatok listája, amelyből kiválasztunk egy táblázatot Termékek. Ha mindent helyesen csinált, akkor hozzárendelheti az ingatlant Aktív igazi érték. Jobb, ha azonnal átnevezi az összetevőt (például ADTProduct). Ezt követően általában létrehozok egy mezőkészletet a DataSet számára. Meghívjuk a mezőszerkesztőt (kattintsunk duplán az összetevőre) és be helyi menü válassza az Összes mező hozzáadása lehetőséget.
Aki nem ismeri, annak elmagyarázom ennek a műveletnek a lényegét. Itt létrehozunk egy előre meghatározott DataSet mezőket. Ha ezt nem kézzel tesszük meg tervezési módban, akkor elvileg semmi szörnyű nem fog történni. A futásidőben ez a készlet automatikusan létrejön. De továbbra is szívesebben készítem manuálisan. Ennek több oka is van. Először is kényelmesebb egy mezőkészlet kezelése, mert tervezési módban magunk is létrehozhatunk további (számított vagy lookUp) mezőket. Maguk a mezők tulajdonságait is módosíthatjuk. Ezenkívül lehetőséget kapunk arra, hogy a TField komponens nevével hivatkozzunk a kód mezőire, ami véleményem szerint nagyban leegyszerűsíti a kód írását.
A VCL alkalmazáshoz hasonlóan a komponenst az adatkészlethez fogjuk csatlakoztatni TDataSource. Ez az összetevő biztosítja a kapcsolatot az adatkészlet és a vizuális vezérlők között. A komponens DataSet tulajdonságának a mi adatkészletünkre (ADTProduk) kell hivatkoznia. Az alábbiakban megadom a DFM fájl egy töredékét
object ADTProduct: TADTable IndexFieldNames = "ID" Connection = ADConnection Update Options. UpdateTableName = "Termék" TableName = "Termék" Bal = 64 Felső = 192 objektum ADTProductID: TADAutoIncField FieldName = "ID" Origin = "ID" ProviderFlags = [pfInWhere, pfInKey] ReadOnly = True end objektum "TFieldName"TFieldField Eredet = "Cím" Méret = 50 végobjektum dsProduct: TDataSource DataSet = ADTPerek bal = 120 Felső = 192 végeFigyeljünk egy érdekességre, a DataModule űrlapfájl nem FMX formátumban kerül mentésre, mint egy hagyományos FireMonkey űrlap, hanem DFM formátumban, mint a VCL-ben.
A következő lépés egy adathalmaz megnyitására szolgáló eljárás létrehozása, amelyet a RunTime-ban kell meghívnunk a program indulásakor. Hozzuk létre ugyanabban a DataModule-ban. Az eljárás kódja rendkívül egyszerű:
eljárás TDM. ConnectToDB ; indítsa el az ADConnection-t. nyisd ki(); ADT termék. nyisd ki(); vége ;Az eljáráshívás a DataModule OnCreate eseménykezelőjébe kerül.
Végezetül szeretném elmondani, hogy az elmúlt néhány évben a FireMonkey az üzleti alkalmazások platformok közötti fejlesztésének professzionális eszközévé nőtte ki magát, és nem csak. Számos hiányosság fokozatosan feloldódik, és minden kiadással modernebbé, önellátóbbá válik a termék, megszűnik a sokéves stagnáláshoz társuló szkepticizmus magával a Delphi nyelvvel szemben is. Új projekteket írni a FireMonkey-n "biztonságos" és ígéretes.
