menno Geplaatst: 29 september 2020 Delen Geplaatst: 29 september 2020 Zie: https://support.claris.com/s/answerview?anum=000035267&language=nl_NL Quote Link naar reactie
0 Peter Wagemans Geplaatst: 30 september 2020 Delen Geplaatst: 30 september 2020 Een "onjuiste fout". Hilarisch. Een onjuiste foutmelding misschien? Dit is een goeie: FileMaker.PerformScriptWithOption ( script, parameter, optie ) Een paar vrienden en ik hebben een projectje op https://github.com/fmWebViewerWorkingGroup/fmBridgit waar we dit probleem eerder probeerden aan te pakken. Dit blijft natuurlijk werken, maar alles kan dus wat eleganter nu. Waarschijnlijk eens nadenken of dit project nog wel nodig is. Quote Link naar reactie
0 Peter Wagemans Geplaatst: 4 oktober 2020 Delen Geplaatst: 4 oktober 2020 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. Quote Link naar reactie
0 Peter Wagemans Geplaatst: 4 oktober 2020 Delen Geplaatst: 4 oktober 2020 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. Quote Link naar reactie
0 menno Geplaatst: 4 oktober 2020 Auteur Delen Geplaatst: 4 oktober 2020 We kunnen niet bij de gebruikte js-bibliotheek, of kunnen we dat wel? Ik zie nergens een verwijzing welke precies is gebruikt en ik vind ook nergens een licentie. Ik neem aan dat het een open-source bibliotheek is en dan is een bijgevoegde licentie en verwijzing naar de originele ontwikkelaar(s) sowieso verplicht. Bovendien geeft het ons de mogelijkheid eventuele fouten zelf op te lossen (zoals dat verrekte 12uur formaat). Je kan sinds MacOS 10.12of10.13 op een NL ingesteld systeem FileMaker in het Engels gebruiken, door dat apart per applcatie in te stellen in "Systeeminstellingen/Taal & Regio/Apps". Dan ontwikkel je met de lokale instellingen die je wenst en FM toch in het Engels. Quote Link naar reactie
0 Peter Wagemans Geplaatst: 5 oktober 2020 Delen Geplaatst: 5 oktober 2020 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. Quote Link naar reactie
0 Peter Wagemans Geplaatst: 5 oktober 2020 Delen Geplaatst: 5 oktober 2020 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 Citaat Hi Peter, Thanks for the kind words. but we no longer control the code for the Addons. There isn't anything we can do to fix them. So the best thing to do is to report them directly to Claris. ... Thanks Todd . Quote Link naar reactie
0 bigbadwolf Geplaatst: 5 oktober 2020 Delen Geplaatst: 5 oktober 2020 Wonderlijk dat je in FileMaker geen response krijgt als je vraag voor een update…! Kennelijk zijn ze weer afgestap van het intern updaten van FileMaker. Sterker nog de App geeft aan dat 19.0.1.116 de meest recente versie is! Quote Link naar reactie
0 bigbadwolf Geplaatst: 6 oktober 2020 Delen Geplaatst: 6 oktober 2020 Toevallig vandaag (pas) de melding van de update ontvangen… Quote Link naar reactie
0 hans erik Geplaatst: 13 oktober 2020 Delen Geplaatst: 13 oktober 2020 Ik heb nog geen hands-on ervaring met de calendar add-on, maar wel alvast een vraag: welke JS libraries gebruiken ze precies? Is dat Full Calendar? Ik had bij de presentatie van FMP19 het idee van niet. Maar wat dan wel? En zonder in samenzweringstheorieën te vervallen: betekent een add-on ook iets voor de gebruiksvoorwaarden en ondersteuning? Of is het een integratie vehikel 'as it happens' en verder niet? Quote Link naar reactie
Vraag
menno
Zie: https://support.claris.com/s/answerview?anum=000035267&language=nl_NL
Link naar reactie
9 antwoorden op deze vraag
Aanbevolen berichten
Doe mee aan dit gesprek
Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.