Kashiash's Blog

o programowaniu inaczej : jak zrobić i się nie narobić

Archive for the ‘Clarion’ Category

Sprawdzanie poprawności wprowadzonych danych

Posted by kashiash w dniu 6 lutego, 2011

Clarion posiada możliwość deklaracji kontroli poprawności danych

Na zakładce Validate Fields możemy wybrać kilka opcji. MOBY korzysta z niektórych z nich:

MUST BE IN TABLE – oznacza ze wartość z tej kolumny musi znajdować się w tabeli w relacji. MOBY pilnuje zaraz po wprowadzeniu wartości czy jest poprawna

CANNOT BE ZERO OR BLANK – w polu musi być cokolwiek wpisane

MUST BE IN RANGE – wartość musi znajdować się w wartościach podanych w tej opcji

Dodatkowo można wypełnić opcje VALIDATE i wpisać w niej wyrażenie logiczne zgodne z syntaktyka języka JAVA, które musi być spełnione, aby można było zapisać dane.

Posted in Android, Clarion, MOBY | Leave a Comment »

Ewidencja pojazdów: Policzmy to i owo ;)

Posted by kashiash w dniu 6 lutego, 2011

Standardowo clarion ma cos takiego jak Formuły, gdzie możesz zdecydować co ma być liczone , jak i kiedy. Niestety zrobienie tego w DCT jest dużo trudniejsze. Uważam, że nie należy robić nic na siłę. Moby I pozwala jedynie na określenie formuł wypełniających poszczególne pola, jakieś specyficzne wyliczenia trzeba zakodować ręcznie. Uspokajam – MOBY II będzie pozwalał na definiowanie formuł w sposób podobny do clarion’a.

Prosta aplikacja, którą próbujemy tu zrobić ma rejestr pojazdów oraz rejestr ich tankowania. Podczas tankowania użytkownik będzie wpisywał stan licznika z momentu tankowania. Możemy ta informacje wpisywać do pola odometer w naszych pojazdach, przez co będą aktualizowane automatycznie.

Jak to zrobić ?

Prostym zapytaniem SQL jesteśmy w stanie pobrać najwyższa wartość stanu licznika dla wybranego pojazdu. Poniżej przypominam strukturę bazy danych.

Pytamy o maksymalna wartość licznika w logu, np. tak :

Select max(EndingOdometer) from FuelLog where Vehicle = 1

Operacje wykonujemy na oknie VehiclesEdit, gdzie id naszego pojazdu możemy pobrać z obiektu reprezentującego rekord z tabeli Vehicles:

Możemy się do niego dostać używając metody getId :


VehiclesRecord.getId()

Czyli nasze zapytanie bedzie wyglądalo tak :

„Select max(EndingOdometer) from FuelLog where Vehicle = ” + VehiclesRecord.getId()

a takie zapytanie wywołamy w następujący sposób:

VehiclesxDbAdapter.getInstance().getQueryScalarLong(„Select max(EndingOdometer) from FuelLog where Vehicle = ” + VehiclesRecord.getId());

aby wpisywalo sie do naszego pola należy wpisać w opcjach pola EndingOdometer EVALUATE oraz EVALUATECONDITION.

EVALUATE(VehiclesxDbAdapter.getInstance().getQueryScalarLong(„Select max(EndingOdometer) from FuelLog where Vehicle = ” + VehiclesRecord.getId()))

EVALUATECONDITION( VehiclesRecord.getId() != null)

Dzięki tym opcjom MOBY wygeneruje kod który pod warunkiem spełnienia warunku w EVALUATECONDITION wpisze wynik z EVALUETE do pola EndingOdometer


public
void DoLookups() {


if (VehiclesRecord.getId() != null) {


VehiclesRecord.setOdmoter(VehiclesxDbAdapter.getInstance().getQueryScalarLong(„Select max(EndingOdometer) from FuelLog where Vehicle = „ + VehiclesRecord.getId()));


// Vehicles Veh:Odmoter


if ( VehiclesRecord.getOdmoter() != null) {


mOdmoterText.setText(VehiclesRecord.getOdmoter().toString());

}

}

}

