Actie op verjaardagsdatum

[Organeduc]

In een veld hanteren wij een ID op personen die als volgt wordt geformuleerd:

40385005 of 310884003 of 70183008, waarbij de laatste 3 cijfers aangeven de hoeveelste in de rij het is van de eraanvoorafgaande 5 of 6 cijfers die dag-maand-jaar aangeven waarop iemand geboren is.

In de resp. gevallen dus: 4 maart 85 nr. 005, 31 augustus 84 nr 3 of 7 januari 83 nr. 8.

Wanneer nu iemand zijn 18-de levensjaar nog niet bereikt heeft, zou ik dit ID graag automatisch in een andere kleur willen zien verschijnen. Of: de kleur van dit veld moet veranderen vanaf de dag dat iemand 18 jaar is geworden.

Is dat mogelijk? Kan iemand me daarbij helpen?

Alvast mijn hartelijke dank.

[AvD]

Eerst een vraagje, vooraleer we iedereen op het verkeerde spoor laten vertrekken.

Ben je - in het eerste voorbeeld - zeker dat je de vierde dag voorstelt als "4" (één digit) terwijl de derde maand een voorloop-nul krijgt?

Dat is al een relevant gegeven als je de datum wil isoleren uit je nummer!

De rest lijkt me een schitterende oefening voor de studenten van Jean.

[JeanWM]

De rest lijkt me een schitterende oefening voor de studenten van Jean.

 

Alhoewel het hier de 7 is hebben ze toch een poging ondernomen in de 6.

 

Het heeft eigenlijk weinig belang of er een «voorloopnul» staat (vinden ze, maar dat werd een discussieonderwerp).

Een veldje met het nummer.

 

Een calcveld

 

dateOutOfNumber_cd :

Date(

Case(

Length(number) = 8;

Middle( number;2; 2)

) ;

Case(

Length(number)=8;

Middle( number; 1; 1)

) ;

Case(

Length(number) =8;

"19" & Middle( number; 4; 2);

Middle( number; 2; 2) ;

Middle( number; 1; 2) ;

"19" & Middle( number; 4; 2)

))

 

Een «flag» veld :

flag_c = Year(Status( CurrentDate)) - Year(dateOutofNumber) >= 18

 

Een globaaltje met twee kleurtjes.

Een berekeningsveld als container dat achter het date veld geplaatst wordt :

more18_cgco = Case(

flag = 1;

GetRepetition( color_gc; 2);

GetRepetition( color_gc; 1)

)

 

Ik post het hier zonder meer zoals ik het gekregen heb. Met 1 uitzondering : het was eerst allemaal verwerkt in 1 script, vermits we aan het 'script' hoofdstuk bezig zijn, ik had het graag ook in gewone 'veldvorm'.

Is voor verbetering vatbaar, er wordt aan gewerkt...

Credit to Yajaria en Armando.

parsingClar.fp5.zip

[Sanne]

Bij het invullen van het ID "310884003" - een voorbeeld uit de "opgave" - (de derde persoon met geboortedatum 31 augustus 1984) levert de formule voor "dateOutofNumber" de datum "30-11-0030".

Dat lijkt mij het eerste punt wat voor verbetering vatbaar is.

 

flag_c = Year(Status( CurrentDate)) - Year(dateOutofNumber) >= 18

Deze formule houdt geen rekening houdt met de verjaardag van de persoon.

 

Dat lijkt mij het tweede punt ter verbetering.

 

Misschien met de studenten nog eens de procedure van debuggen en testen doornemen?

[Organeduc]

Excuus voor plaatsing in de 7 terwijl het inderdaad in mijn geval om de 6 gaat.

In antwoord op de vraag van AvD:

Ben je - in het eerste voorbeeld - zeker dat je de vierde dag voorstelt als "4" (één digit) terwijl de derde maand een voorloop-nul krijgt?

Ja!!

Maar, is het niet eenvoudig om, als een getal soms uit slechts 8 cijfers bestaat in plaats van consequent uit 9, voor dat getal automatisch een 0 te laten toevoegen waardoor de datum er als de eerste zes cijfers uit te halen is?

 

Testen van wat er nu van Jean komt, levert op, dat een en ander soms werkt, maar soms ook niet. Dat heb ik geprobeerd bij de maanden bijvoormeeld.

Overigens, nog mooier zou ik vinden, als er niet een groen of geel veld ontstaat, maar dat de cijfers van de getallen, die de datum aangeven in rood verschijnen, wanneer blijkt dat de persoon nog geen 18 jaar oud is. Ik vraag nog al wat geloof ik, maar toch...

 

Voor de rest volg ik met spanning het werk van Jean en zijn studenten. Voor mij is het voorlopig even geloven en hopen. Het liefhebben volgt dan later wel.

[Sanne]

Excuus voor plaatsing in de 7 terwijl het inderdaad in mijn geval om de 6 gaat.

Om verdere verwarring te voorkomen is dit onderwerp nu naar het juiste forum verhuisd.

[JeanWM]

Yajaria en Vicky hebben zich er vandaag aan gezet.

 

Ze gingen ervan uit dat de laatste drie cijfers altijd het 'lijstnummer' zal zijn.

 

