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

HOME

Archives:

This page is powered by Blogger. Why isn't yours?
donderdag, april 26, 2001
---------------------------------
- Profiler Logboek
- Werksessie 26-4-2001
- D.D. de Kerf
- PC12
---------------------------------


(13:52) Deze ochtend heb ik het koppelmechanisme nog eens goed onder de loep genomen en de 2 koppel-gerelateerde bugs die ik gisteren melde, opgelost. Het probleem was een fundamentele, namelijk het koppelen aan de hand van de weergaveindex van kolomdata voor het koppelen van meerdere kolomdata aan 1 kolomweergave. In het koppelingsmechanisme werd dan ook eerst gekeken of de kolomdata niet al gekoppeld was aan een kolomweergave. Was dit wel al het geval, dan werd de nieuwe koppeling (in dit geval de zandmediaan) aan het bestaande kolomweergave component (in dit geval de lithologie volgens NEN) gekoppeld. Heel fout dus. Daarom heb ik kolomweergaven uitgebreid met een functie die controleert of het component meer 1 of meerdere kolomdata kan bevatten (AcceptsExtraKolomData in btaClass_KolomWeergave en een extra entry in getObj in de COM-componenten). De enige die hier TRUE teruggeeft is op het moment de boorgatinrichting component, de rest moet false teruggeven. Dit heeft het probleem opgelost!

Dat betekent dus dat de versie die er nu ligt mijn tevredenheid heeft. Hij is uiteraard nog niet door en door getest (we hebben immers geen testplan), dus de kans is groot dat er nog bugs in zitten. Ik ben echter wel in de veronderstelling dat de Profiler Lite versie die er nu ligt zeer stabiel is. De Profiler Full-Version heeft wellicht wat te leiden onder de Lite-insteek, maar dat komt allemaal nog wel aan het licht als het NITG gaat testen.

Wat nog WEL steeds moet gebeuren:
* De COM-component-specifieke instellingen in Profiler Lite (gaat niet in de DB en zal toch moeten voor het koppelen met .abm en .bst bestanden)
* Juiste vulling van de programmadatabase en het profiler lite treefile bestand!

Ik hou er voorlopig weer even mee op.


woensdag, april 25, 2001
---------------------------------
- Profiler Logboek
- Werksessie 25-4-2001
- D.D. de Kerf
- PC12
---------------------------------