Uruchamiamy aplikację, wybieramy pojazd, wchodzimy do jego edycji i robimy wpis do logu tankowania, wracamy na dane i pojazdu i …? cieszymy się jak nasz log się aktualizuje.

Skoro poznaliśmy kolejną, istotną możliwość MOBY, wykorzystajmy ja dalej: w logu tankowania przydałoby się, aby stan licznika poprzedniego tankowania był automatycznie podpowiadany, przy okazji niech, jako licznik kończący wpisze się ta sama wartość i oczywiście wyliczy się różnice przejechanych kilometrów.

Robimy to bardzo podobnie jak wcześniej, zmieniamy tylko klauzulę where – mamy wyszukać maksymalna wartość z licznika dla wpisów wcześniejszych niż edytowany. W EVALUATE wpiszemy wyrażenie wyliczające maksymalny licznik z wcześniej wpisanej pozycji

FuelLogxDbAdapter.getInstance().getQueryScalarLong(„Select max(EndingOdometer) from FuelLog where Vehicle = ” + FuelLogRecord.getVehicle() + ” and _id < ” + FuelLogRecord.getId())


Dzięki temu pole StartingOdometer będzie automatycznie uzupełniane.

W kolejnym kroku wprowadzimy wypełnianie EndingOdometer w sytuacji gdy jest puste. Dodatkowo włączymy opcje SPINNABLE, co spowoduje ze MOBY doda 2 przyciski, które pozwalają zwiększać lub zmniejszać wartość tego pola.


UPDATECONTROLS powoduje ze po aktualizacji tego pola pozostałe są ponownie wyliczane, i pole OdometerChange zostanie przeliczone wg zadeklarowanego wyrażenia w EVALUATE.


Wchodzimy do edycji pojazdu, jak widacz licznik jest 6809


Teraz dopisujemy tankowanie, podpowiada nam się Starting i Ending Odometer, zmieniając wartość w Ending Odometer, automatycznie wylicza nam się OdometerChange


Po zapisaniu informacji o tankowaniu w pojeździe automatycznie zaktualizuje nam się Licznik bieżacy



Posted in Android, Clarion, MOBY | Leave a Comment »

Ewidencja pojazdów – dopieszczanie interfejsu

Posted by kashiash w dniu 5 lutego, 2011

O atrakcyjności aplikacji decyduje wygląd interfejsu. Niestety interfejs androida nie jest „sexy” i np. odbiega od tego co oferuje iPhone czy aplikacje robione w Adobe Air/Flex. Bolączką wielu programistów, niestety także autora tego tekstu jest brak smykałki do dopracowywania wyglądu interfejsu. Na szczęście Moby dostarcza kilka predefiniowanych szablonów wyglądu list danych. Oto opis jak ich używać.

Dla każdej tabeli możemy zdefiniować layout alternatywny. Najprostszy z nich to Layout 3 zawierający linijke tekstu oraz ikonkę pozwalającą wyświetlać ikonkę, która zależy od zawartości rekordu listy.

Układ graficzny nr 3

LeftIconField

UpTextField

RightIconField

LoTextField

Aby uzyskać taki wygląd należy w FileUserOptions dodać opcje typu Number o nazwie ALTROWLAYOUT i wpisać jej wartość 3

Oraz określić, jakie pole ma być wyświetlane w UpTextField w przypadku tabeli Dostawców paliwa wybieramy pole Brand, co oznacza , że w polu górnym widoku ma być wyświetlona wartość kolumny Brand z tabeli którą edytujemy czyli w tym przypadku Brands.

Dodatkowo określamy jak ikonka powinna być wyświetlona w LeftIconField podajemy wyrażenie zgodne ze składnia języka JAVA, którego wynik daje nazwę ikonki.

