Az abszolút enkóderekkel ellentétben az inkrementális enkóderek nem képesek megadni a forgás pillanatnyi helyét, segítségükkel csak azt lehet meghatározni, hogy történt-e forgás valamelyik irányba. Viszont jelentősen olcsóbbak, és kevesebb lábat foglalnak el a mikrokontrolleren. Ez sem utolsó szempont, tekintve hogy pár óra kínlódás után rájöttem, hogy a kontrolleremen két láb halott..

Általában véve a forgási enkóderek működését a Wikipedia vonatkozó cikke jobban elmagyarázza, mint én tudnám, így erre nem térek ki részletesen. A lényeg csupán annyi, hogy egy egységnyi forgás alatt két kapcsoló zár az enkóderben egymás után, a forgás irányától függően. Ennek tipikus bekötése active-low jelleggel rendkívűl egyszerű, az enkóder C csatlakozója ráköthető a földre, az A és B lábak számára pedig kiválasztunk két portot a kontrolleren, az én esetemben ez RB6 és RB7 lett. Ezen kívül semmilyen más alkatrészre nincs szükség, hiszen a Pic16F690-es processzor integráltan tartalmaz felhúzó áramkört, ami képes magas szinten tartani az adott portot, és leföldelés esetén biztonságos szinten tartja az áramot.

A feladat tehát a következő: detektálni kell az enkóder kapcsolóinak a zárását, figyelembe véve a sorrendjüket, és ennek megfelelően kell egy változó értékét növelni, vagy csökkenteni. Ha az A kapcsoló zár előbb, és később a B, akkor növelni, ha fordítva akkor csökkenteni kell eggyel a változót. Az általam használt EC12E típusú enkóder 24 diszkrét egységre bont egy kört, azaz 15 fokonként képes érzékelni a forgást, tehát a változó értékét 15-el megszorozva megkapjuk a pontos forgást. Az enkóder mechanikus jellege miatt a használat közben számítani kell pergés előfordulására, aminek a kezeléséről gondoskodni kell.

A mikroprogram gyors időközönként leolvassa a kapcsolók állását, és ez alapján kell eldöntenie, hogy merre forgatjuk az enkóder karját. Mivel figyelembe kell venni a kapcsolók korábbi állapotát is, triviálisan adja magát egy állapotgép-alapú megoldás, ami a pergést úgy küszöböli ki, hogy megengedi az állapotok közötti oda-vissza ugrálást a pergést követve, a pergés stabilizálódásával pedig az állapot is a megfelelő értéken rögzül.

Az állapotgép bemenete a két kapcsoló állása és minden leolvasáskor végrehajt egy lépést:

Az állapotgép megfelelő élei biztosítják, hogy amíg valamelyik kapcsoló pereg, addig a megfelelő két állapot között lépkedjen. Az ábrán pirossal és kékkel jelöltem azokat a lépéseket, mikor is növelem vagy csökkentem a forgást mérő változó értékét.

A programot a gyakorlatban is kipróbáltam, assembly-ben írtam a Pic16F690-hez a kódot, és a pickit2 próbapanelen lévő 4 led segítségével jelzem a változó aktuális értékét:

#include <p16F690.inc>
     __config (_INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _BOR_OFF & _IESO_OFF & _FCMEN_OFF)

     cblock 0x20
State		;state machine variable
Display         ;data to be displayed
     endc

     org 0
Start:
	clrf PORTB
     	bsf STATUS,RP0		; select Register Page 1
	bcf OPTION_REG,7
     	movlw 0xFF
     	movwf TRISA		; Make PortA all input
     	movwf TRISB
     	clrf TRISC		; Make PortC all output
     	clrf ANSEL 		; all pins digital

     	bcf STATUS,RP0		; back to Register Page 0
     	bsf STATUS,RP1		; Reg page 2

	movlw 0xFF
	movwf WPUB		; enable weak pull-up for Port B

	bcf STATUS, RP1		; Reg page 0

     	clrf Display
	clrf State