(17:14) Vandaag nog wat gerommeld aan Profiler (vanaf de middag, aangezien ik 's ochtends en gisteren bezig was met SmartGuest toevoegingen die even een hogere prioriteit hadden). Heb een hoop dingen voor elkaar, maar ook weer een hoop bugs ontdekt die, volgens mij, bij het omgooien van het koppelmechanisme zijn misgegaan.

Wat het nu WEL goed doet:
* Profiler vist zijn eigen pad uit de command line en gebruikt dit om het .trf-bestand te pakken te krijgen! Zo kun je 'm netjes vanuit Boris starten vanaf elke locatie, zonder dat in diezelfde directory ook het .trf bestand moet staan.
* De tekstkolom heeft nu de goede dynamische breedte! (in user templates met 1 boring, bij meerdere boringen gaat het nog erg raar om door mij nog onbekende redenen). De echte problemen bleken erin te zitten dat de EnclosingRect van btaClass_Kolomweergave NIET GELIJK IS aan de EnclosingRect van btaClass_TekstKolomWeergave. Logisch ook, want dit zijn 2 verschillende dingen. Daarom heb ik getObj uitgebreid zodat ook de EnclosingRect van de kolomweergave ACHTER het COM-component kan worden opgevraagd. Verder nog een functie toegevoegd aan LocatieRecord (RefreshRect of zoiets) die naloopt of het EnclosingRect van het locatierecord wel net zo groot is als de enclosingrects van de kolomweergaven IN het locatierecord. Op deze manier is het SELECTIEVIERKANT bij de tekstkolomweergave in orde en wordt de kolom ook niet steeds breder bij het updaten van de kolom!

Waar ik achter ben gekomen dat NIET goed werkt:
* koppelingen na het maken van een profiel met een user template. Als ik bijvoorbeeld de lithostratigrafie eerst ONTKOPPEL en hem vervolgens terug KOPPEL crasht profiler. Ook bij het koppelen van analoge kolommen in een profiel gaat nog vanalles mis (volgens mij hebben de kolommen dan geen kolomdata gekoppeld)

Waar sowieso nog aan gedacht moet worden:
* De COM-component-specifieke instellingen in Profiler Lite (gaat niet in de DB en zal toch moeten voor het koppelen met .abm en .bst bestanden)
* Juiste vulling van de programmadatabase en het profiler lite treefile bestand!

Zo, da's een mooi overzicht van de stand van zaken, naar mij dunkt ;-) Kijken wanneer het echt af komt.


maandag, april 23, 2001
---------------------------------
- Profiler Logboek
- Werksessie 23-4-2001
- D.D. de Kerf
- PC12
---------------------------------


(15:10) Wat een waardeloze dag vandaag. Ben aan de gang gegaan met de bugs in profiler op te lossen, maar heb tot nog toe nog niets bereikt. Eerst heb ik de boornummers proberen te draaien (in de debug versie staan de boornummers netjes een halve kwartslag gedraaid, zodat er een heleboel naast elkaar afgedrukt kunnen worden, terwijl ze in de release versie waardeloos worden getekend: gewoon rechtop en als je inzoomt blijven ze gewoon even groot!), maar dit had geen enkel succes. Ik heb gebrobeerd de code te herschrijven, andere functies te gebruiken, de fonts anders te initialiseren, maar niets helpt. Hoewel ik de tekst wel kon draaien (maar de letters zelf niet) met het anders zetten van de Graphics Mode, bleeft het inzoom-probleem nog steeds bestaan. OK, zou je dan zeggen, dan maken we toch gewoon een debug versie. Ja, kan wel zijn, maar de debug versie geeft om de haverklap assert-failures bij het tekenen. Allemaal dingen om niet bepaald vrolijk van te worden.

Vervolgens ben ik me maar gaan concentreren op het verschijnsel dat alle boringen even hoog beginnen om er achter na 3 uur achter te komen dat de projectie in de sectie set er in vrijwel elke sectie set voor zorgt dat de boringen op dezelfde hoogte worden weergegeven. De functionaliteit is dus wel degelijk in orde! Fijn om te weten, maar jammer van die 3 uur zoeken (misschien was het beter geweest als ik eerst had onderzocht of wat ik zag INDERDAAD niet klopte, maar dat is natuurlijk achteraf praten).

Bovendien ben ik ook van het afsluitprobleem nog lang niet af. Ook de debug-versie geeft de gekke meldingen, maar dat gebeurt ook alleen bij de LITE-versie. Het lijkt er wel op alsof ik voor de LITE-versie alle componenten anders zou moeten compileren (met de LITE_VERSION compiler directive) en dat ze dan misschien niet crashen.... Ik heb geen flauw idee hoe dat zou kunnen komen, maar vind het wel HEEL ERG vervelend. Hmmm, ik kan natuurlijk ook gewoon de destructor uitquoten :-)

Om het lood uit mijn schoenen te krijgen ga ik maar even wat anders doen, anders wordt ik manisch depressief :-)

(17:41) Toch nog een aantal nuttige dingen gedaan en bedacht. Zo heb ik Profiler Lite eindelijk een keer aan Boris gekoppeld (Boris 3 crasht bij mij af en toe om onverklaarbare redenen, maar als ik de versie op de I gebruik gaat het in de meeste gevallen goed). Ik heb de volgende dingen over profiler (in combinatie met Boris) opgemerkt:
* Profiler moet zijn eigen pad kunnen gaan achterhalen om te weten waar het .prf bestand staat, anders moet het .prf bestand ook in de boris directory staan en dat is onacceptabel
* De PAG (nieuwe naam voor BIG) koppeling lijkt maf te zijn in de PAG User Template, omdat de inhoud van de tekstkolom leeg is. De lagen kloppen echter wel.
* Die dynamische breedte van de tekstkolom werkt nu echt niet meer, zoals hij geïmplementeerd is. Bij opstarten is-ie te kort, na één update van de kolom is-ie precies groot genoeg, maar na elke nieuwe update wordt-ie steeds groter. Moet wat aan gedaan worden
* Zou het niet mooi zijn als profiler zelf kon nagaan of er al een instantie open is? Dan hoef je niet elke keer opnieuw de programma instellingen in te lezen en kan Profiler Lite gewoon open blijven staan, achter BORIS.