Podobnie robimy w tabeli Makes

Oraz w tabeli Models

Wykaz ikonek potrzebnych dla naszej aplikacji – zawartośc katalogu res\drawables

Układ graficzny nr 3 wersja rozbudowana

Aby pokazac układ bardziej rozbudowany, zmodyfikujemy nieco tabelę z dostawcami paliwa – dodamy pole z informacja czy akceptują karte paliwowa UTA

W ten sposób definiujemy pole typu CHECKBOX

Generujemy aplikację. W związku z tym, że zmieniła nam się struktura bazy, modyfikujemy numer wersji bazy danych. Dzięki tej informacji MOBY wygeneruje procedurę do konwersji z poprzedniej wersji, na wersje bieżącą.

Ustawiamy dodatkowe opcje jak poniżej:

Dodajemy opcje związane z informacja o prawej ikonce

RightIconField(„uta” + BrandsxDbAdapter.getAcceptUTACards(c))

Do projektu wgrywamy ikonkę uta1.png

Układ graficzny własny … tzn. ręcznie dziergany

Zmieniamy vehicles_list.xml na:

<?xml version=”1.0″ encoding=”utf-8″?>

<RelativeLayout xmlns:android=”http://schemas.android.com/apk/res/android&#8221;

android:id=”@+id/RelativeLayout01″

android:layout_height=”wrap_content”

android:layout_width=”fill_parent”>

 

<ImageView android:layout_width=”wrap_content”

android:layout_height=”wrap_content”

android:id=”@+id/lefticon”

android:visibility=”gone”></ImageView>

 

 

<TextView

android:layout_width=”wrap_content”

android:text=”TextView”

android:padding=”5dp”

android:textAppearance=”?android:attr/textAppearanceMedium”

android:layout_height=”wrap_content”

android:id=”@+id/model”

android:layout_toRightOf=”@+id/lefticon”

android:layout_alignTop=”@+id/lefticon”

android:layout_alignBottom=”@+id/lefticon”>

</TextView>

 

<TextView

android:layout_width=”wrap_content”

android:text=”TextView”

android:textAppearance=”?android:attr/textAppearanceMedium”

android:layout_height=”wrap_content”

android:id=”@+id/odmoter”

android:padding=”5dp”

android:layout_alignParentRight=”true”>

</TextView>

<TextView

android:layout_width=”wrap_content”

android:text=”TextView”

android:padding=”5dp”

android:textAppearance=”?android:attr/textAppearanceMedium”

android:layout_height=”wrap_content”

android:id=”@+id/plateno”

android:layout_centerInParent=”true”

></TextView>

 

</RelativeLayout>

W VehiclesList.java odszukujemy procedure VehiclesHolder

I zmieniamy, aby wyglądała jak poniżej

static class VehiclesHolder {

 

private TextView Odmoter = null;

private TextView Model = null;

private TextView PlateNo = null;

private ImageView LeftIcon=null; //manual

private View row=null;

VehiclesHolder(View row) {

this.row=row;

 

LeftIcon=(ImageView)row.findViewById(R.id.lefticon);

Odmoter=(TextView)row.findViewById(R.id.odmoter);

Model=(TextView)row.findViewById(R.id.model);

PlateNo=(TextView)row.findViewById(R.id.plateno);

 

}

 

void populateFrom(Cursor c) {

if (VehiclesxDbAdapter.getOdmoter(c) != null) {

Odmoter.setText(VehiclesxDbAdapter.getOdmoter(c).toString());

}

if (VehiclesxDbAdapter.getModel(c) != null) {

Model.setText(VehiclesxDbAdapter.getModel(c).toString());

}

if (VehiclesxDbAdapter.getPlateNo(c) != null) {

PlateNo.setText(VehiclesxDbAdapter.getPlateNo(c));

}

int resId;

try {

resId = R.drawable.class.getDeclaredField(„makes” + VehiclesxDbAdapter.getMake(c).toLowerCase()).getInt(null);

LeftIcon.setImageResource(resId);

LeftIcon.setVisibility(View.VISIBLE);

} catch (Exception e) {

Log.d(TAG,”ikona:” + „makes” + VehiclesxDbAdapter.getMake(c).toLowerCase());

LeftIcon.setVisibility(View.INVISIBLE);

}

}

}

