menno

Curl wordt niet standaard in Windows geïnstalleerd, maar het bestaat wel. Je moet het dus ergens neerzetten en de meest gemakkelijk manier voor jou in het programma is wanneer je de curl.exe in %root%\Windows of in %root%\Windows\System32 plaatst. Dan hoef je het pad naar Curl niet op te geven in je command-line en/of je omgevingsvariabelen van Windows niet aan te passen. Ergens inje netwerk neerzetten voor iederen te gebruiken is een andere mogelijkheid, maar dan moet het hele unc-pad meegeven én je hebt mogelijk gezeur met de lokale firewall. Ftp zit overigens wél standaard in windows ingebakken, maar daar praat je op een andere manier mee dan met Curl

Ik heb een tijd terug eens een CF gemaakt waar een datum kan worden geformatteerd volgens een patroon dat je opgeeft. In het voorbeeld dat ik geef is de taal bijvoorbeeld alleen maar Nederlands, maar dat zou je ook gemakkelijk meertalig kunnen maken. In een formule zou je dan FormatDate ( datum ; formaat ) opnemen. Formaat zou dan kunnen bevatten bijvoorbeeld "YYYYMMDD" met de datum van vandaag wordt dat 20151208 of "t d B YYYY" wordt dan dinsdag 8 December 2015 etc. De functie gemakkelijk aan te passen of uit te breiden. (let op de volgorde van vervangen, bijvoorbeeld b is geen willekeurige keuze voor de maandnaam, er is geen dagnaam waar een b in staat) Let ( [ dd = GetAsDate ( thedate ) ; dag = Choose ( DayOfWeek ( dd ) ; "" ; "zondag" ; "maandag" ; "dinsdag" ; "woensdag" ; "donderdag" ; "vrijdag" ; "zaterdag" ) ; d = Day ( dd ) ; m = Month ( dd ) ; maand = Choose ( m ; "" ; "januari" ; "februari" ; "maart" ; "april" ; "mei" ; "juni" ; "juli" ; "augustus" ; "september" ; "oktober" ; "november" ; "december" ) ; y = Year ( dd ) ] ; If ( dateformat ≠ "?" ; Substitute ( dateformat ; [ "dd" ; Right ( "0" & d ; 2 ) ] ; [ "mm" ; Right ( "0" & m ; 2 ) ] ; [ "yyyy" ; Right ( y ; 4 ) ] ; [ "DD" ; Right ( "0" & d ; 2 ) ] ; [ "MM" ; Right ( "0" & m ; 2 ) ] ; [ "YYYY" ; Right ( y ; 4 ) ] ; [ "d" ; d ] ; [ "m" ; m ] ; [ "yy" ; Right ( y ; 2 ) ] ; [ "D" ; d ] ; [ "M" ; m ] ; [ "YY" ; Right ( y ; 2 ) ] ; [ "Y" ; Right ( y ; 4 ) ] ; [ "y" ; Right ( y ; 4 ) ] ; [ "t" ; dag ] ; [ "T" ; Proper ( dag ) ] ; [ "b" ; maand ] ; [ "B" ; Proper ( maand ) ] ) ; "d = dagnr¶m = maandnummer¶yy = jaar 2 cijfers¶y/yyyy = jaar 4 cijfers¶t = dagnaam¶b = maandnaam" ) )

Gaat het hier nog over jouw race-database of ben je met nog iets anders bezig? Wat je hier wilt lijkt me namelijk wat onzinnig voor een DB waar je race-geschiedenis in vastlegt. Het zou dus wel zo handig zijn als je even vertelt wat je exacte doel is. Ik zou iets als dit alleen gebruiken in bijvoorbeeld een orderverwerking, een handleidingen generator of iets anders professioneels.

Ook hier moet je m.i. ook normalisatie toepassen: een nederlandstalig record en een engelstalig record aanmaken. Je komt dan wel weer nieuwe problemen tegen zoals hoe dan snel zoeken enzo ... Ik heb wel een idee, maar daar heb ik nu ff geen tijd voor, ik maak vanavond wel fii een voorbeeldje

Kijk nog eens goed naar mijn voorbeeld, daar heb je alleen maar een table-occurrence nodig .... geen relatie net zoals bij jouw eigen oplossing. Het voordeel van mijn methode is dat je niet continue tig $$-variabelen hebt geladen. Op zich is het natuurlijk helemaal geen probleem wanneer het wél zo is, maar zodra je de data-viewer gaat gebruiken, dan is dat toch anders en wat gebeurt er wanneer je in de scripts een variabele gebruikt met eenzelfde naam die al is gebruikt voor een label?