Verder ook nog de irritante afsluitbug verholpen (niet gefixt!!!). De echte fout bleek op te treden in de ExitInstance van CMFischer1996LegendaComponentApp bij de aanroep van _Module.Term(). Ik heb deze nu uitgequote en alles gaat nu goed. Dit is natuurlijk geen permanente oplossing (slordig) maar het werkt wel. Geen idee waarom het misgaat. Blijkbaar ergens bij het destructen van alle members in de component.... Iets voor Han? (trouwens ook gek dat-ie alleen crasht bij Profiler Lite).

Zo. Genoeg gedaan voor vandaag.


vrijdag, april 20, 2001
---------------------------------
- Profiler Logboek
- Werksessie 20-4-2001
- D.D. de Kerf
- PC12
---------------------------------


Elke keer als je denkt er bijna te zijn blijkt dat er nog steeds een hoop niet goed zit. Vandaag ben ik begonnen met een release build te maken van Profiler zelf en alle componenten. Deze release build wou ik dan opsturen naar Bram, zodat hij alvast kon testen. Ik heb echter gemerkt dat er in de release-versie (en misschien ook wel in de debug versie) nog een hoop niet goed zit.

Hier een kort overzicht van de door mij al geconstateerde bugs/rariteiten:
* Het lijkt erop alsof alle boringen precies even hoog worden getekend, ongeacht de diepte waarop ze beginnen! Dit is een serieus probleem.
* Als ik via het profiel-eigenschappen scherm meerdere kolommen van hetzelfde component (bijvoorbeeld 2 lagenkolomweergaven, lithologie en lithostratigrafie) koppel crasht de release versie!

Bovenstaande bugs lijken vrij serieus te zijn, maar brengen de release van Profiler Lite niet in gevaar. De problemen hebben namelijk allemaal te maken met functionaliteit die niet in de Lite-versie zal zitten zoals het zelf aanbrengen van extra koppelingen en het tekenen van profielen.

Ik ga nu een release build maken van Profiler Lite om te kijken of daar ook grote problemen mee zijn.


(13:53) Ook de release build van Profiler Lite rammelt hier en daar nog wat. Het vervelendste is dat het programma crasht bij het afsluiten en dit is toch eigenlijk onacceptabel voor een applicatie die je wilt demonstreren. Ook kunnen de kolomweergave-specifieke instellingen niet worden gedaan, omdat de lijst met weergaven om de een of andere reden leeg is. Ook dit is funest omdat de gebruiker dan niet zijn eigen .ABM en .BST-bestanden kan instellen... Ik ga dit toch allemaal eerst proberen te verhelpen voor ik daadwerkelijk een versie naar Bram ga sturen.

(14:15) Oei! Vervelend probleem. De volledige versie van Profiler heeft natuurlijk een programma-database waarin de instellingen (en dus ook de activex-specifieke instellingen) kunnen worden opgeslagen. Dit gebeurt dus ook. Profiler Lite heeft die mogelijkheid echter niet. Dat betekent dat we een probleem hebben, want Profiler Lite moet natuurlijk ook in staat gesteld worden abm- en bst-bestanden te gebruiken. Misschien is een apart ini-bestand voor Profiler Lite een uitkomst, maar hierover zal ik eerst met Edwin overleggen (die is volgende week maandag na een week Oostenrijk weer terug in Breda).

(16:11) Ook die andere bug, het crashen bij het afsluiten, krijg ik niet opgelost. Het gaat mis bij het releasen van niet-gebruikte com-componenten in de ExitInstance van CProfilerApp en het heeft hoogst waarschijnlijk iets te maken met de weergavenpatronen, want als ik de weergavenpatronen NIET aanmaak (en dus ook niet verwijder), crasht-ie niet. Het gekke is, dat de weergavepatronen net zo geïmplementeerd zijn als de andere com-componenten (zoals kolomweergave). Ik tast in het duister! Maar nu neem ik een welverdiend weekend ;-)



donderdag, april 19, 2001
---------------------------------
- Profiler Logboek
- Werksessie 19-4-2001
- D.D. de Kerf
- PC12
---------------------------------