Oczywiście podczas kolejnego generowaniaclarion nadpisze nam nasze zmiany. Aby temu zapobiec, zabronimy generowanie kodu listy oraz layoutu wiersza listy

FreezeListLayout(true) oraz FreezeList(true)

Posted in Android, Clarion, MOBY | Leave a Comment »

Ewidencja pojazdów – nowe tabele

Posted by kashiash w dniu 29 stycznia, 2011

Skoro ma być to ewidencja pojazdów to przydałoby się w niej przechowywać informację o wydatkach z tym pojazdem związanych.

W tym celu dodamy FuelLog oraz 2 tabele słownikowe na koncern paliwowy i rodzaj paliwa :

FuelLog
PkFuelLog KEY(Ful:Id),DUP,NOCASE
KeyVehicle KEY(Ful:Vehicle),DUP,NOCASE
KeyBrand KEY(Ful:Brand),DUP,NOCASE
KeyFuelType KEY(Ful:FuelType),DUP,NOCASE
Kolumny
Id LONG
Vehicle LONG
FillUpDate DATE
Quantity REAL
TotalCost REAL
Notes STRING(100)
StartingOdometer LONG
EndingOdometer LONG
OdometerChange LONG
Brand LONG
FuelType LONG
Brands
PkBrands KEY(Bra:Id),DUP,NOCASE
KeyBrand KEY(Bra:Brand),DUP,NOCASE
Kolumny
Id LONG
Brand STRING(51)
FuelTypes
PkFuelTypes KEY(Fty:Id),DUP,NOCASE
KeyFuelType KEY(Fty:FuelTypes),DUP,NOCASE
Kolumny
Id LONG
FuelTypes STRING(50)

Do tego określimy relacje pomiędzy tabelami :

FuelTypes <->> FuelLog

Vehicles <->> FuelLog

Brands <->> FuelLog

I W tabeli w zakładkach Validate check ustawimy odpowiednio wpisy w must be in file dla poł Vehicle, Brand i FuelType

Ustawiamy dla nich UseSpinner i DSP dla wyżej wspomnianych kolumn

 

W efekcie końcowym dostaniemy strukturę bazy jak poniżej:

Zapisujemy i generujemy kod naszej aplikacji.

Doszły nam 3 nowe tabele i potrzebujemy dla nich ikonek. Bez nich nie uda nam się uruchomić aplikacji.

Potrzebujemy brands.png, fuelstypes.png oraz fuellog.png, które należy wgrać do katalogu res/drawables.

Uruchamiamy nasza aplikację i naszym oczom powinien pojawić się następujący widok:

Jak widać zaczyna nam brakować miejsca, w pewnym stopniu pomogłoby zmniejszenie ikon z 48×48 na mniejsze, albo nie pokazywanie wszystkich tych przycisków na głównym menu aplikacji. Tym tematem zajmiemy się później, teraz popatrzmy co nam wyszło ;).

Ewidentnie mamy problem z miejscem, ale mamy w końcu nieocenionego MOBY!

W File User Options ustawiamy PromptsInLine(true) po przegenrowaniu:

To samo możemy ustawić na Vehicles : PromptsInLine(true).

W obecnej wersji aby wejść do listy z zakupami mieliśmy 2 możliwości: albo wchodzimy prosto z menu, albo z pojazdu poprzez przycisk menu.

