Telerik vezérlők – Forráskódok
Magyarországon is sok cég megvásárolta a Telerik controlok valamelyikét. Egész jók, sok pluszt adnak, és még látványosak is. Szóval tényleg hasznos társai tudnak lenni a fejlesztőknek. Sok céggel találkoztam, akik azt mondták, hogy inkább lefejlesztik a kontrolokat minthogy megvásárolnák, na ebből a végén legtöbbször az lett, hogy magyar fizetés mellet is jó drágán sikerült lefejleszteni egy-egy vezérlőt és még bug-os is volt. A termék támogatás meg igazából azé a fejlesztőé, vagy fejlesztő csapaté, akik csinálták. Így általánosságban véve elmondható (saját tapasztalatomból kiindulva), hogy az ilyen menedzsment döntés elhibázott volt.
Másik gyakori indok, hogy nem kapja meg a fejlesztő a kontrolok forráskódját. Na ez pont nem igaz a Telerik-re! Ugyanis az oldalról le lehet tölteni minden csomag forráskódját, sample fájlt és dokumentációját is.Az igazság az, hogy olykor nagyon is kell. Tegnapi nap futottam bele abba, hogy szerettem volna egy WPF-es telerikkes vezérlő templatejt megváltoztatni, Blendből. Na most az uj blend elégé hisztis lett és az istennek nem volt hajlandó copy templatet csinálni. Jó esetben csinált egy üres stylet, rosszabban semmi sem történt. Itt jön az a helyzet, amit minden WPF / XAML tanfolyamon elmondok. Lehet használni a Blendet, mert egy nagyszerű eszköz tud lenni, de ha valami kínja van ismernünk kell a xaml felépítését, és használatát. A megoldás végül az volt, hogy a forráskódból kiszedtem a sablont, bemásoltam, és XAML-ben soronként ahol kellet testre szabtam. Animációt kicsit kényelmetlenebb így írni, de nem megoldhatatlan.
Szóval ha vezérlőre van szükségünk számoljunk mindig utána, hogy a napi díjunkkal éri meg lefelejleszteni vagy megvásárolni érdemesebb egy vezérlőcsomagot.
Windows 8 és Windows Phone 8 színek
A tegnapi napon elkezdtem egy WPF Metros témát készíteni magamnak. Ennek első része az, hogy össze szedje az ember a Metrós színeket. Gondoltam, ha már össsze szedtem akkor megosztom veletek, hátha kell majd valakinek, legfelejebb valaki spórol vele 10 percet.
<ResourceDictionary xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Color x:Key="Teal">#FF00ABA9</Color>
<Color x:Key="Lime">#FF8CBF26</Color>
<Color x:Key="Taupe">#FF87794E</Color>
<Color x:Key="Brown">#FF825A2C</Color>
<Color x:Key="Olive">#FF6D8764</Color>
<Color x:Key="Green">#339933</Color>
<Color x:Key="EmbraId">#FF008A00</Color>
<Color x:Key="Yellow">#FFE3C800</Color>
<Color x:Key="Orange">#FFFA6800</Color>
<Color x:Key="Amber">#FFF0A30A</Color>
<Color x:Key="Pink">#E671B8</Color>
<Color x:Key="Magenta">#FF0097</Color>
<Color x:Key="Crimson">#FFA20025</Color>
<Color x:Key="Red">#E51400</Color>
<Color x:Key="Blue">#1BA1E2</Color>
<Color x:Key="Cobalt">#FF0050EF</Color>
<Color x:Key="Mrine">#034888</Color>
<Color x:Key="Steel">#FF647587</Color>
<Color x:Key="Mauve">#FF76608A</Color>
<Color x:Key="LightPurple">#5859B9</Color>
<Color x:Key="Violet">#FFAA00FF</Color>
<Color x:Key="Indigo">#FF6A00FF</Color>
<Color x:Key="DarkPurple">#260930</Color>
<Color x:Key="White">#FFFFFFFF</Color>
<Color x:Key="Black">#FF000000</Color>
<Color x:Key="LightWhite">#FFCCCCCC</Color>
</ResourceDictionary>
TFS – Work Item törlése
A munka elemek követésének szíve a Work Item. Hasonlóan mint a projektek esetén itt se a könnyű a törlés. (Teljesen jogosan!) Hisz csak úgy ne távolítsunk el Work Itemeket. Ehhez is rendszergazdai jogosultság kell, és egy parancssoros eszköz, ami ebben az esetben nem más mint a witadmin. Részletek itt a witadmin-ról:
witadmin destroywi /collection:https://tfsprojekt.visualstudio.com/DefaultCollection/ /id:51
A witadmin most már működik a TFS “Online” változatával is!
Work Item-et lehetőség szerint ne töröljünk, csak a status-át módosítsuk removed-ra. Csak akkor töröljük ha tényleg olyan WI-ről van szó ami hibás.
TFS (Preview/Azure/Cloud/Online) Project törlése
A tfs.visualstudio.com oldalon bárki regisztrálhat és kaphat egy jól működő felhős TFS szerververt. 5 felhasználóig ingyenes, fölötte CAL –t kell vásárolni. Egy ideje használom és elégedett vagyok vele. Ugyan nincs benne riporting, meg sharepoint, de annyira nem is hiányzik. Ha ilyenekre tényleg szükség volna akkor beüzemelnék egy szervert. Talán csak a sebességgel vannak olykor gondok. De még gyerek cipőben jár, úgyhogy ezt még elnézhetjük. Jelenleg leginkább csak tanulási célra ajánlanám, élesbe nem merném ajánlani még. De itt látszik, hogy a fejlődés folyamatos.
Visszatérve a tárgyhoz. A tegnapi napon TFS-t oktattam, és felmerült egy kérdés mi szerint, hogy lehet az Online TFS alól projektet törölni? Mert hát ugye a sima TFS alól csak a developer consoleal lehet. Hátha van itt valami Webes csoda amivel törölhetnénk. Meg kell nyugtatnom mindenkit, nincs. (És szerintem jobb is így!) Ugyanúgy a tfsdeleteproject console alkalmazást kell használnunk erre a feladatra. Sőt ugyanúgy mint eddig, max annyi lesz a különbség, hogy Live ID (öhöm akarom mondani Microsoft Account) bejelentkezést kér tőlünk.
A parancs így néz ki:
tfsdeleteproject /collection:"https://regisztraciomneve.visualstudio.com/DefaultCollection/" "ProjectNeve"
Visual Studio Facebook Chat Integráció
A közösségi hálózat egy programozó számára is fontos lehet, gondolhatta ezt ennek az add-in-nak a fejlesztője. Írt egy Facebook chat alkalmazást a Visual Studio-hoz. Beépül a Studióba és munka közben beszélgethetünk ismerőseinkkel (a produktív munka jegyében 🙂 )
Letölthető a Visual Studio Gallery-ből: innen
UI-tól ne várjunk sokat, elégé összehányt, de működni működik.
Windows Phone System Tray – Az a bizonyos fehér szín
Szóval itt van ez a gyönyörű jószág: a Windows Phone. A WP8 sokat fejlődött elődjéhez képest, hisz itt már nagyszerű (haha) WinRT fut a mélyén. Igazából ezzel nincs is itt különösebb baj, igaz, hogy sok minden duplikálva van az API-ban, de hát ezen még az ember túllendül. Kezdek egy szabadidős projektemnek a végére érni, és ilyenkor jön az ellenőrzés. Ugyanis viszonylag szigorú feltételeknek kell megfelelni ahhoz, hogy az alkalmazás bekerüljön a Microsoft Store-ba. (Igaz, ha valami gagyit tölt fel az ember akkor az átmegy mert sok mindent nem lehet elrontani.) El is kezdtem tesztelni az alkalmazást. Első teszt az volt, hogy hogy is néz ki fehér háttérrel az alkalmazás, mert ugye ha elütnek a színek vagy kín van vele, akkor visszadobják az egészet. Na már most erről azt kell tudni, hogy ha a fejlesztő nem csak a beépített színeket és sablonokat akarja használni mert létrehozna valami egyedit akkor cseszheti. Na de sebaj, ez végül is egy követelmény, és teljesen jogos is, max a létjogosultságával lehet vitatkozni – szerintem.
De tértjünk a tárgyra!
Elkezdi az ember stílusozni az alkalmazást. Minden textblocknak vezérlőnek stílust készít, leszármaztatja stb. Eljut két fontos vezérlőig amivel megint csak baja lesz. Az egyik az ApplicationBar ami ugye nem silverlight kontrol (héé hát nem WinRT van?!), ezért se binding, se stílus, se routed eventje nincs. Írd be manuálisan amit akarsz, minden page-re külön. Jó-jó megcsinálom, bár a style-t pont erre találták ki, de ha nem hát nem. Sebaj beírtam, működik.
Jön a system tray. A system tray az alkalmazásunk felső résszén található, itt jelenik meg az óra, a hálózat, akku töltöttség és egyéb adatok. Hát ez se köthető nagyon, bár én megcsináltam, hogy legalább a ProcessIndicator szövege köthető legyen, mert hát mégis csak MVVM-et használ az ember. De jöttek a stílusok. Na mondom jó, hát úgy is csak néhány page-n kell a system tray-t használni. Be is írom neki, hogy mindenkép legyen fekete, és az előtér színe fehér.
Íme:
shell:SystemTray.IsVisible="True" shell:SystemTray.Opacity="0.7" shell:SystemTray.BackgroundColor="Black" shell:SystemTray.ForegroundColor="White"
Elindítom az alkalmazást és mit látnak szemeim:
Mi a szösz? Hogy-hogy fekete? De hát oda van írva, hogy White!
Na jó akkor teszteljünk! Kap egy sárga színt!
shell:SystemTray.IsVisible="True" shell:SystemTray.Opacity="0.7" shell:SystemTray.BackgroundColor="Black" shell:SystemTray.ForegroundColor="Yellow"
Vajon működni fog-e? Dobpergés! Működik!
Akkor, miért nem jó a fehér szín?
Próbáljuk meg, átszínezni kódból fehérre…. Bár az ember ilyenkor a fejét fogja, hogy akkor megint code-behind, vagy egyszerű dologhoz is hihetetlen workaroundok kellenek a ViewModel-be. Na de Code-behind!
SystemTray.SetForegroundColor(this, System.Windows.Media.Colors.White);
Láss csodát működik:
Tényleg megkérdezném a fejlesztőit, hogy ugyan mi baj van a fehér színnel, ha markup-ban akarom definiálni? Ha elakarom rontani fekete témával is eltudom…
WinRT hiányosságok – III. rész (DispatcherTimer)
Mai napra egy kis szépséget választottam a DispatcherTimer-t.
Megint csak a marketingesek álltal emlegetett “könnyű portolhatóság” témaköréhez kapcsolódóan:
Windows 8 Modern Style
public class DispatcherTimer
{
// …
public event EventHandler<object> Tick;
}
Windows Phone 8
public class DispatcherTimer
{
// …
public event EventHandler Tick;
}
Aki érti, eltudja képzelni, hogy ha ezt a DispatcherTimer-t használjuk, milyen “könnyű” lesz a portolás.
A tegnapi bejegyzéshez surex írt egy nagyon jó kommentet. Tanulságos:
“Január elején elhatároztuk h meglévő de még Marketplecen nem lévő WP7 alkalmazásunkat “átkattintjuk” WP8-ra és W8-ra. Utóbbinál feladtam a közös kódbázist ,mert annyira kevés közös volt bennük, hogy minden interface-t implementálhattam újra W8 -on… Szóval amíg nem próbáltam elhittem a Marketing bullshitet, hogy könnyű portolni WP8 és W8 közt, de a valóságtól ez nagyon messze van! Online course a mit hogyan fejlesszünk WP(-ra és W8-ral: https://www.microsoftvirtualacademy.com/training-courses/build-apps-for-both-windows-8-and-windows-phone-8 Érdemes megnézni, bár nem visz közelebb a célhoz!”
WinRT hiányosságok – II. rész (IValueConverter)
Szóval, mint írtam, felszeretném hívni a figyelmet néhány WinRT-s API hiányosságra, ami bosszantó lehet a fejlesztőnek. A mai témánk az IValueConverter.
Az IValueConverter interface a WPF-ben jelent meg, és az egyik leghasznosabb társnak bizonyult az idők folyamán. Ugyanis adataink nem mindig, úgy vagy olyan formán állnak a rendelkezésünkre mint ahogy azt mi szeretnénk.Gyakori scenario amikor a convertert egyszerűen csak szöveg formázására, használjuk.(Dátum, pénznem, telefonszám, pin kód stb) Például: Az adatbázisban a telefonszámok formázatlanul szerepelnek, viszont a felületen mi már egy szépen tagolt telefonszámot szeretnénk látni. De számos eset van még, ahol a converterk jól jönnek. Ez csak 1 eset a sokból.
Fórumokon nagyon hangzatos az, hogy a WinRT majd megváltja a világot, hisz a Windows Phone 8 és a Windows 8 azonos alapokra épül, és itt jön a kedvenc mondatom könnyű portolni Windows 8-as alkalmazást Windows Phone 8-ra. Nos aki ezt mondja az valószínűleg nem protolt még alkalmazást a két platform között. Bár igazat kell adni abban, hogy könnyebb, meg h vannak közös részek, de ennyi erővel a WP7 és WPF –es alkalmazásokra is igaz volt. (jó egy picit nagyobb költői túlzással)
Ezt az alábbi egyszerű példán keresztül is láthatjuk majd, hogy #if kell még a legegyszerűbb kódrészlethez is.
Csak az összehasonlítás kedvéért, íme a Windows 8 IValueConverter interface Convert metódusának törzse:
publicobject Convert(object value, Type targetType, object parameter, string language)
És íme a Windows Phone 8-as Convert metódusa:
publicobject Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
Mint látható, az utolsó paraméterben különbözik. A WP8 –nál CultureInfo van (és ez a jobb!), míg Windows 8-nál string language. (Érted string! 🙂 )
Hogy kéne ezt a problémát feloldani portolásnál? Itt jön a #if, azaz feltételes fordítással! (yeeah)
publicclassNumberConverter : IValueConverter
{
#if NETFX_CORE
public object Convert(object value, Type targetType, object parameter, string language)
#else
publicobject Convert(object value, Type targetType, object parameter, CultureInfo culture)
#endif
Mondjuk addig kevesebb a probléma, amíg nem érdekelnek a különböző kultúrák, hanem csak az angol vagy a magyar. Az igazi szépség akkor jön, amikor tényleg globális piacra több nyelvű alkalmazást akarunk írni. Valóban furának tűnhet, de akár hogy is de hordozható valamilyen szinten a kód. “Sajnos” (illetve annyira nem) se Andoridos, se iOS tapasztalatom nincs, hogy ott milyen a portolás, tehát lehet, hogy azokon a platformokon rosszabb. (nem tudom) Mindenesetre itt is vannak fura, dolgok. Ja és igen a Blue az érkezik, gőz erővel jön. De, ha ezt a paramétert javítják a következő változatban (már csak azért is, hogy még közelebb hozzák a két platformot), akkor pedig visszafelé nem lesz kompatibilisek az alkalmazások. (Gondolom ezt is megoldják, majd valahogy. Csak jelezném, hogy akkor ugyanott lesznek mint a Win32-vel.)
WinRT API hiányosságok – I. rész (Binding)
A történet onnan indul, hogy a Winmagazin oldalon posztoltam egy olyat, hogy szerintem az egész WinRT API egy ipari hulladék.
Konkrétan ezt írtam:
“Jó írás. Én is kidobnám a francba az egész Metro-t. 1 alkalmazást se használok róla. Egyszerűen rosszabb a minősége is, meg kényelmetlenebb is. Van Windows 8-as tabletem is, de kb semmi értelmet a Tablet módnak ezen a rendszeren. (Inkább vettem volna iPad-et) A metro api egy ipari hulladék, de tényleg. Bár aki fejlesztett WPF-re / Silvertlightra az gyorsan meg tudja tanulni. Igaz rengeteg korlát van benne, komoly alkalmazásokat (játékokon) kívűl nem érdemes / "lehet" benne írni. De mondjon valaki 1 jó Metros alkalmazást amit minden nap használ, és inkább azt használja mint a Windows-osat. Maga az OS nem volna olyan borzalmas. Viszonylag stabil, driverekkel sincs nagyon probléma (legalább is nekem) de ez a Metro (vagy ModernUI) egyszerűen siralmas szerintem.”
Egyszer csak megjelent a devportálon egy fórumbejegyzés, amely rám hivatkozva és idézve (háh idéznek tőlem! Ezt is megéltem!) a srác kirobbantott egy vitát. Nagyon sokan posztoltak erre, hogy miért rossz vagy épp miért jó a Windows 8 és a WinRT API. Bár én inkább API-ra gondoltam a kritika alatt nem pedig a rendszer hiányosságaira, de bevallom nagy részükkel egyetértek. (Kövezz meg MS! :)) Mondjuk ettől függetlenül a rendszerrel kevesebb bajom van mint a WinRT API-val.
A következő néhány írásomban egy-egy API beli hiányosságot fogok leírni. Félre értés ne essék, nem azért, hogy "leszóljam” a rendszert, azt megteszik helyettem mások – Ezt a devportálon írjátok meg, ha van ilyen. Ha szeretitek azt is – , hanem azért, hogy ha fejlesztő vagy és belefutsz ezekbe a hibákba, akkor ne érjen váratlanul, hogy Óóó a fene ez miért nem megy?!. Hisz WPF vagy SL alatt tökéletesen működött ez a kódsor.
Kezdjük el.
BINDING!
A binding azaz az adatkötés bátran kijelenthetjük, hogy a XAML alkalmazások alapja. Aki fejlesztett WPF-re vagy Silverlight-ra az ezzel tisztában van. Aki ráadásul “jól” fejlesztett és MVVM-et használt akkor pláne tudja, hogy létszükséglet. (Véleményem szerint, aki nem MVVM-be fejleszt WPF/SL/WP8/Windows 8 alá, az mélyen, nem ismeri a rendszer képességeit. – Ezért is meg lehet kövezni. Ez szubjektív vélemény.) Szóval itt van ez a rendszer és ott van a Binding. Az, hogy hiányos és gáz a Binding az egy dolog, de tegnap egyik kollégám (Mr. X) hívta fel erre az aprócska “hibára” figyelmemet.
Tegyük fel, hogy van egy tulajdonságot ami decimal típusú. Ez a ViewModel-ben van.
public class MainViewModel : INotifyPropertyChanged
{
private decimal price;
public decimal Price
{
get { return price; }
set {
price = value;
OnPropertyChanged("Price");
}
}
…
}
Ez a tulajdonság kötve van egy TextBox-hoz. A kötés kétirányú!
<TextBox Text="{Binding Price, Mode=TwoWay}"/>
Az ember ilyenkor azt várná, hogy ha megváltoztatja a TextBox tartalmát, akkor az a tulajdonság ami hozzá kötve van szintén meg fog változni. Ezért is kötés, ráadásul kétirányú. Cserébe viszont csak ezt a hibaüzenetet kapunk az output Window-ra:
Error: Cannot save value from target back to source. BindingExpression: Path=’Price’ DataItem=’App8.MainViewModel’; target element is ‘Windows.UI.Xaml.Controls.TextBox’ (Name=’null’); target property is ‘Text’ (type ‘String’).
Ugyanis ez a csodás API nem tud kötni kétirányúan se decimal, se byte típushoz. Igen, írd át a kódodat double-ra vagy épp int-re, mert a decimal az ööö hát az nincs támogatva. Hiába azt használjuk, pl. Árak reprezentálására, nem azt nem kötheted. Tehát, ha WinRT-t használtok és adatkötést szeretnétek nem biztos, hogy a decimal, és még néhány típus megfelelő lesz a számotokra.
Felhívnám még a figyelmet, hogy UpdateSourceTrigger-t se nagyon keressetek a kötésnél…
Persze ez csak 1 hiányosság a sok közül. Amibe belefutok, majd leírom még. Ha esetleg ti is belefutottatok hasonló szépségekbe, kérlek írjátok meg a kommentek között.
Konklúzióm:
Azt lehet mondani, hogy ez V1, meg hogy a Silverlight is milyen volt amikor kijött, és, hogy-hogy felfejlődött, de azt ne felejtsük el, hogy a Silverlight az Online platform volt! Plusz igen, valóban leváltja a WinRT az őskori Win32-t mert csudaúj és a Win32 hibáit itt nem követik el, de ahhoz jó alapok kellenek, és ez a változatt még nem az. A blue-val meg jön egy szép szerviz csomag. Ott arra leszek kíváncsi, hogy ezeket a hibákat, hogy javítják, mert bizonyos esetekben akkor nem lesz kompatibilisek a mostani alkalmazások az újjal. (Lásd Converterek és használatuk. Következő cikkben leírom)
Jó tudom, hogy API szintjén nem sok embert érdekel a WinRT, de azért a Windows 8-hoz ez is hozzá tartozik, és aki foglalkozik vele, belefuthat ebbe.
Microframework – Netduino
Az első bejegyzésem ebben a témában nem várt eredménnyel végződött. Ugyanis többen nézték, olvasták el mint az eddigi írásaimat. Ami 3 dolgot vethet fel bennem:
- 1 xarul írok (jó ez esélyes – De legalább is helytelenül)
- 2 A WP7-8 és a Windows 8 kevésbé érdekes mint a Microframework
- 3 Ööööö Nem emlékszem, de amikor elkezdtem írni még 3 volt.
Szóval elkezdtem ezzel a témával alapszinten foglalkozni. Főleg fejlesztési oldalról közelítem meg ezt a témakört.
De térjek a témára. Elkezdtem nézegetni az Add References ablakot. Rögtön szembetűnik, hogy elég szegényes. Az alap dolgok persze itt vannak, System, System.IO stb. Persze ott vannak a HW használó assemblyk is. Ezek a Microsoft.SPOT kezdetűek. Ezenkívül persze ott vannak még azok az assemblyk amiket a gyártótól kapunk.
Ebben az írásban nem a GHI-s termékről lesz szó, hanem egy jóval olcsóbb kis eszközről, ez pedig nem más mint a netduino plus. Ez csak 40$ környékén van. Ez egyfajta építsd magad szintű eszköz. Az alaplap kerül 40$-ba és ha az ember akar hozzá kamerát, hangszórót, azt külön meg kell vennie és rákötheti erre az eszközre. Persze itt is a kijelző az egyik legdrágább darab. Itt is elverheti az ember pénzét.
Chopper irt egy STM32F4DISCOVERY készülékről ami relative olcsó 4000 Ft. Ezt meg is rendeltem, ha megérkezik majd írok róla.
Szóval itt ez a kis lego, és hát itt már nem hello world-van hiszen kijelzője sincs. A változatosság kedvéért, hanem hello blink- van. Visual Studio-t elindítva, és egy új Microframeworkös consol alkalmazást elkészítve el is kezdhetjük a munkát. Adjuk hozzá a Neduino-s referenciákat az Add References menüpont alatt. Nincs túl sok, úgyhogy nem lehet eltéveszteni:
|
publicstaticvoid Main() |
Szóval kezdjük az elején:
A Debug.Print metódussal tudunk a Visual Studio output windowjára írni. Nincs Debug.Write* WriteLine * WriteLineIf vagy épp Assert. Kb csak ennyi van, ezzel gazdálkodjunk. Hibakeresés szempontjából jól fog nagyon jönni, ezért is hagytam benne ezt a kódot. Amúgy van Breakpoint (mágyárul Brékpont), de nem mindig úgy viselkedik ahogy elvárnám. De van és ez a lényeg.
Mivel most egy Led-et szeretnék megszólítani, ehhez szükségem lesz egy OutputPort objektumra. Itt meghatározhatom, hogy melyik pin “voltage level”-jét (Mi ennek a szép magyar neve? – Volt szintje? Feszültség szint?) szeretném megváltoztatni. Az első paraméter az a pin amit módosítani szeretnék ebben az esetben az alaplapi LED. A második paraméterrel a kezdeti állapotot határozhatjuk meg, ami jelen esetben false. Azaz nem fog világítani a LED.
A következőekben egy for ciklusban (ami 15x ismétlődik) ki be kapcsolgatom a LED-et. Azért, hogy ne tünjön el azonnal egy Sleep-et is belerakok. És igen jól látjátok van Thread.Sleep és ugyanúgy működik mint bármelyik más .NET es környezetben. Igaz itt meg is áll a tudomány mert statikusan kb csak a Sleep meg egy GetDomain metódusa van. Van még egy CurrentThread tulajdonsága. A led Write metódusával tudjuk ki-be kapcsolni a LED-et.
Na de haladjunk picit tovább, és nézzük meg az input kezelést is. A Netduino ilyen téren nem sokat add, hiszen az alaplapon csak egy gomb van, az is a megszakításra. De mi most ezt szeretnénk felhasználni. Ehhez egy InputPort osztályra lesz szükségünk. Ezt példányosítva, meghatározhatjuk, hogy melyik Pint-t szeretnénk figyelni, ami jelen esetben az ONBOARD_SW1. A Pins- enumerációt a SecretLabs.NETMF.Hardware.NetduinoPlus névtér alatt találjuk. A glitchfiltert false-ra a ResistorMode-ot pedig Disabled-re állitsuk.
A végtelen while ciklusban az inputport példány Read metódusát hívjuk meg. Ennek visszatérési értéke egy boolean érték. Na most ennek az értéke érdekes. A régi firmwaren ez false, ha le van nyomva, true ha nincs, az újon pedig fordítva. Szóval nézze meg mindenki, hogy melyiket használja.
|
publicstaticvoid Main() |
A lényeg, hogy boolean értékel tér vissza és ezt adjuk át a led Write metódusának.
Turóczy Attila szakmai blogja 