Eigenlijk al veel te lang niet meer gelogt vanwege de stapel werk die er nog lag en de naderende deadline. Wel heb ik het grootste gedeelte van de afgelopen maand besteed aan Profiler en dan met name de tekstkolomweergave component, algemene functionaliteit die nodig was voor Profiler-Lite en het afdrukken van profielen over meerdere pagina's.

Om te beginnen bij de dingen die nog open stonden bij mijn laatste log, een aantal bugs die zijn omschreven zijn nu gelukkig opgelost. De bug bij koppelingen als je meerdere profielen aanmaakt in 1 profiler sessie was een pittige. Uiteindelijk kwam ik erachter dat het mis ging omdat de overload van de toekenningsoperator (=) bij de klasse cDocIni nooit echt goed heeft gewerkt. De koppelingen (stringlists) werden niet goed meegekopieerd, waardoor het dus helemaal misging. Deze bug is nu wel gefixt.
Een andere bug waar eerder sprake van was, was het verloren gaan van de koppelingen na het inlezen van een opgeslagen file. Hier heb ik verder nog niet naar gekeken, maar de kans bestaat dat deze bug door de bugfix die hierboven is beschreven, ook is opgelost.



Profiler Lite

Aangezien in Profiler Lite profielen zo makkelijk mogelijk moeten kunnen worden gemaakt, moet je zoveel mogelijk kunnen regelen in de user template. Bij mijn missie om een goede user template te maken kwam ik een hoop rare dingen tegen:

- Vreemde bugs. Als bepaalde waarden in de user template niet werden gezet, ging het bij het opstellen van het profiel gigantisch mis. Schaling ging de mist in, koppelingen werden belachelijk gelegd of Profiler crashte gewoonweg. De oorzaak hiervan lag bij het feit dat alle instellingen van de user templates wel geprogrammeerd zijn, maar niet goed doorgetest. Zo was de schaling helemaal wazig als je in de user template de mogelijkheid om de schaling aan te passen, uitschakelde. De meeste problemen lagen dan ook in het wizard/optiescherm van het profiel. Hierin zat hier en daar functionaliteit die uitgevoerd moest worden om het profiel correct op te bouwen. Erg vervelende zaken allemaal, maar stuk voor stuk heb ik alle bugs die ik tegenkwam gefixt.

- Kolom-afhankelijke instellingen. In de oude user templates was het niet mogelijk om kolom-specifieke instellingen te realiseren. En ik had sowieso een kolom-specifieke instelling nodig, namelijk het automatisch weergeven van volgnummers van lagen in de lagenkolom component. Omdat het in de oude implementatie niet mogelijk was, heb ik de user templates uitgebreid, zodat ze ook instellingen van de kolomweergave componenten kunnen bevatten. Hiervoor heb ik een generiek mechanisme bedacht, waarbij het kolomweergave component (een COM-component) in de vorm van een string zijn mogelijke instellingen aan Profiler doorgeeft. De mogelijke instellingen van de Y-schaal component zien er bijvoorbeeld als volgt uit:

2001\tBOOL\tTRUE\tY-schaal Weergeven\tTRUE of FALSE\n
2002\tLONG\t1\tHoogte of diepte\t0 = Diepte weergeven, 1 = Hoogte weergeven\n"
2003\tSTRING\tcm\tEenheid\tmm, cm, dm, of m


Dit betekent het volgende:
2001: het nummer waaronder de parameter gezet kan worden met de setObj-functie van het kolomweergave component
BOOL: het type van de parameter. Mogelijke waarden zijn BOOL, LONG en STRING
TRUE: de initiële waarde
Y-schaal Weergeven: omschrijving van wat de parameter doet
TRUE of FALSE: omschrijving van de waarden die ingevuld kunnen worden

In de docIni wordt nu een lijst met stringlists bijgehouden, één stringlist voor elk component waarvoor parameters zijn ingesteld. Zo kun je per weergavecomponent (dus ook de Y-schaal weergave! :-)) opgeven wat de instellingen moeten zijn bij het gebruik van de user template.



Tekstkolom Weergave Component