Jeśli ustawimy UseTabHost(true) w FileUserOptions dla Vehicles, to program wygeneruje kod tak, że lista będzie widziana także na osobnej zakładce w oknie edycji pojazdu



W kolejnych krokach popracujemy nad listą danych wyswietlanych w pojazdach i logu tankowań, na razie pobawcie się nowa aplikacją androidową

Dlaczego to nie chce mi się skompilować ?

Jeśli otrzymujemy komunikat ze nasz projekt zawiera błędy i nie możemy go uruchomić zaglądamy na zakładkę PROBLEMS

poniżej przykład komunikatu na który pomaga wyczyszczenie projektu

Walkę ze wszystkimi problemami proponuje zaczynać od operacji wyczyszczenia projektu:

wybieramy Project/Clean i obserwujemy, co się wyświetla na zakładce Problems

komunikat najbardziej prawdopodobny w aplikacja wygenerowanej przez MOBY – brakuje nam ikonek.

Wgrywamy o wymaganej nazwie do katalogu res/drawables i powinno być po sprawie

Posted in Android, Clarion, MOBY | Leave a Comment »

Opcja dzwonienia na numer z kontrolki Text Edit : PhoneButton Option

Posted by kashiash w dniu 20 stycznia, 2011

Dodaliśmy w MOBY możliwość dodania przycisku do dzwonienia na numer wpisany w polu. Wystarczy w UserOptions dodać PhoneButton (True)

Dzięki temu wpisowi generator w kodzie doda taki wpis:

[java]

mTelefonText = (EditText) findViewById(R.id.autologTelefon);

Button CallPhoneTelefon = (Button)findViewById(R.id.CallPhoneTelefon );

CallPhoneTelefon.setOnClickListener(new OnClickListener(){

public
void onClick(View arg1){

String toDial=„tel:”+mTelefonText.getText().toString();

if (toDial.length()>4) {

startActivity(new Intent(Intent.ACTION_DIAL,Uri.parse(toDial)));

}

}

});

[/java]

Co w efekcie da nam w aplikacji:


I po naciśnięciu przycisku ze słuchawką


Posted in Android, Clarion, MOBY | Leave a Comment »

Piękny kod …? To programowanie czy wybory miss ?

Posted by kashiash w dniu 28 listopada, 2010

Wcześniej napisałem o pisaniu kodu na skróty, ale nie określiłem co jest na skróty a co nie jest … Warto to mieć gdzieś spisane i dostępne pod ręką , unika się wtedy analizowanie czy „skrót”, który chce zastosować to już skrót czy może  optymalna metoda zakodowania tego co własnie robimy.

Z tych najbardziej popularnych to :

– nie należy używać instrukcji „goto” – co ciekawe prawie każdy język ja ma … ciekawe dlaczego ? Wytłumaczeń jest kilka, ale najbardziej istotne jest to że kod z takimi kwiatkami jest mało czytelny i trudno go użyć bez większych modyfikacji w innym miejscu programu.

– nie należy używać zmiennych globalnych.  Dane można przekazywać jako parametry w funkcjach i procedurach

– zakres dostępności zmiennych powinien być jak najmniejszy. W przypadku pogańskich języków programowania zmienne można deklarować bezpośrednio przed użyciem, clarion (z małymi wyjątkami) zmusza do deklarowania zmiennych w sekcji przeznaczonej na deklaracje, ale zmienna używana w routine powinna być dostępna tylko w routine, jeśli w procedurze deklarujemy wewnętrzne procedury to ich zmienne powinny być tez dostępne tylko w podprocedurach. Dla kilku procedur wspólna zmienna  możemy zdefiniować w module grupującym te procedury. Globalne kolejki mają tendencje do wysypywania aplikacji (jest pewien problem ze współdzieleniem takich kolejek w wielu wątkach)

– stosuj wcięcia w kodzie. Kod odpowiedzialny za różne funkcjonalności rozdzielaj pustymi wierszami. Zdecydowanie poprawia to czytelność.

