Peter Wagemans

FileMaker Go op je Mac. Als het een Apple Silicon Mac is. Cool. En super gemakkelijk om dingen te checken als je development ook op dat platform moet draaien. Als ik he goed begrijp, kan je dus FileMaker Go gewoon downloaden van de App Store en opstarten? Niet echt duidelijk voor mij of het nu al of niet out-of-the-box werkt. Ik heb de aankoop van een M1 uitgesteld, maar nu kriebelt het wel… :-) Welke communicatie? Volgens mij communiceert Apple met alle andere software vendors, BEHALVE met Claris. Fixes om FileMaker compatible te maken met het nieuwste Apple OS, komen altijd pas veel later uit dan de release van dat OS. Het lijkt wel of Claris er pas aan begint zodra ze net als de gewone burger hun development machines upgraden en dan zien dat het niet meer werkt. In schril contrast zie ik heel veel en zelfs grote applicaties hun upgrades aanbieden, zelfs al vóór het nieuwe OS gereleased wordt. Als dit niet kan voor Claris, ben ik niet verbaast dat ernog niet aan een ARM based versie van de FileMaker engine gewerkt is. Maar ik ben enorm blij verrast dat FileMaker Go zou werken, want dit vereist dacht ik een (kleine?) aanpassing.

BDW, ivm met die verkorte scriptnamen in de script-werkruimte, had dat hier ook voor. Werkte wél als ik de MBS plug-in niet de script IDs liet tonen, en werkte helemaal terug toen ik de MBS plug-in vervangen heb door de laatste versie. Dus waarschjijnlijk iets met de vensters van de script-werkruimte dat veranderd was. Misschien een eerste poging om het correct te doen werken met automatische dark mode? Dat dit absoluut fout gaat, en niet opgelost is in versie 19, is voor mij absoluut een raadsel. Dus een beetje off-topic, het is hier niet dat FileMaker problemen geeft met Big Sur, maar dat scripts onleesbaar worden sinds Catalina, als je 's avonds automatisch naar dark mode switched. Voor sommige developers geen probleem, hun code wás al onleesbaar. Maar ik wordt 's avond niet graag gedwongen om FileMaker te stoppen en terug op te starten, omdat Claris niet goed weet hoe ze Cocoa windows moeten programmeren, terwijl bedrijven die helemaal niets met Apple te maken hebben dat wél kunnen.

Deze week gebruik gemaakt van de Black Friday korting om voor een klant zo'n DynaPDF licentie aan te schaffen. Door de lockdown is er een beetje een verschuiving: klanten willen veel meer doen via email en PDFs 1 bepaalde klant van mij heeft een Windows Terminal Server voorzien - zelfs al zijn al de clients daar Macs. omdat er meer over VPN/Internet gewerkt wordt, moeten routines kunnen draaien als server side scripts. Zelfs in Mac omgevingen wordt er tegenwoorig veelal gekozen voor een WIndows FileMaker server. Dus heel wat code die ik via MBS met de gratis macOS toolbox PDFKit deed lopen, moest herwerkt worden, omdat PDFKit niet op Windows werkt. Ik kreeg dingen wel aan de praat via shell commando's naar ImageMagick, maar het was allemaal nogal traag, en volgens mij ook weer een extra ding dat moet onderhouden worden en kan breken. Dus: DynaPDF. Geen goedkope licentie, want we wilden de Pro, en op beide platformen, zodat ik dezelfde codebase kon gebruiken. Maar een verantwoorde uitgave. Zoals hans erik hierboven aangeeft: voor niets gaat de zon op. PS: i.v.m. het logo hier op de site. Dat is een maan achter de Sint-Rombouts toren in Mechelen. Geen zon. Ik weet het, het zal geen prijzen winnen. Maar hier op Clarify kun je dus stellen: voor niets gaat de maan op.

