Mijn dag-tot-dag logboek van de werkzaamheden die ik op profiler uitvoer.

HOME

Archives:

Mail van Davy aan Edwin, 20-3-2001, 17:20

Edwin,

ik heb het component zover dat-ie netjes tekst kan tekenen met word-wrap functionaliteit erin. Ook worden de juiste fonts en fontkleuren uit de legenda gehaald. Bovendien heb ik de locaties voor de ABM en BST files ook als member variabelen...

Het eigenschappen scherm heb ik enigszins gestript, maar heb er nog wel wat in laten zitten. Altijd handig als je bijvoorbeeld de achterliggende data wilt zien. Wat ik OOK heb laten zitten is de vinkjes voor 'verbergen' e.d. Ik dacht dat dit handig zou zijn als je bijvoorbeeld een bepaalde laag niet wil tekenen. Misschien dat je daar gewoon de bestaande architectuur van laagweergaven voor blijven gebruiken, dat is het snelst geïmplementeerd.

Je kunt testen met de BORBG component en de 'boorgatinrichting' template (die laatste zit in de lokale database. oh ja, de instellingen voor de db's moet als volgt zijn:
In ProfilerApp kun je via Systeem->Programma databases de DSN's zetten:
Primaire DB: profiler_dba/profiler_dba@west_v1
secundaire DB: profiler_user (een odbc koppeling naar d:\profiler\profilerv1.0.mdb))


Als programmeerhulp:

btaClass_TekstKolomWeergave::DrawText
-------------------------------------------------------------
In deze functie wordt de tekst uiteindelijk getekent. Het enige wat je daar moet doen is de juiste lettertypes op de juiste plaats zetten en de juiste tekst afdrukken m.b.v. de globale functie DrawTextWithWordWrap.

btaClass_TekstKolomWeergave::InitFonts
------------------------------------------------------------
In deze functie worden de fonts uit de legenda aan member variabelen gekoppeld. Hij is vrij eenvoudig uit te breiden. LET OP: deze functie wordt bij elke draw uitgevoerd, omdat de fontsize afhankelijk is van de status van de CDC!

DrawTextWithWordWrap
-------------------------------------
Globale functie om tekst met tekstterugloop te tekenen. Hierbij een uitleg:

long DrawTextWithWordWrap(CDC* pDC, long lLeft, long lRight, long lTop, CString sTekst,
BOOL bDraw /*= true*/, float fSpacing /*= 0.25
/*standaard is de horizontale spacing 1/4 maal de hoogte van 1 letter*/)

pDC: Spreekt voor zich, lijkt mij
lLeft: x-coordinaat van de linkerkant van de tekst
lRight: x-coordinaat van de rechterkant van de tekst
lTop: y-coordinaat van de bovenkant van de tekst
sTekst: De te tekenen tekst
bDraw: Deze parameter is om te kunnen tekenen zonder te tekenen. Dit is nodig als je wilt weten tot hoe diep hij gaat tekenen
fSpacing: De horizontale spacing, dus de ruimte tussen de zinnen. Staat standaard op 1/4 van de hoogte van 1 letter

return value: y-coordinaat van de onderkant van de (getekende) tekst

Als er nog iets is wat ik kan doen, hoor ik dat graag!

Groeten,

Davy
posted by Davy at 01:48 [edit]

Mail van Davy aan Edwin, 16-3-2001, 12:29

Edwin,

hierbij de samenvatting van ons overleg over hoe we het nu gaan
aanpakken met betrekking tot de tekstkolomweergave component in profiler.
De volgende dingen zijn besloten en geopperd:

1) na jou gesprek met Aleid is toch wel duidelijk geworden dat de
verwachtingen van TNO niet geheel overeen kwamen met wat wij hadden
beloofd te leveren. Als compromis zal waarschijnlijk profiler onderwater
worden aangeroepen door de boorstaat print module, zodat profiler het
visuele gedeelte kan printen en de boorstaat print module de tekst.

2) Hoe we het ook gaan oplossen, de tekstkolom moet sowieso in Profiler
komen. We hebben samen het component alvast aangemaakt, zodat ik daar nu
aan verder kan. De volgende acties moeten worden ondernomen om de
tekstkolom te realiseren:

* (KER) Optioneel laagnummers printen naast de kolomweergave. De breedte
van de kolom blijft bij het aanzetten van de nummering even groot,
alleen wordt er voor de weergave componenten dan wat minder ruimte
gereserveerd
* (KER) Het implementeren van een component dat strings kan afdrukken in
het gewenst lettertype en rekening houdend met terugloop (!).
* (KER) Het (in het weergave component) te pakken krijgen van de
parameters waarin de locatie van de .bst en .abm bestanden staan.
* (DEK) Het vervangen van de statische test-tekst uit het tekstcomponent
dat KER heeft gemaakt, door de werkelijke tekst. Hiervoor moet de
'engine' van de boorstaat printmodule worden geïntegreerd in het
kolomweergave component.

Volgens mij was dit alles. Als ik wat ben vergeten hoor ik dat graag.

Groeten,

Davy
posted by Davy at 03:18 [edit]

Mail van Edwin aan Davy, 15-3-2001, 15:47

Hoi Davy,


We hebben gesproken over het realiseren van de tekstuele weergave van data (2001-3.6). We hebben het volgende besloten:


1. De keuze van de kolomweergave component (.dll) wordt nu bepaald door de inlees component (.dll) en bewaard in KolomData (class). Dit is niet correct omdat de data niet mag bepalen hoe ets weergegeven moet worden. De koppeling wordt voortaan opgeslagen in de profiler programma instellingen database. De tabel data interpretatie krijgt daartoe een veld 'activex_id' die verwijst naar een KOLOM_WEERGAVE component in de ACTIVEX tabel. In het klassediagram betekend dit dat de CLSID van de kolomweergave component (.dll) bewaard wordt in DataInterpretatie class).

ACTIES:
- Aanpassen implementatie huidige inlees componenten (.dll)
- Aanpassen header btaClass_KolomData
- Aanpassen header btaClass_DataInterpretatie
- Aanpassen implementatie btaClass_LocatieRecord
- Wijzigen datamodel programma instellingen db (fk van 'data_intrepretatie'
naar 'activex_id').



Discussie:
We zitten met de vraag of het zin heeft een apparte weergave component te maken voor de UITGEBREIDE tekstuele weergave van data. Deze component maakt het dan mogelijk de uitgebreide omschrijving te maken zoals die nu gegenereert wordt door de 'boorstaat print module'. Er zijn echter een aantal problemen. Ten eerste heb je toegang nodig tot twee bestanden: .bst en .abm. Ten tweede zit je met het probleem dat je geen 'kopgegevens' en andere data kan weergeven. Een oplossing zou kunnen zijn het blijven gebruiken van de boorstaat module, waarbij we op de een of andere manier een samenwerking tussen de twee programma's tot stand brengen. Ik zal eerst met Aleid overleggen of dat sowieso een oplossing is.


Als we besluiten toch de tekstomschrijvingen in Profiler als apparte kolom weer te geven moeten we nog het volgende doen:

1. Er wordt een nieuwe kolom weergave component gemaakt voor het weergeven van tekstuele omschrijvingen van data. Deze kolom geeft het volgende weer: : , voorbeeld: "1: Matig grof zand".

2. Aanpassen lagenkolomcomponent: toevoegen van laagnummers.

3. Een oplossing vinden voor de opname van de paden naar de juiste .abm en .bst achter de ; in de CLSID in de ActiveX tabel.


Morgen kunnen we hierover verder praten.


Groeten Edwin.
posted by Davy at 06:44 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 14-3-2001
- D.D. de Kerf
- PC12
---------------------------------

Poeh, poeh. Na zeker 8 uur verdwaalt te zijn geweest in de UpdateLocatieRecord functie en de bijbehorende COM-componenten, kan ik nu toch gelukkig melden dat het koppelen en ontkoppelen nu gaat zoals het hoort. Allereerst heb ik het ontkoppelen geïmplementeerd door een entry in de setObj functie van de boorgatinrichtingKolomWeergave toe te voegen waarmee het mogelijk werd om legenda-engines te ontkoppelen. Het probleem werd echter nog groter toen dit af was en werkte, maar ik ineens geen omstorting meer terug kon koppelen.... De verklaring hiervan lag in het feit dat de koppeling ook nog via het 'oneigenlijke gebruik van het model' verliep en na deze nieuwe functionaliteit dus ook niet meer werkte. Daarom moest ik me dus weer door UpdateLocatieRecord worstelen.