You're welcome Willem. Ik heb het voorbeeld nog een heel klein beetje aangepast. De talen staan nu in een aparte tabel, zodat je het script om de vertalingen-tabel niet meer hoeft aan te passen wanneer je een taal wilt toevoegen . In plaats daarvan voeg je een taal toe in die tabel en trap je het script af om de Translations-tabel aan te vullen.

In dit draadje op het forum wil de vraagsteller graag verschillende talen kunnen instellen. Hij had zelf op modular filemaker een voorbeeld(artikel) gevonden, maar dat was niet helemaal wat hij zocht en misschien is de daar voorgestelde methode net niet helemaal flexibel genoeg. Ik vond het ook niet helemaal ideaal en gebruik zelf een andere (door mij bedachte) methode die ik in een voorbeeld heb gegoten en heb gepubliceerd op mijn eigen blog uiteraard is er weer een download beschikbaar die jullie kunnen bekijken.

Ik heb over dit onderwerp even een blog-post gemaakt, dat is eenvoudiger uitleggen en voorbeelden geven. Kijk maar naar het artikel op mijn blog en download daar het voorbeeldbestand dat ik er bij heb gemaakt. Aanmelden is beslist niet nodig, tenzij je daar wilt reageren . Vragen erover kan je gerust hier op clarify stellen, want er zijn hier genoeg mensen die je er mee willen helpen.

Hier worden (globale) variabelen gebruikt als veldlabels. Je kan dat op 2 manieren doen: De variabele(n) instellen en daarna naar de layout gaan of De variabele(n) instellen en dan de layout verversen. De layout verversen kan op legio manieren zoals refresh-window, even naar preview en weer terug, een nieuw record aanmaken, naar een ander layout en weer terug etc. Een andere methode is een tabel met alleen globale velden maken (die hoeft dus ook maar één record te hebben). Je geeft die tabel een Table-Occurrence naam van slecht één letter, bijvoorbeeld "T". Je hoeft geen enkele relatie te leggen naar die tabel, omdat de velden allemaal global zijn Daarna gebruik je die velden gewoon exact zoals merge-velden overal op je layouts als: <<T::veldnaam>> ipv <<$$LabelNaam>> Je kan nu bij het opstarten van je solution even in een scriptje alle labelvelden instellen met de gewenste taal, daarna kan je het weer "vergeten". Het voordeel van deze methode is dat je niet zo'n idioot grote hoeveelheid $$-variabelen hebt

Dag Hans, behalve dat er in de query een denkfout zit (je zou moeten zoeken op: GetAsText ( Get ( HuidigeDatum ) - 7 ) & " *:*:*" ) lijkt het er op dat je ook nog de scriptstap verkeerd zit in te vullen. Ik zie staan Selectie instellen [ BezoekData : : BezDatum[ 1 = GetAsTimestamp ( Get (Huidigedatum) ) - 7 *86400) ) en ik mis de stap dat je naar de zoek-modus toe gaat. (maar misschien zit je daar al in en heb ik daar dus niks over gezegd). Je moet niet Selectie instellen maar je moet Veld Instellen:

In welke verzie van FM en welke versie van Windows werkte dat dan nog? Welke scriptstappen gebruikte je daarvoor? GoTo-Object ["WebViewerName"] en dan Copy[] oid? Of gebruik je GetLayoutObjectAttribute( "WebViewerName" ; "Content" ) (zie ook GetLayoutObjectAttribute op FileMakerTips)

Een tijdstempel en een datumveld zijn "onderwater" gewoon getallen. Het verschil dan dat een datum het aantal dagen weergeeft dat is gestart sinds 1-1-0001 0:00 een tijdstempel start op hetzelfde moment, maar geeft het aantal seconden weer. 1 dag is 86400 seconden, dus als je wilt zoeken zoals jij voorstelt dan moet je dat als volgt doen doen: GetAsTimeStamp ( Get ( CurrentDate ) ) - 7 * 86400

Dat zou best eens kunnen, maar dat kan ik morgen pas testen. Best idioot dat dat een lay-out eigenschap is, want voor alle andere toestanden moet je wél van alles in de inspector instellen. Anyway dank voor de tip, ik ga er morgen meteen naar kijken!