Ook de tekstkolom weergave component is nu af. Hier moest alleen de daadwerkelijke invulling van de goede tekst nog worden bijgeprogrammeerd. Hiervoor is Edwin begonnen met het isoleren van de juiste code uit de bestaande BORIS 'Boorstaat Printen Module'. Hij had het echter te druk en heeft mij na enkele uren het werk toevertrouwd. Uiteindelijk was het mogelijk om via één functie de rauwe data van een laag (bijvoorbeeld "G=Z ZM=125") om te zetten naar menselijk leesbare tekst (bijvoorbeeld "uiterst siltig, grijs-groen").
Het probleem was echter dat, vooraleer deze functie goed kon werken, een drietal instellingen nodig waren:
1) Het aanmaken van een cBoorstaat object. Dit object bevat informatie over hoe de gegevens weergegeven moeten gaan worden. Deze informatie haalt het object uit een .bst-file dat met de Boorstaat Printen module kan worden gemaakt. Aangezien gebruikers hun eigen .bst-bestanden kunnen hebben, moet het mogelijk zijn om dit file (met pad en al) in te kunnen stellen.
2) Het aanmaken van een cBoorBeschrijvingsMethode object. Dit object bevat informatie over de mogelijke typen data (bijvoorbeeld dat G staat voor Grondsoort). Deze informatie haalt het object weer uit een .abm-file wat ook door BORIS gebruikt wordt bij het invoeren van data. Aangezien er vele abm-bestanden mogelijk zijn en mensen hun eigen abm-file kunnen hebben, moet het ook hier weer mogelijk zijn om het .abm-bestand (met pad en al) in te kunnen stellen.
3) Het zetten van de kolomgroep. Aangezien abm-files meerdere kolomgroepen kunnen bevatten (denk bijvoorbeeld aan lithologie, lithostratigrafie en nieuwe lithostratigrafie), moet ook nog even worden aangegeven welke kolomgroep gebruikt moet worden. De aangegeven kolomgroep moet dan wel in het .abm- en .bst-bestand voorkomen.

Zoals alweer duidelijk wordt moeten er een aantal dingen ingesteld kunnen worden. Dit willen we niet run-time doen (anders moet de gebruiker zelf nog elke keer de files gaan specificeren) en eigenlijk ook niet in een user-template stoppen (anders moet je immers voor elke user template dezelfde instellingen weer toevoegen). Daarom is besloten Profiler uit te breiden met een 'statische instellingen'-scherm. Met dit scherm is het mogelijk om voor DE HELE PROFILER SESSIE een aantal instellingen (kolomweergave specifiek) in kunnen doen. Dit mechanisme heb ik net zo geïmplementeerd als de hierboven beschreven kolomweergave-specifieke instellingen in de user-templates. Het enige verschil is dat er een extra scherm is (met vrijwel dezelfde implementatie als hetzelfde scherm voor de user-templates) en dat de instellingen niet worden opgeslagen in het cDocIni object, maar in btaClass_Main. Uiteraard worden de instellingen wel weggeschreven naar de profiler database.

De tekstkolom weergave component maakt gebruik van de statische instellingen door 3 parameters aan te bieden:
1) Koppelingen tussen datadefinitie en .bst-file, waar je per datadefinitie aan kunt geven welke .bst-file gebruikt moet worden.
2) Koppelingen tussen datadefinitie en .abm-file, waar je per datadefinitie aan kunt geven welke .abm-file gebruikt moet worden.
3) Koppelingen tussen datadefinitie en kolomgroep, waar je per datadefinitie aan kunt geven welke kolomgroep gebruikt moet worden.

Voor deze 3 parameters zijn ook 2 extra typen toegevoegd aan het statische-parameter verhaal in de kolomweergave componenten, namelijk:
DD_FILE voor het opslaan van koppelingen tussen datadefinities en files (1 op 1)
DD_STRING voor het opslaan van koppelingen tussen datadefinities en string (1 op 1)

Er blijft echter nog 1 kleine slordigheid ingebouwd in de tekstkolomweergave component, namelijk bij selectie. Omdat tekst kolomweergaven zichzelf zo breed maken als binnen het profiel (of binnen de pagina) mogelijk is, is nooit echt bekend hoe breed de kolom is. Om de een of andere vage reden is het selectievierkant van de kolom dan ook kleiner dan de werkelijke breedte. Ik heb veel gedaan om dit probleem op te lossen, maar ben er tot op heden nog niet in geslaagd.



2 Programma Databases