MainLoop:

;state table:
; input	|  000 	|  010	|  100	|  011	|  101	|
;  00	| 		->000			| == always ->000
;  01	|      ->010 	| ->000 | ->010 |->000- | == if state,0 ->000 (dec if 101), else ->010
;  10	| ->100	| ->000	| ->100 |->000+	| ->100 | == if state,1 ->000 (inc if 011), else ->100
;  11	| ->000 | ->011 | ->101 | ->011 | ->101 | == if state,0 ->101, else if state,1 ->011, else ->000

;decide current input: 00, 01, 10, or 11
;note that all input are active low

	btfss PORTB,6
	goto Input0
	goto Input1

Input0:
	btfss PORTB,7
	goto Input00
	goto Input01	

Input1:
	btfss PORTB,7
	goto Input10
	goto Input11

Input11: ;00
	clrf State		;state ->000
	goto Output
Input10: ;01
	btfss State,0
	goto I01B		;if 0xx
	goto I01A		;if 1xx
I01A:
		btfsc State,2	;if xx1
		decf Display,1	; decrement data
		clrf State	;->000
		goto Output
I01B:
		clrf State	;->010
		bsf State,1
		goto Output
Input01: ;10
	btfss State,1
	goto I10B		;if x0x
	goto I10A		;if x1x
I10A:
		btfsc State,2	;if xx1
		incf Display,1	; increment data
		clrf State	;->000
		goto Output
I10B:
		clrf State	;->100
		bsf State,0
		goto Output
Input00: ;11
	btfsc State,0		;if 1xx
	goto IA
	btfsc State,1		;or x1x
	goto IA
	goto Output
IA:
		bsf State,2 	;->uu1
	goto Output

Output:

     movfw     Display       ; Copy the display to the LEDs
     movwf     PORTC

     goto      MainLoop
     end

A dolgot összeállítva minden várakozásomat felülmúlva működött, a forgást pontosan és gyorsan méri, bár csak kézzel forgattam, így nem tudtam letesztelni, hogy mekkora szögsebességet képes még mérni. Mindenestre akár felhasználónak nyújtott bemeneti eszközként is remekül szerepelhet, mindenképpen kifinomultabb megoldás mint pl. egy potméter A/D átalakítóval. Digitális hifiken rendszeresen találkozhatunk ezzel a megoldással hangerő-szabályozás formájában.

[cc_java]while (true) {
Process p = Runtime.getRuntime().exec(“macska”);
p.waitFor();
}[/cc_java]

A kód eredeti, Tompika kedvenc állatait, a macskákat felemlegetve. A kód elméletben a következőt kellene, hogy csinálja: az első sor a [cci_java]p[/cci_java] referenciával elérhető módon indít egy processzt; míg a második sor vár, amíg a processz fut.

Ha megnézzük a kapcsolódó JavaDoc kommenteket, ez így működőképes is lehet. Ezzel szemben futásidőben problémák léptek fel, amiket feltehetőleg a következő kódrészletre való kicserélés javított:

[cc_java]while (true)
{
Process p = Runtime.getRuntime().exec(“macska”);
p.waitFor();
p.getErrorStream().close();
p.getOutputStream().close();
p.getInputStream().close();
p.destroy();
}
[/cc_java]

A kódrészlet utolsó sora vicces. Idézném a Javadoc kommentet:

[cci_java]public abstract void destroy()[/cci_java]

Kills the subprocess. The subprocess represented by this [cci_java]Process[/cci_java] object is forcibly terminated.

Amit én úgy értelmeznék, hogy a függvényt meghívva explicite lezárom a Processt. Viszont állítólag nem így történik. Valaki tudja a magyarázatot? Kíváncsi lennék rá.

PS.: ha valaki hozzájut hasonló gyöngyszemekhez, és eljuttatja hozzám, szívesen közzéteszem.