Tijdens het debuggen van bovenstaande functionaliteit crashte Profiler regelmatig bij het selecteren (vooral als ik twee keer kort na elkaar iets probeerde te selecteren). In het commentaar zag ik dat het ook de eerste keer niet was dat-ie daarop crashte. Ik ben erachter gekomen dat deze crashes veroorzaakt worden door een pointer die ineens wijst naar een object dat niet meer bestaat. Een check op NULL leverde namelijk niets op. Het gaat dan om de member variabele m_pCurSelectedGC van de klasse CProfilerView. Om dit op te lossen heb ik op de plaatsen waar Profiler crashte try {} - catch(...) {} constructies aangebracht. Sindsdien is-ie op die plaats nog niet gecrasht (--- kijkt trots ---).

Het volgende op de lijst was de serialisatie. Die was natuurlijk helemaal verwaarloosd bij het ontwikkelen van de nieuwe opzet en moest nu weer bijgetrokken worden. Na een paar uur worstelen met btaClass_Aggregatie's en store_and_load_pointers kreeg ik ook dit voor elkaar. Er viel mij echter wel iets geks op na de serialisatie. Als een opgeslagen profiel wordt ingelezen ziet het er op het eerste gezicht goed uit. Alleen de koppelingenlijst klopt voor geen meter. Het lijkt erop alsof zo'n beetje alles wat er te koppelen valt (en NIET te koppelen valt) gekoppeld is, tenminste in het eigenschappen-dialoog. Ik denk dat dat ook de reden is waarom een opgeslagen lithologie-profiel na inlezen toch weer ging herberekenen, ookal was de database niet gewijzigd....

Tenslotte nog even gekeken naar het probleem van de kolombreedte van de gehele weergavecomponent. Profiler gaat, onafhankelijk van de weergavecomponent, berekenen hoe breed het component gaat worden. Dit doet profiler door het aantal kolomdata die aan de component zijn gekoppeld te vermenigvuldigen met de standaardbreedte van de kolomcomponent die aan de kolomdata vasthangt. Dit betekent voor de boorgatinrichting dat profiler de breedte dus steeds de breedte van 1 buis teveel schatte, omdat de omstorting ook een kolomdata is en dus wordt opgeteld bij het aantal kolomdata. Als oplossing heb ik de kolom gewoon wat breder gemaakt als er omstorting aan is gekoppeld. Dit was de makkelijkste oplossing en er valt ook wel wat voor te zeggen, omdat bij omstorting meer ruimte alleen maar duidelijker is. Je moet dan immers ook de achtergrond goed kunnen zien.

Nu de boorgatinrichting component in principe af is wacht ik op een gesprek met Edwin over de volgende stap: de tekstweergave component (waarmee in gewone tekst boorgegevens naast de gewone, grafische, kolom komen te staan).

Status Quo: op 14-3-2001:
- Profiler bug: koppeling bij meerdere profielen in 1 sessie. Deze bug heb ik al regelmatig omschreven en is nog niet opgelost. Het gaat hier om een echte Profiler bug die ook al voor de uitbreiding erin zat.
- Profiler bug: koppelingen na openen opgeslagen profiel. Na het openen van een opgeslagen profiel zijn de koppelingen in het profiel op zich OK, alleen in het eigenschappen dialoog klopt er niets meer van.
- Boorgatinrichting component: Wat mij betreft is dit af ;-)

Update Status Quo anno 13-3-2001:
- Ontkoppeling mechanisme: Gefixt
- Variabele breedte van de volledige kolom: Gefixt, hoewel niet op de meest mooie manier. Zie hierboven (4de alinea) voor meer info.
- Variabele breedte van de lagen: Geïmplementeerd. Was vrij eenvoudig.
- Selectie: Gefixt. Bovendien waarschijnlijk een beruchte 'willekeurige-profiler-crash' mee opgelost.
posted by Davy at 05:35 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 13-3-2001
- D.D. de Kerf
- PC12
---------------------------------

Hoewel ik dacht het boorgatinrichting component zo goed als af te hebben, bleek dat het toch maar anders moest. Afgelopen vrijdag was ik druk doende een probleem uit te denken (namelijk, hoe koppel ik de omstorting als aparte kolom (dit geeft namelijk extra mogelijkheden binnen profiler, omdat je dan elke datainterpretatie en legenda los kan laten op de omstorting) zonder een nieuwe kolomweergave te triggeren). Bovendien bleek dat zodra er een andere datadefinitie in het profiel kwam, de koppeling ook anders te verlopen. Voor elk kolomdata component werd een kolomweergave aangemaakt, wat resulteerde in 3 identieke boorgatinrichting componenten met elk 3 buizen, terwijl ik maar 1 weergavecomponent nodig had met 3 buizen.... Hoe het dan eerst altijd goed gegaan is, is mij tot op heden nog niet duidelijk, maar dit betekende wel een probleem. Immers, hoe krijg ik het voor elkaar dat meerdere kolomdata aan één kolomweergave worden gekoppeld??