– kod powinien sam się dokumentować! Jeśli procedury i funkcje ponazywasz tak, że nazwa mówi do czego służy to analiza takiego kodu będzie dużo prostsza. Przy właściwym podejściu do tematu dodatkowe komentarze będą prawie zbędne, oczywiście bez utraty czytelności i łatwości analizy intencji programisty.

– unikaj zagnieżdżeń kodu, LOOP z CASE/IF/LOOP  w środku jest jeszcze ok, ale kolejny wewnętrzny LOOP  powinien być już zakodowany jako osobna funkcja/procedura.  Jeśli trzeba przekazać sporo parametrów do takiej procedury, może warto te zmienne zgrupować w jakimś obiekcie i przekazywać pojedynczy obiekt zamiast kilkunastu parametrów ?

– funkcje powinny być krótkie, kiedys istniała dobra praktyka nie przekraczania wielkości ekranu, czyli jeśli kod funkcji nie mieścił się na ekranie bez przewijania to kwalifikował się do podzielenia. Warto tez przypomniec sobie, jakie wówczas były ekrany: 24*80 znaków. Obecnie ekrany są większe i mieszczą więcej kodu, jednak stopień percepcji programujących raczej się nie poprawił.

– w przypadku klas i obiektów interfejs komunikacji z nimi powinien być jak najwęższy, czyli cechy czynimy prywatnymi, dajemy możliwość ich modyfikacji tylko przez gettery i settery, a jeszcze lepiej (jeśli obiekt po utworzeniu nie będzie modyfikowany) jedynie przez konstruktor. Hermetyzacja rządzi ;).

– od kilku lat zwalczam w sobie wypełniania embeds kodem dłuższym niż 2 linijowym. Użycie takiego kodu w innym miejscu jest uciążliwe i prowadzi do wielokrotnego powtarzania fragmentów kodu w wielu miejscach programu.  Zły przykład daje sam clarion, który wkleja spore fragmenty kodu w każdej z procedur, ale robi to z szablonów i nie ma problemów z wielokrotnym używaniem tej samej funkcjonalności w wielu miejscach i zwykle nie jesteśmy zmuszani do analizowania kodu wygenerowanego. Nie należy się sugerować tym co robi clarion, tylko zwracać na wybitnie długaśne fragmenty kodu własnego autorstwa.

Ciąg dalszy nastąpi …

Posted in Clarion, Dobre praktyki | 4 Komentarze »

Zjazd Użytkowników Clarion w lesie pod Warszawą

Posted by kashiash w dniu 20 listopada, 2010

AGENDA

Sobota
10:00 – 11:00 Praktyczne użycie Codejock Calendar na przykładzie planowania zabiegów rehabilitacyjnych 

Prezentacja ilustrująca sposób zintegrowania komponentu Codejock Calendar Pro ActiveX z aplikacją bazującą na zastosowaniu terminarza. Demonstracja parametryzowania kontrolki w runtime’ie bez potrzeby wybierania różnych opcji.

Grzegorz Siwiec
11:00 – 12:45 Clarion i Android … to możliwe 

Android zdobywa coraz większą popularność. Programy na tę platformę można tworzyć za pomocą Clarion i wymieniać dane ze standardowymi aplikacjami.

Jacek Kosiński
12:45 – 13:00 Clarion i Android … perspektywy 

Perspektywy rozwoju projektu związanego z programowaniem aplikacji Android w Clarion

Grzegorz Fałda
13:00 – 13:45 Tworzenie dynamicznych raportów w oparciu o SQL, InMemory Driver oraz Dynamic File Driver
Demonstracja możliwości generowania i przeglądania zestawów danych o strukturze definiowanej dynamicznie przez użytkownika. Rozwiązanie bazujące na wykorzystaniu silnika SQL oraz driverów SoftVelocity.
Andrzej Skolniak
13:45 – 14:30 iQXML … 