A következő kódrészlet ugyan működik és mivel a publikus api elrejti, az átlag fejlesztő nem találkozik vele, mégis érdemes rávetni egy pillantást. További szócséplés helyett következzék a kód, szerintem magáért beszél:


//AbstractEditPart.class

if (editPolicy != null) {
editPolicy.setHost(this);
if (isActive())
editPolicy.activate();
}
}


Akinek nem világos elsőre, kifejteném a problémát: láthatóan egy tömböt használ a java-ban alapértelmezésként elérhető "Map" funkcionalitásának a kiváltására. A tömb páros (és nulladik) helyén szereplő elem tárolja a kulcsot, az utána lévő páratlan helyen lévő elem az érték.

Minden elem hozzáadásakor dinamikusan növeli a tömb méretét, törléskor meg egyszerűen null-ra állítja a tömb megfelelő elemét. Ehhez még társul egy custom iterátor is, ami a tömb nem null elemeit listázza.

Őszintén nem értem a tervezési döntést, ami a tömb-alapú Map-hez vezethetett. A memóriaigénye a HashMap-nek nem sokkal több, és mivel jellemzően kis elemszámú esetek fordulnak elő, ez nem számottevő. A sebessége a HashMap-nek jobb, a "get" és "put" metódusok általános esetben konstans, de mindenképpen kevesebb a tömb végigjárásánál. Mindennek a tetejébe a fenti kód Map alkalmazásával kb. 3 sorra cserélhető, nem beszélve az osztály egyéb kódjáról, ami a tömböt piszkálja.

Egyetlen érthető mentségként csak arra tudok gondolni, hogy esetleg a kód korábban íródott, minthogy a java collections API-ba belekerült volna a Map. Ez viszont az 1.2-es verzióban történt meg, tehát elég régen. Nem tudom mennyi idős a GEF, így ezt nem tudom eldönetni.. Mindenesetre ez a kód nálam megütötte a WTF szintet.

Mondjuk ha csak annyi lenne a véleményem róla, hogy érdemes elolvasni, akkor egyszerűen fognám magam, és én is feltenném a deliciousre, hogy az a kevés ember, aki véletlenül odatéved, megtalálja. De a helyzet az, hogy egyfelől érdekesnek tartom, másrészt nem értek vele (mindenben) egyet.

Ami feltétlenül tetszett az írásban, és ami miatt minden, programozásban érintett embernek ajánlom elolvasásra, hogy konkrét példán bemutatja a különböző programfejlesztési elveket. Ráadásul mosóporreklám stílusban, azaz ilyen volt és ilyen lett összehasonlítással.

Előrebocsátanám még (egyszer), mielőtt elkezdek belemenni egyes részletkérdésekbe, hogy a cikkel alapvetően egyetértek, de néhány dolog érdemes továbbgondolásra. Az egyik, hogy ezeket a tervezési elveket szabálynak állítja be, szerintem viszont legfeljebb ökölszabálynak lehet tekinteni. Azaz alapvetően érdemes követni őket, kivéve, ha nem jók az adott helyzetben.

Miért lehetnek rosszak ezek az elvek? Például ha minden egyes funkciót külön osztályba teszünk, az osztályok, interfészek száma könnyen kezelhetetlen méretűre duzzadhat. Szóval amit megnyerünk a réven (áttekinthetőbbek és szerkeszthetőbbek a lokális kódok), elveszíthetjük a vámon (struktrurálisan nehezen áttekinthető a rendszer, nagy a betanulási idő).

Emellett a sok indirekció és absztrakciós szint teljesítményproblémákhoz vezethet. Például egy hívásnak nem elhanyagolható költségei vannak (stackelés, stb.). Vagy éppen hivatkozhatnék arra a nem túl régi tapasztalatomra, hogy egy algoritmusnál a legtöbb időt az vitte el, hogy a memóriából ismételten lekért adatokat. Ezt profilerrel derítettem ki, és lokális változóba áttöltve az adatokat és újra felhasználva kb. felére csökkentettem a futási időt. Vicces dolog az a cache miss (legalábbis szerintem ez történhetett).