Na een lang gesprek met Edwin zijn we tot de conclusie gekomen dat het weergavecomponent op dat moment nog verkeerd gebruik maakte van het model. Dit was mij bij de ontwikkeling niet opgevallen, omdat het model uit zoveel verschillende delen bestaat. Bovendien moet je eigenlijk altijd alle semantische (achterliggende) betekenissen van de relaties en aggregaties in je hoofd houden. Een wijze les, maar iets te laat geleerd, want nu moest het dus anders. In plaats van de weergavecomponent via het locatie object uit te laten zoeken welke kolommen het moest tekenen, moest het mogelijk worden meerdere legendaengines te koppelen aan één kolomweergave. Welke kolomdata/legendaengines aan welke kolomweergave moet worden gekoppeld, kan worden duidelijkgemaakt in het inleescomponent. Dit inleescomponent geeft dan per locatie volgnummers aan de kolomdata, die aangeven of ze aan hetzelfde component moeten worden gekoppeld of niet. De modelwijziging was snel gemaakt (kolomweergave heeft nu een relatie met * legenda-engines i.p.v. met 1). Het probleem is echter altijd dat ook de functionaliteit moet worden aangepast aan het nieuwe model en in Profiler zit nogal wat functionaliteit. Gelukkig is bij deze modelwijziging het raakvlak te overzien. Voornamelijk de locatierecord klasse zal eraan moeten geloven, en dan met name de InitLocatieRecord en UpdateLocatieRecord functies. Die zijn helaas nogal omvangrijk, maar na anderhalve dag werk was deze vrijwel geheel omgeschreven.

Na deze modelwijziging kon ik met een gerust hart verder. Het implementeren van de omstorting was vrij eenvoudig. Naast kolomdata en weergavedata van de buizen heeft het object nu ook een optionele koppeling naar kolomdata en weergavedata van een lagenkolom met daarin de omstorting. Bij het tekenen wordt dan ook eerst de omstorting getekend (indien aanwezig) en vervolgens de buizen er bovenop. Verder moest eigenschappen scherm nog flink worden aangepast na de modelwijziging, maar dat is inmiddels ook gebeurd.

Status Quo: Met betrekking tot de recente modelwijziging:
- Ontkoppeling mechanisme: Vooralsnog keek het ontkoppelings mechanisme in btaClass_LocatieRecord.UpdateLocatieRecord alleen maar naar kolomweergaven die wellicht niet meer nodig waren. Nu is het echter zo dat ook legendaengines BINNEN een kolomweergave moeten kunnen worden ontkoppeld. Stel bijvoorbeeld dat ik de ontstorting uit mijn boorgatinrichting wil ontkoppelen. In Profiler ontkoppel ik dan de lithologie en in principe moet dan de legendaengine naar de omstorting uit de kolomweergave component worden verwijderd. Als ik vervolgens ook de filterstellingen ontkoppel moet het kolomweergave component zelf worden verwijderd, omdat er dan geen enkele legendaengine meer aan gekoppeld is. Dit mechnanisme zit nog niet in profiler, omdat ervan uit werd gegaan dat een kolomweergave component maar één kolomdata component weergeeft.
- Variabele breedte van de volledige kolom: Hoewel vorige keer werd gemeld dat dit was geïmplementeerd, moet dit toch opnieuw worden bekeken. Immers, de omstorting is ook een kolom en wordt ook meegenomen in de breedte. Dit resulteert in een bredere kolom, zodra de omstorting eraan wordt gekoppeld.

Update Status Quo anno 9-3-2001:
- Omstorting: geïmplementeerd.
- Variabele breedte van de lagen: Moet nog steeds gebeuren.
- Bug bij meerdere profielen in 1 sessie: Moet ook nog steeds naar gekeken worden.
- Selectie: Dit is nog steeds niet opgelost, hoewel het wel is verbeterd dankzij de omstorting. Als er omstorting is, kun je altijd naar het eigenschappen scherm.
posted by Davy at 00:29 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 9-3-2001
- D.D. de Kerf
- PC12
---------------------------------