XML to dzisiaj podstawowy format do wymiany danych pomiędzy różnymi systemami. Ale nie tylko – można go np. wykorzystać do aktualizacji tabel słownikowych. Dzięki darmowej bibliotece iQXML zabawa z tym formatem staje się lekka, łatwa i przyjemna.

Marek Otremba
14:30 – 15:30 Przerwa obiadowa
15:30 – 16:15 Programowanie urządzeń z Windows Mobile w Clarion.NET 

Clarion.NET jest jeszcze w wersji beta. Nie ma jeszcze do niego szablonów. Ale już teraz umożliwia programowanie aplikacji dla platformy Windows Mobile i stanowi ciekawą alternatywę dla np. VisualStudio.

Darek Boncler
16:15 – 17:00 NetTalk – narzędzie „wszystkomające” 

NetTalk w roli szpiega. Pokażemy, jak aplikacja uzbrojona w tę bibliotekę może przekazywać informacje statystyczne, czy też chronić licencje producenta.

Grzegorz Siwiec
17:00 – 17:30 Migracja danych z TPS do SQL 

Coś dla tych, którzy planują dokonanie migracji swoich danych z formatu TPS do jednego z motorów SQL. Prezentacja wspomagania tej operacji przez zastosowanie Data Management Center. [Uwaga! Prezentacja zdalna w języku angielskim]

Jean-Pierre Gutsatz
Niedziela
10:00 – 11:30 Instalowanie i konfigurowanie SVN i Tortoise – system kontroli wersji w Clarion 

Co to jest? Dlaczego warto stosować. Pokaz instalacji i konfiguracji oraz działania systemu.

Jacek Kosiński
11:30 – 12:15 Nowoczesny interfejs aplikacji bazujący na szablonach Noyantis i kontrolkach ActiveX Codejock Software 

Interfejs aplikacji zbudowanych w Clarion jest dosyć zgrzebny. By taki nie był, trzeba włożyć w to sporo wysiłku albo …. wykorzystać kontrolki ActiveX.

Darek Boncler
12:15 – 15:00 Programowanie aplikacji Web w oparciu o Capesoft NetTalk  

Zasady budowy serwerów aplikacji w oparciu o NetTalk WebServer. Podobieństwa i różnice w stosunku do standardowych aplikacji Clarion. Techniki zaawansowane: WebServices, multihosting itp.

Jacek Kosiński
15:00 – 16:00 Podsumowanie. Losowanie nagród. 

Zakończenie Zjazdu

Obiecałem ze udostępnię materiały z konferencji, co niniejszym czynię:

prezentacja służąca mi jako podpowiadaczka o czym mam mówić

Android i Clarion

dct w clarionie i wygenerowana aplikacja w JAVA
Dct2AndroidApps_USUN_PDF_NAKOŃCU.zip

Prezentacje Grzegorza … niedługo

Prezentacja jak z Dct powstaje app do androida

Przymiarki do aplikacji androidowej definiowanej w app:

 

 

 

Posted in Clarion | Leave a Comment »

Google Maps i Clarion

Posted by kashiash w dniu 24 lipca, 2010

Skoro mamy własna przeglądarkę to poogladajmy sobie w niej mapy z googlemaps.
Najpierw te prostsze statyczne np do pokazania lokalizacji wybranych współrzednych lub do pokazania mapy o podanym adresie.

Dokumnatacj na google jest tutaj:
http://code.google.com/intl/pl-PL/apis/maps/documentation/staticmaps/#Zoomlevels

w skrócie wystarczy spreparować odpowiedni link i sprawa z głowy 😉
np
http://maps.google.com/maps/api/staticmap?center=40.714728,-73.998672&zoom=12&size=400×400&maptype=satellite&sensor=true_or_false

http://maps.google.com/maps/api/staticmap?center=40.714728,-73.998672&zoom=12&size=400×400&maptype=hybrid&sensor=true_or_false