Ik vond deze morgen een nieuwe Git repository "Big Mac" - https://github.com/StarPlayrX/bigmac/blob/master/README.md Dit zijn shell scripts en ook een paar drivers denk ik, die mijn 2010 Mac Pro naar Big Sur kunnen upgraden. WTF heb ik zo'n museumstuk? Omdat het een beest is. Helemaal gepimpt met 2 snelle 3,4 Ghz CPU's, 64GB RAM, USB 3, een stevige video kaart, een 10gbit netwerk kaart en een NVMe raid PCI kaart. Een FMDatamigration job die op mijn Mac Mini i7 4core 31:09 pakte, doet dit ding in… 1:44. Draait op het ogenblik Catalina via de dosude patch, maar ik denk dat Collin ermee gestopt. Vreet wel electriciteit, maar staat nu als Apple RDP machine bij klant, en ik werk er hele dagen via VPN op. Dus dit wordt een projectje voor tijdens de eindejaarsdagen, als ik wat meer tijd heb, want het kan natuurlijk mislopen. De patch vond ik via een artikel op de MacWorld web site https://www.macworld.co.uk/how-to/install-catalina-old-mac-3654960/ . Voor Big Sur moet je in de eerste plaats kijken op https://github.com/barrykn/big-sur-micropatcher , de patcher die ik wil gebruiken is specifiek voor De Kaasrasp.

FMComparison is een apart programma, dat nu nog in beta is.

Mijn licentie op FMPerception geeft me ook recht op FMComparison, en ik heb onlangs de beta eens getest, dit is ook heel bruikbare software. Dit genereert een rapport gebaseerd op de verschillen, en start van de XML ( niet de DDR ), dus het is geen reverse engineering.

Gevonden. Winfried Huslik. http://fmdiff.com/download/FMDiff.pdf Dit is overgenomen door Jürgen Geßwein.

Er was vroeger zo'n programmaatje dat dat deed, programmeur was iemand met een Duitse naam, en ik geloof dat die een paar jaar geleden overleden is. Weet iemand nog hoe dat ding heette? Chris Moyer vroeg me dit daarnet.

Al via een aantal kanalen laten weten, maar nog niet via m'n eigen website. Schande. Voortaan vaart mijn bedrijfje Clarify onder de eigen vlag als FileMaker consultant. Lesterius geniet niet meer van mijn partner tarief, maar kan me nog steeds tegen een fair b2b tarief inhuren, wat ik veronderstel niet zal gebeuren, gezien zelfs mijn partner tarief gecontesteerd werd. Dus hierbij laat ik dat gewoon even weten, wie mij via email wil bereiken kan dat dus niet meer via Lesterius, maar via peter at nospam dot clarify dot net.

Met de MBS plug-in - zelfs met de ongeregistreerde gratis versie - kan je die Script IDs ook zien, het is een optie in de voorkeuren, kan je aan en afzetten. Dat is misschien handig om te weten.

Net een berichtje teruggekregen van Todd Geist. Ik had hem gemailed dat ik onder de indruk was van de kalender, maar dat ik toch wat bugs gevonden had. Spijtig genoeg moeten we door de Claris kanalen - waar ik mijn buik vol van heb. Dus idealisten gevraagd hier .

Ik heb een hekel aan zo van die JavaScript code die functienamen met 1 letter heeft. Lekker duidelijk. Zou het zoveel sneller laden als je toch lokaal werkt? Dat AM/PM formaat probleem ben ik ook op zoek naar geweest. Even. Ik heb de MBS debugger in de web viewer bijgezet, zodat ik een "inspect element" menuutje beschikbaar had. Om te ontdekken dat de kalender iets van een 40.000 lijnen code heeft.