Verder hebben ze er gebruik van gemaakt om het bestandje ook 'rijp' te maken voor een andere toepasing.

 

Het nummer invullen en de leeftijdslimiet zou voldoende moeten zijn voor zowel de layout met de berekeningsvelden als voor de layout met het script.

 

Hou er rekening mee dat het eerder de bedoeling is om zoveel mogelijk zaken toe te passen die tijdens de amper 8 lessen werden gezien.

 

Maar...oops, ik zie nu dat de datum in het ID nummer in een andere kleur zou moeten komen....

wel...de aanzet is toch al gegeven...voor het overige zal dat in de 7 kunnen...in de 6 zie ik zo vlug geen pasklare oplossing, of het zou de achtergrond moeten zijn....

Met merge is ook wel iets aan te vangen...geef ons nog wat tijd.... We vinden het wel..tomorrow is an other day....

ClarifyParse.zip

[Konkel Noen]

In een veld hanteren wij een ID op personen die als volgt wordt geformuleerd:

40385005 of 310884003 of 70183008, waarbij de laatste 3 cijfers aangeven de hoeveelste in de rij het is van de eraanvoorafgaande 5 of 6 cijfers die dag-maand-jaar aangeven waarop iemand geboren is.

In de resp. gevallen dus: 4 maart 85 nr. 005, 31 augustus 84 nr 3 of 7 januari 83 nr. 8.

Wanneer nu iemand zijn 18-de levensjaar nog niet bereikt heeft, zou ik dit ID graag automatisch in een andere kleur willen zien verschijnen. Of: de kleur van dit veld moet veranderen vanaf de dag dat iemand 18 jaar is geworden.

Is dat mogelijk? Kan iemand me daarbij helpen?

Alvast mijn hartelijke dank.

 

 

Ik zou het ID aanmaken in het voor mij meer logisch formaat 'yyyymmddnnn'

vb. 19850304005

Het rekenen met ID's lijkt mij dan eenvoudiger.

Maar wie ben ik ... ?

[JeanWM]

Allee vooruit....

 

Vicky heeft het voor mekaar gekregen....

 

Datum in het ID wordt in rood weergegeven....

ClarifyParse02.zip

Edited December 3, 2004 by Guest

[Rony Rabijns]

Ik zou het ID aanmaken in het voor mij meer logisch formaat 'yyyymmddnnn'

vb. 19850304005

 

Tuurlijk, om nog maar te zwijgen van alle andere voordelen die deze notatie met zich meebrengt.

[JeanWM]

Moeten we alles herbeginnen ¿?

Of is een verandering van de velden voldoende ¿?

[Organeduc]

Ik zou het ID aanmaken in het voor mij meer logisch formaat 'yyyymmddnnn'

vb. 19850304005

Ik denk er zelf niet anders over, maar moet soms gebruik maken van dat wat me wordt aangeleverd, om wat voor reden dan ook.

Vicky heeft het voor mekaar gekregen....

Pluim voor Vicky, tot nu toe werkt het goed. Mijn allerhartelijkste dank.[/img]

Edited December 5, 2004 by Guest

[Organeduc]

Ik zou het ID aanmaken in het voor mij meer logisch formaat 'yyyymmddnnn'

vb. 19850304005

Het rekenen met ID's lijkt mij dan eenvoudiger.

Maar wie ben ik ... ?

Ik denk er zelf niet anders over, maar moet soms gebruik maken van dat wat me wordt aangeleverd, om wat voor reden dan ook.

Pluim voor Vicky, tot nu toe werkt het goed. Mijn allerhartelijkste dank.

[Organeduc]

In de vorige twee berichten heb ik wat zitten knoeien. Excuus als ik daar iemand tekort mee doe.

Ik wil nog een stapje verder, of misschien wel teruggaan:

Wanneer ik de lijst met namen en daarin de ID open, zou ik graag willen zien, dat, zonder dat ik daarvoor eerst een leeftijd moet invullen, de cijfers van de leeftijd van de mensen automatisch rood kleuren, wanneer zij op de systeemdatum nog geen 18 jaar zijn.

Daarnaast zou ik graag in een nieuwe layout van een gerelateerde tabel een datumveld willen opnemen, waarbij de leeftijd van de weer te geven personen opnieuw automatisch rood wordt, wanneer zij op de ingegeven datum op de gerelateerde tabel nog geen 18 jaar oud zijn.

Eigenlijk zijn dit twee verschillende berekeningen dus.

Ik hoop, dat ook dit weer lukt, zonder dat jonge mensen er hun tanden op stuk bijten.

[Organeduc]

Een vraag aan Jean.

Ergens in het forum heb ik eens een methode gezien waarmee je velden benoemt en er een code aan toevoegt, zodat je bij meer uitgebreide toepassingen, vrijwel meteen weet met wat voor een soort veld je te maken hebt. Zoiets als c_veldnaam voor een gecalculeerd veld met de naam veldnaam. Ik merk in de scripten en in de oplossing, dat er veel van dit soort codes toegevoegd zijn aan veldnamen, zowel als prefix, als als suffix.