(10:50) Weer even tijd om mijn bevindingen met betrekking tot profiler te noteren. Ik zit sinds deze maandag op een ander kantoor (kantoor 7 op de 3de verdieping... Sinds februari hebben we namelijk ook een 2de en een 3de verdieping) en een andere computer met Windows 2000 in plaats van Windows NT. De overgang naar windows 2000 gaf op zich erg weinig problemen. Er waren in het begin wel wat strubbelingen met het werkend krijgen van tools als PL/SQL developer en Visual C met Oracle, maar gelukkig zijn dit binnen Bodégro allemaal bekende problemen en waren ze snel de wereld uit geholpen.

Het begin van de week besteed aan communicatie met Aleid om nog wat onduidelijkheden met betrekking tot de boorgatinrichting uit de wereld te helpen. Conclusie is, zoals we al verwacht hadden, dat de kolombreedte van filterinstelling componenten flexibel moet zijn. Dat betekent dat, hoe meer buizen er zijn, hoe breder de kolom moet zijn. Bovendien vond Aleid mijn idee om de omstorting weer te geven (namelijk als gewone lagenkolom onder de filterstellingen, zodat je de omstorting ook echt rondom de buizen ziet liggen) dik in orde en dit zal ik dan binnenkort ook proberen te realiseren. Tenslotte moet de buisdikte ook gevisualiseerd worden en dit gaan we doen door de breedte van de lagen afhankelijk te maken van de doorsnede van de buis. Oh ja, en de volgnummers van de buizen moeten boven de buizen worden afgedrukt.

Eergisteren en gisteren heb ik besteed aan het inrichten van mijn PC om profiler te kunnen ontwikkelen op Windows 2000. Bovendien heb ik tijdens dit inrichten de functionaliteit bijgebouwd dat de volgnummers van de buizen boven de buizen worden afgedrukt. Ik gebruik hiervoor het Arial lettertype dat half zo groot is als de lettergrootte die gebruikt wordt voor de Y-schaal component. Dit gaat nu nog goed (met volgnummers van 2 cijfers lang), maar ik denk niet dat met deze lettergrootte meer dan 3 karakters per buis kunnen worden afgedrukt. Dit lijkt mij echter ook niet echt nodig, omdat een filterstelling met meer dan 999 buizen vrij ondenkbaar is ;-) Bovendien is de koptekst nu rechtstreeks gekoppeld met de kopgegevens van de buis. Dit is natuurlijk nog niet correct, omdat hier meer in kan staan dan alleen het volgnummer, maar omdat we nog geen goede gegevensdefinitie hebben voor de filterstellingen, laat ik het voorlopig even zo.

Gistermiddag en vanochtend heb ik besteed aan het realiseren van een flexibele kolombreedte, zodat filterstellingen met veel buizen breder zijn dan filterstellingen met weinig buizen. Ik moest sowieso naar het schalingmechanisme kijken, omdat het nog niet helemaal goed ging bij filterstellingen. Het leek erop alsof de breedte van het papier werd berekend aan de hand van het aantal kolomdata-objecten per locatie (en dat was ook zo). Dit is natuurlijk ok, totdat je meerdere kolomdata-objecten in één weergavepatroon gaat weergeven (zoals het geval is bij de boorinrichting component). Uiteindelijk bleek dat de functie GeefWeergavebreedteVoorDataInterpretatie_Legenda van btaClass_Profiel de boosdoener was. Deze functie wordt gebruikt bij het bepalen van de breedte van het profiel. Op het moment dat deze functie wordt aangeroepen bestaan er nog geen weergavecomponenten en kun je dus niet aan de weergavecomponenten zelf gaan vragen hoe breed ze zullen worden. De functie keek daarom puur naar de orientatie van de achterliggende koppelingen. Was de orientatie horizontaal, dan werd de breedte van een lagenkolomcomponent genomen. Was de orientatie verticaal, dan werd de breedte van een analogekolomcomponent genomen. Wat er bij de boorgatinrichting gebeurde, werd dat elke koppeling van de laatste locatie (in mijn geval 6, omdat ik 6 buizen had en dus ook 6 koppelingen (?)) gezien als een lagenkolom (omdat de orientatie horizontaal was) en dus werd de breedte geschat op 6 keer 6mm. Uiteindelijk WERD de breedte maar 6 keer 2mm (de standaard breedte van een buis) en werd het profiel dus veel te breed gemaakt.