Er is nog vanalles mis met die nieuwe functies en de kalender module. Mijn systeem staat staat als volgt ingesteld: Dat is voor mij als developer de beste instelling, zo wordt ik niet geconfronteerd met constante taalwissels in applicaties die geen NL ondersteunen. Nochthans begint voor mij de week nog altijd op maandag, en wil ik geen 12-uurs notatie, maar een 24-uurs notatie voor tijden. De systeemsoftware laat me niet toe om de taal van de dagen in te stellen, maar buiten wat layoutmatige problemen in FileMaker, lig ik daar niet wakker van. Merk op dat de regio, eerste dag van de week, het kalendertype, het tijdsformaat en het temperatuursymbool GEEN deel uitmaken van de localisatie, maar een instelling vormen NAAST de taal/regio layer. En daar gaat het waarschijnlijk fout. Dit is het resultaat van de nieuwe "Get(SystemLocaleElements)" functie - als FileMaker in het Nederlands staat, wordt dit "Get ( ElementenSysteemlandinstelling )" { "APIVers" : 1, "Currency" : { "Leading" : false, "Symbol" : "€" }, "Date" : { "DMQ" : { "1stDayOfWeek" : 1, "DaysOfWeek" : { "AbbrvList" : [ "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ], "NameList" : [ "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" ] }, "Months" : { "AbbrvList" : [ "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" ], "NameList" : [ "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" ] }, "Quarters" : { "AbbrvList" : [ "Q1", "Q2", "Q3", "Q4" ], "NameList" : [ "1st Quarter", "2nd Quarter", "3rd Quarter", "4th Quarter" ] } }, "DMY" : { "ElementArray" : { "NameList" : [ "D#", "M$", "YYYY#", "D$" ], "SepList" : [ ", ", " ", " ", "" ] }, "MustUseLocalesSep" : false }, "DateNums" : { "0d" : true, "0m" : true, "YYyy" : false }, "DateOrderID" : 1, "DateOrderName" : "DMY", "Sep" : "/" }, "LocaleID" : { "IDNum" : 21, "IDStr" : "English", "ISOLangCode" : "en", "LID" : "English", "Name" : "English" }, "Misc" : { "Active" : true, "Metric" : true }, "Num" : { "1000s" : ".", "Decimal" : ",", "Lead0" : true }, "Text" : { "SQuotLead" : "“", "SQuotTrail" : "”", "Sep" : ";" }, "Time" : { "12h" : false, "HMS" : { "0h" : true, "24h" : "", "Seconds" : false }, "NightDay" : { "12hSuffix" : true, "amStr" : " AM", "pmStr" : " PM" }, "Sep" : ":" } } Bug: de eerste dag van de week is niet 1, maar 2. Volgens mij haalt hij ook de tijdsnotatie niet goed op. Switchen we naar Nederlands, gaat FileMaker netjes onmiddellijk het resultaat van de functie veranderen. Zonder zelfs de dataviewer te verlaten. En voor Nederlands doet hij het goed: { "APIVers" : 1, "Currency" : { "Leading" : true, "Symbol" : "€" }, "Date" : { "DMQ" : { "1stDayOfWeek" : 2, "DaysOfWeek" : { "AbbrvList" : [ "zo", "ma", "di", "wo", "do", "vr", "za" ], "NameList" : [ "zondag", "maandag", "dinsdag", "woensdag", "donderdag", "vrijdag", "zaterdag" ] }, "Months" : { "AbbrvList" : [ "jan.", "feb.", "mrt.", "apr.", "mei", "jun.", "jul.", "aug.", "sep.", "okt.", "nov.", "dec." ], "NameList" : [ "januari", "februari", "maart", "april", "mei", "juni", "juli", "augustus", "september", "oktober", "november", "december" ] }, "Quarters" : { "AbbrvList" : [ "Q1", "Q2", "Q3", "Q4" ], "NameList" : [ "1ste kwartaal", "2de kwartaal", "3de kwartaal", "4de kwartaal" ] } }, "DMY" : { "ElementArray" : { "NameList" : [ "D#", "M$", "YYYY#", "D$" ], "SepList" : [ " ", " ", " ", "" ] }, "MustUseLocalesSep" : false }, "DateNums" : { "0d" : false, "0m" : true, "YYyy" : false }, "DateOrderID" : 1, "DateOrderName" : "DMY", "Sep" : "/" }, "LocaleID" : { "IDNum" : 20, "IDStr" : "Dutch", "ISOLangCode" : "nl", "LID" : "Dutch", "Name" : "Dutch" }, "Misc" : { "Active" : true, "Metric" : true }, "Num" : { "1000s" : ".", "Decimal" : ",", "Lead0" : true }, "Text" : { "SQuotLead" : "“", "SQuotTrail" : "”", "Sep" : ";" }, "Time" : { "12h" : false, "HMS" : { "0h" : true, "24h" : "", "Seconds" : false }, "NightDay" : { "12hSuffix" : true, "amStr" : " AM", "pmStr" : " PM" }, "Sep" : ":" } } Toch wat de dagen en de eerste dag van de week betreft. De tijdsnotatie lijkt me niet te veranderen. En dan terug naar de kalender-module: De default eerste dag van de week wordt NIET ingesteld door naar die mooie nieuwe functie te kijken - of ze nu klopt of niet. Waarschijnlijk is dit ontwikkeld in FileMaker Pro 18. En niet meer aangepast voor FileMaker Pro 19. Het wordt uiteindelijk een beetje een mik-mak van verschillende taalinstellingen als je FileMaker in het Engels staat, terwijl het bestand op een systeem met NL instellingen gemaakt is. Ik vind dit een fantastische eerste stap, maar toch maar even een nieuwe versie hiervan uitbrengen, Claris. Het zou als volgt moeten werken volgens mij: Alle taalinstellingen moeten uit het systeem komen, en niet de taal van de applicatie volgen. FileMaker start op in de taal van het systeem, behalve als die taal niet ondersteund wordt in FileMaker, dan start FileMaker in het Engels op. Correct, maar dat wil niet zeggen dat er voor de rest niet naar de taalinstellingen van het systeem kan gekeken worden voor alle andere zaken zoals dagnamen en maandnamen. Alle tijdsformaatinstellingen en start-van-de-week instelling moeten uit het systeem komen, en niet uit het bestand ( Deze technologie is ondertussen 33 jaar oud en mag gerust "Dinosaurus DNA" genoemd worden ) De gebruikers hebben absoluut geen boodschap aan de systeeminstellingen van de computer die de file aangemaakt heeft. "Get ( ElementenBestandslandinstelling ) " is een nieuwe functie die hierop voortborduurt en niet alleen volledig nutteloos, het is ook een stap in de foute richting en een complete verspilling van development tijd. Bedenk dat in ons kleine Belgen-landje er FileMaker Servers opgesteld staan waarop mensen ingelogd zijn die respectievelijk Nederlands, Frans, Engels en zelfs nog andere talen ingesteld hebben op hun client machines. Die mensen gaan we dus de taal van de programmeur in de strot duwen? Get ( ElementenSysteemlandinstelling ) of de Engelstalige equivalent Get(SystemLocaleElements) moet de start van de week overnemen zoals te zien in het regelpaneel, en het tijdsformaat zoals te zien is in het regelpaneel. En niet een instelling die eigen is aan de taal/regio. Djeezus. Het gaat al jaren fout met deze zaken, en het blijft maar fout gaan. Het is natuurlijk wel bruikbaar hoor maar om een paragraafje van de release notes te quoten: Lijkt me een beetje een understatement. Er is veel meer aan de hand. Maar waarschijnlijk is het allemaal wat te ingewikkeld.

In de kalender module kan je best de string values voor de "pause/resume" script stap vervangen door breuken. FileMaker is niet happy met "0.5" op een systeem dat geen decimale punt heeft. Die pauses zitten er een aantal keer in, dus best alles even aflopen.

Ik gebruik de XL lib, die op haar beurt door de MBS plug-in ondersteund wordt. Ik moet regelmatig van die custom Excelletjes maken, en dit bespaart me veel tijd, en dus kost het uiteindelijk minder voor de klanten die regelmatig functionaliteit nodig hebben die niet standaard in FileMaker zit. Voor de formules kan het dus bijvoorbeeld met: https://www.mbsplugins.eu/XLSheetCellWriteFormula.shtml