(Enkele voorbeelden: numberParse_cn en sc_targetYear)

Zou je me kunnen aangeven wat de codes betekenen, die er door je studenten in de velden gebruikt worden? Dat geeft me weer wat meer inzicht in waar ik mee bezig ben. Alvast mijn dank

[JeanWM]

... dat, zonder dat ik daarvoor eerst een leeftijd moet invullen, de cijfers van de leeftijd van de mensen automatisch rood kleuren, wanneer zij op de systeemdatum nog geen 18 jaar zijn.

 

Vervang de verwijzing naar de valuelist met de leeftijd door een vaste waarde.

 

Daarnaast zou ik graag in een nieuwe layout van een gerelateerde tabel een datumveld willen opnemen, waarbij de leeftijd van de weer te geven personen opnieuw automatisch rood wordt, wanneer zij op de ingegeven datum op de gerelateerde tabel nog geen 18 jaar oud zijn.

 

Plaats het numberveld of het datumveld op die layout....

 

Zou je me kunnen aangeven wat de codes betekenen, die er door je studenten in de velden gebruikt worden?

 

Iedere ontwikkelaar heeft zo’n eigen manier voor veldbenamingen.

Wat de beste manier is ¿?....ik zou het niet weten, gebruik de manier waar jij je het beste mee voelt...

 

In ’ t kort wat wij gebruiken :

Basis is, probeer met de veldbenaming genoeg informatie te geven dat het voor jouw ‘herkenbaar’ is, ook na maanden.

In iedere toepassing worden wel velden gebruikt voor het ‘aansturen’ van het geheel.

bv. creation date, creation time, modification date, found count, constant, message, icons enz.

Zo hebben we een 40-tal velden die altijd in onze toepassingen terug te vinden zijn. (niet in kleine testtoepassingen natuurlijk)

 

Daarvoor gebruiken wij onderverdelingen in de veldbenamingen die met een ‘z’ beginnen.

Bij het sorteren op de veldnaam, worden al die ‘developmentvelden’ onderaan de lijst geplaatst.

Sommige ontwikkelaars gebruiken bv een ‘voorloop’ g_ voor het aangeven van global fields. Persoonlijk ben ik daar niet voor, omdat bij de sortering die velden tussen de ‘user fields’ terecht komen.

Bij het ‘z’ gebruik dienen we enkel rekening te houden met het feit dat geen enkel user field met een ‘z’ begint. Dus geen ‘zipcode’ voor het postnummer bv...

 

Zo zijn er de ‘interface’ velden, die in de afdeling ZI --- Interface --- terechtkomen.

De navigatie icoontjes komen in het veld : zi_recNavIcon_gcor

zi = interface

recNavIcon = record navigatie iconen

g = global

co = container

r = repeat

 

De zc komen in de ‘ZC ---Controle’ afdeling :

zc_recFound_cnu

zc = controle

recFound = records found

c = calculation = Status( CurrentFoundCount)

n = result number

u = unstored

 

De zk komen in de ‘ZK --- Keys’ afdeling

zk_constant_cni

zk = key

constant = constant value

c = calculation

n = result number

i = indexed

 

De zv komen in de ‘ZV --- Variable’ afdeling

zv_counter_gnr

zv = variable

counter = counterfield

g = global

n = number

r = repeat

 

Op die manier weet je ook het resultaat, maar ook wat het resultaat ‘moet’ zijn, omdat je die veldbenamingen eigenlijk eerst in je logical tabel, je data model en je relational tabel gebruikt. Dus voor je eigenlijk in FM met de aanmaak van velden begint. Omdat je bij de opmaak van die modellen al gaat bepalen of je een veld bv. moet indexeren, of unstored moet zijn enz.

Zo zijn er verschillende ‘standaarden’ te vinden. Google even rond.

Coresolutions heeft een pdf uitgave op http://www.coresolutions.on.ca/filemaker/standards.php

 

Indien een gewoon user field aanleiding kan geven tot ‘twijfel’ geven we dit ook een aanduiding.

Met bv dateBirth, weet je dat het een datumveld is.

Bij dateAttend weet je dat ook, alleen betreft het hier een global date field, dus wordt de veldbenaming : dateAttend_gd

 

We gebruiken geen spatie bij de veldbenaming omdat dit soms aanleiding kan geven tot fouten indien je het geheel naar andere platformen moet overbrengen die geen spatie in veldbenamingen aanvaarden, en ieder woord, behalve het eerste, begint met een hoofdletter.

 

Is allemaal vatbaar voor eindeloze discussies wat ‘het’ beste is.

Voor mij komt het erop neer een methode te gebruiken waar je zelf altijd aan uit kunt, zelfs na jaren. Het betreft per slot van rekening je eigen creaties.....

[Organeduc]

Jean,

Allereerst mijn dank voor je aanwijzingen.

Allertweedst dank voor je antwoord op mijn vraag naar de codes.

Is allemaal vatbaar voor eindeloze discussies wat "het" beste is.

Wie ben ik om deze discussie aan te gaan. Die autoriteit heb ik nog niet.

Mijn hartelijke dank voor je uiteenzetting en de verwijzingen die je me gaf.