Ik heb daarom de functie GeefWeergavebreedteVoorDataInterpretatie_Legenda herschreven. In plaats van een tijdelijke lagenkolom- of analogekolomcomponent aan te maken, kijkt de functie nu naar de clsid die verbonden is aan de kolomdata (dankzij het inleescomponent dat vanaf nu zelf aan kan geven welke component gebruikt moet worden voor de weergave) en maakt DAAR een tijdelijke component voor aan. De breedte wordt vervolgens uitgelezen en gebruikt. Aangezien de standaard breedte voor een boorgatinrichtingcomponent 2 mm is (de breedte van 1 buis), wordt nu 6x 2mm gepakt als breedte voor de locatie en dat is ook correct.... Mis gaat het echter zodra enkele buizen onzichtbaar worden gemaakt. Dit onzichtbaar maken gebeurt namelijk in de component zelf (kan ook moeilijk ergens anders). Als je dus in een boorgatinrichtingcomponent enkele buizen gaat verbergen, wordt de breedte door btaClass_Profiel toch nog geschat op de volledige breedte van de weergave voor ALLE buizen. Dit lijkt mij persoonlijk echter niet zo'n bezwaar, aangezien het verbergen van buizen toch een functionaliteit is die je niet vaak zult gebruiken. En als je 'm gebruikt kan je op deze manier ook nog zien dat er meer buizen inzitten, omdat het profiel meer ruimte heeft gereserveerd voor de kolom...

Wel zag ik nog iets geks bij het testen. Als ik in één profiler sessie een aantal profielen met lithologie, vervolgens een profiel met boorgatinrichting en daarna weer een profiel met lithologie aanmaak, worden in dat laatste profiel de koppelingen standaard niet gezet. Erg vreemd. Ik kan ook zo 1-2-3 geen reden bedenken, maar ik zal deze 'bug' onthouden.

Status Quo: Met betrekking tot het recente overleg met Aleid zal ik nog even kort de stand van zaken geven:
- Kopjes bij buizen: Geïmplementeerd.
- Variabele breedte van de volledige kolom: Geïmplementeerd.
- Omstorting: Moet nog. Mijn idee is om de omstorting als een lagenkolomcomponent in het profiel toe te voegen. Zo hebben we in ieder geval de data al in het profiel. Vervolgens moeten we dan instellen dat boorgatinrichtingcomponent transparant wordt en over het lagencomponent getekend wordt... Hoe ik dit ga aanpakken weet ik nog niet goed en dat ga ik dus eerst eens uitontwerpen.
- Variabele breedte van de lagen: Moet nog. Ook hiervan weet ik nog niet precies hoe ik het aan ga pakken. Ik kan natuurlijk dit gedrag alleen in de boorgatinrichting component implementeren en bijvoorbeeld in de code op zoek gaan naar de breedte van de buis. Een andere mogelijkheid is om variabele laagbreedte in te bouwen in de lagenkolomcomponent. Deze laatste optie is op zich beter, omdat je dan de functionaliteit ook bij gewone datainterpretaties kan gaan gebruiken. Het is echter veel meer werk en bovendien moet het dan geïntegreerd worden in de huidige definite van datainterpretaties... Een hele klus dus.
- Bug bij meerdere profielen in 1 sessie: Hierboven uitgelegd.

Update Status Quo anno 27-2-2001:
- Selectie: Dit is nog steeds niet opgelost. Ik zal hier eens met Edwin naar kijken, want ik begrijp het niet.
- Schaling: De schaling heb ik, zoals hierboven beschreven, vrij eenvoudig kunnen regelen. Dit punt is dus opgelost.
posted by Davy at 02:31 [edit]

---------------------------------
- Profiler Logboek
- Werksessie 1-3-2001
- D.D. de Kerf
- PC06
---------------------------------

(13:15) Zo. Na een lange tocht door de LegendaApp, wat meteen een goede grondige test was van de LegendaApp met CloneDB functionaliteit, heb ik uiteindelijk toch een aardige datadefinitie kunnen maken voor de filterstellingen. Ik moet wel zeggen dat de meeste tijd in dit proces zijn opgeslokt door het fixen van bugs uit de conversie naar LegendaApp met CloneDB functie. Blijkbaar gingen een hoop dingen nog niet goed (en dat is logisch, omdat ik een tijd geleden de app na aanpassingen niet echt grondig getest heb) en ik heb me dus ook het grootste gedeelte van de tijd besteed aan het verbeteren van de LegendaApp en het inleesmechanisme van ProfilerApp (ik heb zelfs nog een paar STF bugs gevonden en gefixt! ;-) ).
posted by Davy at 04:23 [edit]