Een tijd geleden dacht ik het probleem van meerdere programma databases opgelost te hebben met de STF-functionaliteit 'CloneDB'. Ik had zelf echter al gezien dat het ook een hoop nadelen had en na een gesprek met Bram werd duidelijk dat het zo eigenlijk niet acceptabel was. Het was immers niet mogelijk om vanuit de secundaire database te verwijzen naar records in de primaire database. Om deze reden kon je bijvoorbeeld ook niet je eigen datainterpretatie maken bij een bestaande datadefinitie die in de primaire database stond.
Daarom hebben we besloten om het mechanisme te wijzigen in een 'synchronisatie-strategie', waarbij de secundaire database gesynchroniseerd kan worden met de primaire database. Dit betekent dat de inhoud van de primaire database altijd aanwezig is in de primaire database zelf, maar ook in de lokale, secundaire databases. Deze strategie had ook nog een aantal andere voordelen die, samen met de werking, zijn uitgelegd in het document dat op het moment dat ik dit schrijf 'Meerdere Programmadatabases (Sync vs. CloneDB)' heet en aanwezig is in de projectdirectory van Profiler (2001-03.DEK Profiler) staat.

Omdat het synchroniseren (wat een onderdeel van STF 4.1 geworden is) nogal lang kan duren heb ik het mechanisme in Profiler (btaClass_LegendaSetManager) voorzien van een progress bar (die sindsdien opgenomen is in de BTA Window Factory) en een duidelijk aanduiding in de system tray (2 databases met een pijl ertussen). Ook heb ik de mogelijkheid ingebouwd om het automatisch synchroniseren aan en uit te zetten (in het 'programma databases' instellingen scherm).



Printen over meerdere pagina's

Een laatste probleem was dat boorstaten zo hoog konden worden, dat ze niet meer op 1 A4-tje passen. Daarom moest het mogelijk worden om ook Profiler over meerdere pagina's te kunnen laten printen, zoals ook de BORIS module 'boorstaat printen' dat al kon. Bij Profiler ligt het echter wel wat anders en dat betekende dus uitzoekwerk en ploeteren.

Tenslotte is het mij (gisteren en vanochtend) uiteindelijk gelukt om dit toch (relatief simpel!) voor elkaar te krijgen. Bij het printen krijg je namelijk een STRUCT mee waarin precies wordt aangegeven welke pagina er op dat moment geprint wordt. Door het verschuiven van de ViewPort van de Device Context naar de juiste plaats was het zo mogelijk om telkens een ander stukje van het profiel te printen. Hiervoor moest ik wel een hoop uitproberen en goochelen met units (device- en logical units en de schaling die voor het printen zelf wordt gebruikt en mij niet bekend is in welke eenheid).

Tenslotte heb ik het printen zelfs zo mooit gemaakt dat niet alleen in de hoogte, maar ook in de breedte een profiel kan worden verspreid over meerdere pagina's. Op deze manier kun je met je A4-printer ook juist geschaalde grote profielen uitprinten. Het printproces begint linksboven en gaat van links naar rechts alle 'lagen' van het profiel af. Als extraatje heb ik ook het selectievierkant uitgezet tijdens het printproces. Dit was eerst namelijk niet zo, waardoor ook de selectie op dat moment werd afgedrukt in de vorm van een vierkant van stippellijnen.




Status Quo: op 19-4-2001:
- Profiler Lite. Wat mij betreft is Profiler Lite 'ready to go'. We moeten alleen nog wel even een export maken van de juiste gegevens naar een tree-file. Dit moet in overleg met Edwin en misschien ook Bram.
- Tekst Kolom Weergave: Is volgens mij af
- Meerdere programma databases. Is af (dankzij het synchronisatie mechanisme)
- Printen over meerdere pagina's. Is af

- Kleine slordigheden. Het selectievierkant van de tekstkolomweergave en koppelingen na het openen van een opgeslagen profiel
- BORBG datadefinitie. Moet nog aangeleverd worden door TNO
- Nieuwe VAX legenda. Moet nog aangeleverd worden door TNO

- Release. Ready, Willing and Able! Volgens mij zijn we klaar voor een succesvolle release van in ieder geval Profiler Lite en een stabielere en uitgebreidere versie van Profiler (volledig)!


Update Status Quo anno 14-3-2001:
- Profiler bug: koppeling bij meerdere profielen in 1 sessie. Gefixt!
- Profiler bug: koppelingen na openen opgeslagen profiel. Misschien ook gefixt, maar dat heb ik nog niet gecontroleerd.