És a legkomolyabb, kimutatható probléma (szerintem): a “tell, don’t ask” elvet jelenleg piszkosul nem szokás adatmodellre alkalmazni. Legalábbis Java környékén az aktuális state of the art marhára nem teszi – kivéve, ha rosszul látom, hogy mi a legfejlettebb. Aminek akár még oka is lehet.

A “tell, don’t ask” elv mit is jelent? Mondd meg az objektumnak, hogy mit csináljon (állapotfüggően), ne lekérd az állapotát, és ez alapján te döntsél helyette.

Érdekes módon viszont az adatmodellek manapság egyre inkább mennek a nagyon buta, csak getter/setterekből álló modellek felé. Miért is? Én úgy tippelem azért, mert

1. Ez a rész jól generálható. Az EMF alaptechnológia tipikusan arról szól, hogy valahogy összeklikkelgetsz egy EMF modellt, beállítod a genmodellt, és kapsz egy gyönyörűséges Java osztályhalmazt. Ami persze nem tud semmit azon túl, hogy getter, setter és factory hívásokkal felépíthető és bejárható.
2. J2EE technológiánál az entitásokat menti le a rendszer egy az egyben adatbázisba, amely entitásoknak tipikusan szintén getter/setter metódusai vannak. Esetleg még számított mezők is beköszönnek.

Mindkét esetben az a szokás, hogy a modellbefolyásoló logikát külön Manager jellegű osztályokba tesszük, akik a tényleges igényeknek megfelelően építik (rombolják ) a modellt.

És végül a legfontosabb hozzáfűznivalóm az íráshoz: igen, hosszú távon megéri ezeket az elveket követve tervezni, kivéve, ha amiatt, mert nem készülünk el határidőre, rövid/közepes távon befejeződik a projekt. És ennek a kezelése bizony emberi kérdés. Emiatt zárszóként Jeff Atwoodot idézném:

The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world — those are the people and projects that will ultimately succeed.

PS.: Mostanában Aadaam is foglalkozik azzal, hogyan érdemes nagyobb rendszereket összerakni. Ráadásul azt mutatja meg, hogyan lehet PHP-ban nem gányolni. Szép teljesítmény az is.

A dolog lényege, hogy egy definiált listát megjelenít, és lehetővé teszi a felhasználó számára az elemek kiválasztását egy dialógusban. Az ötlet jó, hiszen viszonylag gyakran szükséges feladat.

Ugyanakkor egy érdekes adalék a működéséhez: működik az a hasznos (és elvárt) funkció, hogy a lista elemei dupla kattintással történő kiválasztása működik. Feltéve, hogy a Mégsem gomb is engedélyezve van… No comment. (Ld. még Bug 292576).

Úgy gondolom, bemutatom a kódot, és felteszem a kérdést, látja-e más is a hibát benne.

[ccw_java]private ICoreNotificationObject notificationObject;