Ik doe het bijna nooit, maar vandaag wilde ik eens een kader om een tekstveld afdrukken. Dus in de inspector even in de eigenschappen van het veld de omranding aangezet, zwart, 2 punten dik .... Prachtig te zien in bladermodus. Echter in preview en bij het afdrukken is het kader weg! Uiteindelijk heb ik maar een losse rechthoek om het veld getekend en die wordt wél afgedrukt. Het lijkt me echter dat ik dat zou moeten hoeven te doen, dus mijn vraag hoe stel ik dat dan wel voor het afdrukken in? Het theme van de layout is enlightened oid.

Ik heb meerdere keren ervaren dat wanneer je géén commit doet, het record nog niet is weggeschreven en je er niet op kan queriën of een relatie naartoe kan leggen/gebruiken. Je kan op de lay-out instellen dat records automatisch moeten worden ge-commit zodra je die lay-out verlaat. Vergeet je dat of laat je om wat voor reden dan ook het venster met die lay-out open dan krijg je niet altijd het antwoord van de database dat je verwacht als bijvoorbeeld een pk opvraagt en daarmee een relatie wilt leggen. Door standaard te commiten voorkom je dat probleem

Ik heb even het eea getest en kom tot exact deselfde bevindingen. Ik denk daarom dat dit een regelrechte bug is en heb er op de website van fmi een bugmelding van gemaakt. Mvg, Menno

Hieronder de code van hoe je zo'n record zou kunnen aanmaken in de portaal op de layout "Seizoen" van jouw eigen voorbeeld: If [ Get ( LayoutTableName ) ≠ "Seizoen" ] # Zorg dat je op een layout met de context "Seizoen" staat Exit Script [ ] Else If [ Get ( WindowMode ) ≠ 0 ] # Zorg dat je blader-modus actief is Exit Script [ ] End If # Venster vastzetten, anders beweegt er van alles en de procedure is langzamer Freeze Window # Sla de PK van het huidige record op in een variabele Set Variable [ $pk ; Value:Seizoen::__PK_Seizoen ] # Ga naar een layout waarvan de basistabel dezelfde is als van de portaal waar een record moet worden aangemaakt Go to Layout [ "Seizoen_Lineitems" ] # Maak hier een nieuw record aan New Record/Request # Vul de juiste FK met de zojuist in een variabele opgeslagen PK Set Field [ Seizoen_Lineitems::_FK_Seizoen[ ] ; $pk ] # Vastleggen record. Heel belangrijk!!!! Commit Records/Requests [ Skip data entry validation ] # Weer terug naar de originele layout Go to Layout [ original layout ] # Einde script # Als je het goed overneemt moet er op jouw scherm helemaal niets flikkeren oid. Je zou ook kunnen starten met een nieuw venster maken en dan aan het einde ipv terug naar de originele layout dat venster weer kunnen sluiten ... net wat je zelf leuker/handiger vind

Ik heb jouw voorbeeldje even bekeken en je bent volgens mij in de goede richting bezig, maar ik zou het nog wat verder uitwerken voordat je begint met van alles aan elkaar te knopen. Als ik het voor mezelf op een rijtje zie, dan kom ik tot de volgende basis: 5 hoofdtabellen: Coureurs De persoon (Naam en andere persoonskenmerken) Teams Is een apart team of bij gebrek aan een team de individuele coureur Seizoenen Het seizoen (periode etc) Autos Merk, Type, VIN en overige kenmerken Races Races zonder data bijv. GP Monaco. 2 tussentabellen Races_Seizoenen De individuele race in een specifiek seizoen Autos_Teams_Coureurs De combinatie zoals deze deelneemt aan een race 1 resultaattabel Deelnames Races_Seizoenen + Autos_Teams_Coureurs De focus ligt hier dus op de coureurs die met een bepaalde auto van een bepaald team deelnemen aan individuele races. Vanaf hier kan je vervolgens gemakkelijk weergaven maken van welke coureurs in bepaalde seizoenen hebben deelgenomen. Of welke auto's door welke coureurs zijn bestuurd etc. etc. Is het niet belangrijk voor je om precies te weten welke auto's er zijn gebruikt en volstaat het merk/type, dan geef je dat aan bij de combinatie Teams_Coureurs. Die zijn dan mogelijk niet meer uniek, dus mijn keuze zou zijn de auto's wél als aparte entiteit te behandelen. Ik zie alleen niet uit je verhaal komen wat je precies wilt bereiken. Een goede opzet bereik je door ofwel heel duidelijk je doel voor ogen te hebben óf door alles zoveel mogelijk uit splitsen door te normaliseren (zie o.a. https://nl.wikipedia.org/wiki/Databasenormalisatie) Normalisatie kan extreem ver gaan en is voor FileMaker lang niet altijd handig, maar door het op zijn minst te overwegen, ga je wel heel intensief je datamodel bekijken en soms ook wel aanpassen. Vanwege deze normalisatie zou ik dus die auto's als aparte entiteiten behandelen in jouw DB, maar dat is jouw beslissing en is afhankelijk van je precies van jouw DB verwacht. Om bij die auto te blijven, die zou je verder uiteen kunnen laten vallen door weer aparte tabellen te maken voor "Merk" en "Model" en Model zou weer uiteen kunnen halen in "Type" en "Versie" oid. Dat gaat voor jouw toepassing hoogstwaarschijnlijk weel te ver en dus zou je kunnen volstaan met een tabel "Auto" waarin bijvoorbeeld "VIN" het belangrijkste kenmerk is, maar dat zou ook het "Racenummer" kunnen zijn. Niet direct antwoord op jouw vraag vrees ik, meer een pointer in een bepaalde richting, maar ik hoop dat je er iets mee kan aanvangen. Succes in China trouwens, ik neem aan dat je er aan het werk bent?