http://maps.google.com/maps/api/staticmap?center=40.714728,-73.998672&zoom=12&size=400×400&maptype=roadmap&sensor=true_or_false

 http://maps.google.com/maps/api/staticmap?center=40.714728,-73.998672&zoom=12&size=400×400&maptype=terrain&sensor=true_or_false

lub z podaniem jawnym adresu:

http://maps.google.com/maps/api/staticmap?center=Brooklyn+Bridge,New+York,NY&zoom=14&size=512×512&maptype=roadmap
&markers=color:blue|label:S|40.702147,-74.015794&markers=color:green|label:G|40.711614,-74.012318
&markers=color:red|color:red|label:C|40.718217,-73.998284&sensor=false

ekran z programu

i jeszcze w wyszukiwaniu przez adres

Kod żródlowy i sam program (plik spakowany w formacie ZIP – usunąć .PDF na końcu)

Wersja z małym bajerem, wersja stayczna z przeijaniem ;). Kod żrodlowy poniżej

DOWNLOAD HERE! – Kod zródlowy do wersji gdzie widać ze mi sie nudzi 😉

Posted in Clarion, Google Apps, kurs clariona | Leave a Comment »

Pojawił się Clarion 7.2

Posted by kashiash w dniu 24 lipca, 2010

Tak naprawdę już ponad miesiąc temu miałem go w rękach. Niestety uzywam wielu bibliotek dodatkowych i nie miałem każdej kompatybilnej z nowym clarionem. Przedwczoraj dostałem ostatnia brakującą i połowa wczorajszego dnia zajęta była instalowaniem. Problem nie jest z Clarionem, tylko ze mną. okazało sie, że pomimo posiadanej zbiorczej listy szablonów do niektórych kody aktywacyjne są nieaktyalne lub po prostu z lenistwa ich nie wpisałem. Wiekszośc czasu zajęło mi przeszukiwanie inboxa w poczcie prywatnej oraz w firmowej w celu wyszukania potrzebnych informacji. W końcu mam działającego nowego clariona (o tym co nowe napisze w kolejnym wpisie). Z poprzedniego dnia wyciągnałem nastepujace wnioski.

lista z kodami aktywacyjnymi powinna być aktualna (wczoraj ja zaktualizowałem)
powinna też mieć linki skąd pobrać najnowszą wersję
wszystko co skompletujemy do instalacji należy zarchiwizować i trzymać w bezpiecznym miejscu
w przypadku pojawiania sie aktualizacji bibliotek lista i katalog programów instalacyjnych powinny być aktualizowane na bieżaco
wtedy zamiast stracić pół dnia, wystarczy pół godziny

Posted in Clarion, Dobre praktyki | Leave a Comment »

Dobre nawyki programisty – funkcje

Posted by kashiash w dniu 1 czerwca, 2010

1. Nadmiar argumentów
Funkcje powinny mieć jak najmniej argumentów, najlepiej wcale. W przypadku clariona jest to o tyle możliwe że argumentami funkcji mogą być dane z bieżącego rekordu które dostępne są w całym wątku dla wszystkich procedur. Jeśli argumentów jest wiecej niz 3 warto pomyśleć o stworzeniu obiektu który ma kilka cech i jako parametr przekazywać taki obiekt.
2. Argumenty Wejściowo-Wyjściowe przekazywane zwrotnie przez wskaźnik w clarionie
Nigdy ich nie lubiłem, nie były dla mnie intuicyjne i dość ciężko analizuje się taki kod – jeśli funkcja ma zwracać wiele wyników ..niech zwraca obiekt lub typ złożony (dla nie lubiących OOP)
3. Stare/martwe funkcje
Jeśli funkcja nie jest używana powinna być usunięta z systemu. Podobnie jeśli jest backupem po jej modyfikacji

Posted in Clarion, Dobre praktyki | Otagowane: , , , | Leave a Comment »