public void actionPerformed(ICoreNotificationObject notification) {
this.notificationObject = notification;
Display.getDefault().aSyncExec(new Runnable() {

public void run() {
String action = notificationObject.getActionType();
if (isOneOf(action, new String[] {
ICoreNotificationObject.TA_TRANSACTION_END,
ICoreNotificationObject.TA_UNDO_END,
ICoreNotificationObject.TA_SUBTRANSACTION_END})) {
updateGraph();
transactions.pop();
} else if (isOneOf(action, new String[] {…}){
//…
}
});[/ccw_java]

Még némi információ a kód működéséről: a kód egy eseményfigyelő osztály belsejében van, és a Runnable adatváltozásokat próbál követni, amely tranzakciókba van szervezve, ill. a tranzakciók során visszavonás események is érkezhetnek.

Na, kinek van tippje, mi lehet a hiba? Ha nincs tipp véges időn belül (előre nem specifikálnám), akkor majd megosztom a helyes megfejtést. Annyit mondok előre, hogy fejet falbaverős hiba .

Update: először is helyesbítettem a kódot, mert sikeresen a javított változatot töltöttem fel.

A problémát az okozta, hogy az asyncExec() hívás indított egy új jobot, amit valamikor majd végrehajt. Csak közben visszaadja a vezérlést, és ezzel lehetővé teszi a rendszer számára, hogy felülírja a run() metóduson belül is használt notificationObject változót.

Az asyncExec() hívás syncExec()-re cserélése megoldotta a problémát, ugyanis az megvárja, hogy visszatérjen a meghívott thread.

Ez a hiba kifejezetten mocskos dolog, mert eredetileg működött, míg a környezet refactoringja előhozta a bugot…

A parser az LPG parser generátorral készült, méghozzá annak az 1.0-s változatával. Most már van 2-es is, ami természetesen nem kompatibilis a régivel (legalábbis generált kód szintjén semmiképp sem – többek között más java package-et használ). Miután nem sokkal release előtt kaptam meg, frissíteni most biztos nem lehet (később meg valószínűleg úgyis kellene).

Na, tehát ott tartottam, hogy 1-es verzió. Minden nagyon szép, minden nagyon jó, mindennel meg vagyok elégedve, úgyhogy módosítottam a grammar fájlt. Na, ideje újragenerálni a kódot. És itt jön a feketeleves: az LPG parser generátor régi verziójához csak egy Windows-os exe fájl van, azzal lehet futtatni. Természetesen forráskód is van, de még a makefile is a Visual C++ fordítóra van kihegyezve. Szóval lefordítani macerás.

Nem is kezdem el, mert feltehetőleg csak ideiglenes megoldás kell (max. 1-2 év ). Ugyanakkor cél, hogy a megoldás integrálódjon az Eclipse-be, azaz néhány klikkeléssel sikerüljön a programot elindítani. A lehetőségeim: wine vagy VMware.

Az utóbbi nem tetszene, mert relatíve sok erőforrást eszik, ráadásul egyszerűen csak a VMware alatt futó Eclipse példánnyal lehetne összekapcsolni, amelynek a gyorsbillentyűi teljesen mások, mint a natív Mac-es példányé.

Szóval lehet reménykedni, hogy a wine-osok jó munkát végeztek. És szerencsém van, mert az lpg.exe gond nélkül futtatható vele.

Most már csak az Eclipse integráció van hátra. Ennek remek eszköze az External Tools eszköz (megjegyzés: natív Windows-on is csak így lehet futtatni az lpg.exe-t Eclipse-ből – nincs jobb támogatás) a Run menüben.

Létrehozhatunk egy saját eszközt, amelynek felparaméterezéséhez használhatjuk az Eclipse különböző változóit. Számunkra ehhez kettőre van szükség:

• [cci]${resource_loc}[/cci]: az aktuálisan kijelölt erőforrás elérhetősége a fájlrendszerben (nem workspace-relatív módon!)
• [cci]${container_loc}[/cci]: az aktuális erőforrást tartalmazó mappa elérhetősége (szintén nem workspace-relatív módon)

Az LPG parser generátor számára fontos a munkakönyvtár beállítása, ide fogja generálni a fájlokat. A többi adat kitöltése magától értetődő, ezért csak egy képernyőfotót illesztek be róla.

LPG futtatása Wine segítségével az aktuális fájlra

Az LPG futásához három dologra van szükség: a nyelvtan fájlra vagy fájlokra, az include fájlokra és a template fájlokra. Ezek lehetnek mind a munkakönyvtárban (ez a helyzet, ha saját sablonokat használunk), vagy pedig környezeti változók által kijelölt mappában, esetleg paraméterként is át lehet adni.

Szerintem a legtisztább a környezeti változók használata, ezért az Environment fülön felvettem az [cci]LPG_INCLUDE[/cci] és az [cci]LPG_TEMPLATE[/cci] környezeti változókat, azokat a megfelelő mappákra irányítva.

Ezután a futtatás gombra kattintva jött a varázslat: a wine az OSX-es útvonalakat lefordítja a Windows-os program számára érthető formátumra (megfigyelhetőek az Y:\ kezdetű útvonalak a szöveges kimeneten – amik természetesen megjelennek az Eclipse Console view-ban), és az ugyanilyen formátumban készülő fájlok megjelennek az OSX-es mappában. Sőt, a környezeti változókra is igaz ez. Nagyon cool.

A technológiával két kisebb gondom van: nem tudom az LPG-t így a .g fájl jobb gombos menüjéből futtatni (nincs ott külső eszköz futtatásához lehetőség), és nem működik a megoldás, ha nem a Navigator view aktív a Run external tool használatakor (természetesen akkor sem, ha nem a .g fájl van kijelölve, de ez természetes ). Van ezekre valakinek valami ötlete?

Megkérdezték tőlem, van-e ötletem, mitől lehet az, hogy egy ábra hivatkozásánál a számot miért jeleníti meg teljesen más stílusban, mint a többi ábrahivatkozást, ill. mint az ábra feliratát. A probléma úgy jelentkezett, hogy Figure 9. számú ábra (ez az elvárt formátum), míg a hivatkozása Figure 4.4 formátumban jelent meg.

A hivatkozásokat a LaTeX vissza tudta fejteni, semmiféle hibaüzenet nem jelent meg, csak rosszul jelent meg a sorszám. Nagyon látványos hiba sem volt a kódban, többszöri átolvasás után (lényegében hasonlóan nézett ki, mint a többi ábrabeillesztés).

Megpróbálgatva kihagyni elemeket, áthelyezni a kritikus ábrát, illetve hivatkozást sikerült rájönni, hogy a LaTeX valami miatt a fejezet/szakasz-számot jeleníti meg az ábra sorszáma helyett.

Innen már egy gyors Google megadta a megoldást: http://www.leancrew.com/all-this/2008/09/latex-figure-captions/ , ill. az oldalon keresztül a következő lap: http://en.wikibooks.org/wiki/LaTeX/Labels_and_Cross-referencing#Fixing_wrong_labels

A megoldás lényege a következő: semmilyen körülmények között ne legyen a [cci_latex]\label[/cci_latex] címkeparancs a [cci_latex]\caption[/cci_latex] feliratparancs elé. A feliratparancs belsejébe vagy a feliratparancs utánra nyugodtan kerülhet.

A végére beszúrok egy javasolt mintát kép beillesztésére, ami ezt a hibát elkerüli (a forrás a TeXlipse plug-in sablon gyűjteménye:

[cc_latex]\begin{figure}[htp]
\begin{center}
\includegraphics[width=${figureWidth}]{${filename}}
\caption[${labelInTOC}]{${figureCaption}}
\label{${figureLabel}}
\end{center}
\end{figure}[/cc_latex]

A TeXlipse editor ezt a mintát automatikusan beilleszti, ezért nekem nehéz ezt a hibát elkövetnem, de másnak még hasznos lehet. Remélem, van, akinek a megoldás megosztásával


public class AB{
public static abstract class A{
public A(){
doSomething();
}
protected abstract void doSomething();
}

public static void main(String[] args){
new B();
}
}


A példát igyekeztem egyszerűnek tartani, de talán megérdemel egy rövid magyarázatot: Két osztályt definiáltam, az egyik leszármazottja a másiknak. Érdekesség még, hogy az ős konstruktora kódot hív meg a leszármazottból absztrakt metóduson keresztűl. Egy “B” típusú objektum létrehozásához láthatóan három helyről kell kódot hívni: Az “A” és a “B” konstruktora, továbbá a “B” osztályban lévő, konstruktoron kívüli inicializálás. A probléma ezen három kódrészlet lefutásának sorrendje.

Első ránézésre a kóddal semmi probléma nincs azon kívül, hogy teljesen haszontalan. Mindkét mező final, így gondolnánk a konstruktor elött inicializálódnak, tehát nem okozhat problémát. Azonban a kód futtatásakor egy csinos NullPointerException kacsint vissza ránk. A futás kimenete:


class java.lang.String
Exception in thread "main" java.lang.NullPointerException
at AB$B.doSomething(AB.java:22)
at AB$A.(AB.java:8)
at AB$B.(AB.java:17)
at AB.main(AB.java:27)


Láthatóan a B.doSomething() első sora lefut hiba nélkül, a probléma utána keletkezik. Tehát az “s” változó már létezik, az “o” viszont nem. A konstruktorok lefutásának sorrendje tehát: s=..,A(),o=..,B(). A két mező között csupán az a különbség, hogy az “s” mező típusa megegyezik a futásidejű értékének típusával. Ez meghatározza, hogy a mező a szülő osztály konstruktora előtt vagy után kap értéket. Érdemes kipróbálni, ha az “s” mező elöl kivesszük a final kulcsszót, az azt okozza, hogy az is a szülő konstruktor hívása után kap értéket. Vajon hogy határozódik meg a pontos sorrend, mitől függ, hogy hova ütemezi be a java a mezők értékadását?

Nyílván valahogy igyekszik meghatározni, hogy az adott értékadás kiértékelhető-e az osztály örökölt részének inicializálása nélkül vagy sem. Ennek tesztelésére tettem még egy kísérletet, kicsit módosítva a példát:


public class AB{
public static abstract class A{
protected String a;
public A(){
a = "abc";
doSomething();
}
protected abstract void doSomething();
}

public static void main(String[] args){
new B();
}
}


Ez a kód is szépen elszáll, méghozzá a B.doSomething() első sorában! Azaz, az explicit hivatkozás egy szülő objektum-beli elemre azt eredményezi, hogy a mező értékadását a szülő konstruktor utánra ütemezi. Elég intelligensnek tűnik a dolog, de mégis beleütközik az ember, mert másra számít.

Persze elkerülhető a dolog ha a konstruktorból hívott absztrakt metódusokat anti-pattern-nek kiáltjuk ki, bár gyakran jól jön. Mégis pontosan mi határozza meg a sorrendet, és lehet-e befolyásolni valahogyan? Van valaki aki nálam sikeresebben guglizott?

Pár óra keresgélés és javadoc olvasgatás után rábukkantam a megoldásra: Minden view-t tartalmazó IWorkbenchPartSite lehetőséget biztosít egy ISelectionProvider regisztrálására, amely interfészt ad kiválasztási információk kinyerésére és átadására, továbbá listener-ek regisztrálására. A másik, csatlakoztatni kívánt view által megadott ISelectionProvider-nek az általunk generált kiválasztási eseményeket át lehet adni, illetve figyelni lehet az általa generált ilyen eseményeket.

A problémát csak az okoz, hogy egy adott view által generált és elfogadott kiválasztandó elemek az adott view modelljéből kerül ki, tehát ugyanezen modell elemeit kell neki átadni. Ha az általunk írt view más modellen, vagy ugyanazon modell felett máshogy definiálja a kiválasztást, akkor a kiválasztást konvertálni kell a modellek között. Ez természetesen csak akkor oldható meg, ha egyáltalán értelmezhető a közös kiválasztás.

Mindehhez persze az első lépés az, hogy megtaláljuk a csatlakoztatni kivánt view-t, amit az azonosítójának ismeretében tehetünk meg a következő módon:


PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().findView(viewID).getSite().getSelectionProvider();


ahol a [cci_java]viewID[/cci_java] helyére a keresett view szöveges azonosítóját kell megadni. A Variables View azonosítóját az org.eclipse.debug.ui plugin egy [cci_java]IDebugUIConstants[/cci_java] nevű publikus interfész elérhetővé teszi.

Mint az eclipse esetében általában erre problémára is egy jól kitalált megoldás létezik, ami megfelelően egyszerű ahhoz, hogy a módszer ismeretében könnyű legyen implementálni, a nehézséget csak a módszer megtalálása jelenti.