Het probleem is dat je begint met Case ( IsEmpty ( Overlijdensdatum ) Je moet je afvragen wat de meest significante factor is. In dit geval is dat de "Geboortedatum", want als die onbekend is kan je de leeftijd bij leven, noch bij overlijden uitrekenen. De berekening voor de leeftijd bij leven zou er als volgt uit kunnen zien: Case ( IsEmpty ( Geboortedatum ) and IsEmpty ( Overlijdensdatum ) ; "Onbekend" ; IsEmpty ( Geboortedatum ) ; "" ; IsEmpty ( Overlijdensdatum ) ; Year ( Get ( HuidigeDatum ) - Geboortedatum + 1 ) - 1 ; "" ) En de leeftijd bij overlijden zo: Case ( IsEmpty ( Overlijdensdatum ) ; "" ; IsEmpty ( Geboortedatum ) ; "Onbekend" ; Year ( Overlijdensdatum - Geboortedatum + 1 ) - 1 ) Je ziet dat de formule voor de leeftijdsberekening ook wat korter is dan de jouwe. Dat kan alleen maar omdat jij de leeftijd in jaren vraagt. De "-1" is omdat de jaartelling start in het jaar "1" terwijl wij leeftijd tellen vanaf "0", de "+1" is omdat wij de leeftijd aan het begin van de verjaardag een jaar opschuiven ipv aan het einde van de verjaardag.

Als je mijn voorbeeld gebruikt, dan zou ik toch de "halt-script" / "script-onderbreken" gebruiken. Het voordel is dan dat alle lopende scripts en triggers worden gestopt. Je kan dan rustig doen wat je wilt en bij het alsnog sluiten wordt het bestand wél gesloten omdat je dan al op de "setup" lay-out staat.

http://www.seedcode.com/pmwiki/index.php?n=SeedCodeCalendarFree12.SeedCodeCalendarFree12

Hi Ruben, Dat het niet werkt is eigenlijk een aanname van mij, ik heb ook 10.10.5 draaien, maar fp7 loopt daarop niet lekker bij mij. Ik kan wél bestanden openen, maar knoppen doen het niet, menu's werken niet goed, soms kan ik niet typen etc. Dus voor fp7 grijp ik terug op windows, want daar werkt dat probleemloos (net zoals fp5 / fmp6-dev, dat op MacOS helemaal niet meer kan worden gebruikt.) mvg, Menno

Hi Danny, ik denk dat je het niet goed hebt getest, want wat ik beschreef heb ik in meerdere situaties werkend. Ik heb daarom 2 voorbeeldjes toegevoegd één in fp7 en één in fmp12 formaat (dit ivm het feit dat veel mensen fp7 niet meer kunnen gebruiken op hun mac). Je kan openen als Guest of als de user "Admin" (zonder password). mvg, Menno Afsluiten.fmp12 Afsluiten.fp7

Je kan ná de stap: "Ga naar Layout X" een "Halt-Script" of "Script Onderbreken" plaatsen. Dat stopt het afsluiten ... alleen dan zal dat bij het afluiten wéér gebeuren, dus zal je er ook even in moeten bakken dat wanneer Layout X voorstaat, het afsluiten gebeurt ipv "Ga naar Layout X" en "Script Onderbreken". Waarom gebruik je overigens de gebruikersnaam en niet de privilegeset?

Je kan ook wanneer je meerdere bestanden wilt versturen, deze in een map plaatsen, die map zippen en dan het zip-bestand meesturen. Je werkt toch op MacOSX? Met applescript valt zoiets prima te realiseren.