andries

Haai haai, @Peter Wagemans hierbij je voorbeeldje. Het is zonder bibliotheek, maar ik heb wel een eigen klasse moeten schrijven die FileMaker.PerformScript een beetje extend naar FileMaker.PerformScript ( scriptname, parameter, successCallback, errorCallback ). een klein voorbeeldje om 2 way interactie te gaan doen tussen FileMaker en Webviewer. Dit maakt gebruikt van callbacks en/of Promises, een manier waarmee in Javascript vaak een extern iets wordt aangeroepen en afhankelijk of het allemaal goed is gegaan (success) of er iets is misgegaan (error) laat je dan iets gebeuren in je Javascript applicatie. Het komt dus eigenlijk hier op neer: "Filemaker, roep dit script aan, als alles goed is gegaan doe dan dit, als alles fout is gegaan doe dan dat." Een concreet voorbeeld voor bijvoorbeeld een kalendarintegratie is. Indien de gebruiker een event van plek veranderd, roep dan FileMaker aan om dit weg te schrijven in de databank. Indien dit NIET gelukt is (error bij wegschrijven naar record bijvoorbeeld), revert dan de beweging en zet het event weer op de oorspronkelijke plaats zodat de gebruiker ziet dat het niet bewaard is. Dit heet asynchroon programmeren, en is eigenlijk een must om goed te snappen als je wil verder gaan met Javascript. Als een tijdslijn gebeurt dus eigenlijk dit: 1. Actie in Javascript wordt aangeroepen, met daarbij direct de acties: wat als het goed gaat, wat als het mis gaat. 2. Intern worden deze acties geregistreerd, en Javascript roept FileMaker aan. 3. Javascript code stopt nu met werken, dit is ook GEEN PAUZE, we zijn effectief aan het einde van de code gekomen 4. FileMaker doet zijn ding, en bepaalt of hij aan de Webviewer wil zeggen of het goed of slecht is gelopen. 5. De webviewer voert de stukjes code (geregistreerd in stap 1) uit. In code: function onEventDrop(event,revertDrop){ //fm.performScript (scriptname, parameter, successCallback, errorCallback ) fm.performScript("Bewaar Event",event, //success callback deze wordt nadien aangeroepen als FileMaker OK terugstuurt function ( data ) { //data is teruggestuurd vanuit filemaker alert("hoi pipeloi, het is bewaard"); }, //error callback deze wordt nadien aangeroepen als FileMaker ERROR terugstuurt function( error ) { //error is teruggestuurd vanuit filemaker alert("oeps, foutcode in filemaker: " + code ); //revertDrop is een functie die we kregen van FullCalendar om een drop te annuleren, dus roepen we die aan. revertDrop(); } } In FileMaker: #BUSINESS LOGICA #hier kan je heel wat logica doen en bijvoorbeeld proberen weg te schrijven naar een filemaker record #ALS DEMO: een custom dialog Show Custom Dialog [ Title: "Keuze"; Message: "Is de record bewaard?"; Default Button: “Yes”, Commit: “No”; Button 2: “No”, Commit: “No” ] If [ Get ( LastMessageChoice ) = 1 ] #we pass success to the callback Set Variable [ $result; Value:JSONSetElement ( "" ; [ "id" ; JSONGetElement ( Get ( ScriptParameter ) ; "id" ) ; JSONString ]; [ "success" ; Get ( LastMessageChoice ) = 1 ; JSONString ] )] Else If [ Get ( LastMessageChoice ) = 2 ] #we pass error to the callback Set Variable [ $result; Value:JSONSetElement ( "" ; [ "id" ; JSONGetElement ( Get ( ScriptParameter ) ; "id" ) ; JSONString ]; [ "error" ; Get ( LastMessageChoice ) = 2 ; JSONString ] )] End If #RETURN TO WEBVIEWER Perform JavaScript in Web Viewer [ Object Name: "wv"; Function Name: "fmcallback"; Parameter 1: $result ] Zoals je in het voorbeeld zult zien heb ik toch een eigenlijk bibliotheek er in gezet. Heeft me veel bloed zweet en tranen gekost om dit helemaal werkende te krijgen. Ik wil dit gerust wel eens uitleggen hoe het allemaal werkt, maar het komt hier op neer: Ik heb de FileMaker.performScript een beetje uitgebreid zodat je nu ook een success callback en error callback kunt meegeven. Deze registreer ik, en ik roep dan het filemaker script aan. De parameter pas ik wat aan, want ik voeg er nog een "id" aan toe en dan de parameter zoals doorgegeven. Bekijk dit als een soort "telefoon lijn waarop filemaker kan terugroepen". Als FileMaker met dit ID de webviewer opnieuw aanroept, weet de webviewer dus om welke actie het ging. Eigenlijk zegt de webviewer tegen filemaker: hallo, ik ben actie 23 en ik zou willen dat je de record bewaart. Nadien zegt Filemaker tegen de webviewer, actie 23 is helemaal goed gelopen! En hierbij het voorbeeldje, speel er eens mee, en als er vragen zijn shoot! het is nogal een moeilijk concept, maar éénmaal dat je asynchroon kopieren onder de knie hebt, zou je dit eigenlijk ook in Filemaker willen Oh ja, voor de diehards: dit werkt ook met Promises (toch op Mac, op Windows niet zeker), dus je kan ook dit doen: fm.performScript ( "getData", "" ) .then ( (data) => { //data is scriptresultaat van van getData data.sort(); fm.performScript ( "storeData", data); }) .then ( ( data ) => { //data is script resultaat van storeData //doe hier nog dingen }) .catch ( ( error ) => { //dit is ofwel de error van getData of van storeData, cool he :) alert(error); }) callback.fmp12

ik zal straks eens iets in elkaar knutselen om 2 way communicatie te demonstreren.

ik heb via de API van gmail ook corrupte pdfs voorgehad, toen kwam dat omdat ik niet de juiste content type had gedefinieerd voor mijn mails. Als je echter de native email functie van filemaker gebruikt, lijkt mij de bug in het VBS te liggen en niet in FileMaker... kijk eens of er een VBS script is die de headers aanpast van attachments, en vooral de Content-Type dan.

dat heeft er op zich niets mee te maken, omdat het gaat om de communicatie vanuit de webviewer naar filemaker die nu ongelimiteerd is. Wat je nu makkelijk kan doen is bijvoorbeelde image manipulatie (cropper.js bijvoorbeeld) en dan de image als base64 naar filemaker sturen. om op jouw probleem terug te komen, kan je wel (en ik ben aan een add-on aan het werken hiervoor) een functie voorzien binnen de webviewer "loadLibrary" en die dan aanspreken via Perform Script In Webviewer [ "loadLibrary" ; "https://.....] Waar je hier tegen aanloopt is dat die sowieso asynchroon loopt en dat je door het synchrone karakter van een FileMaker script nooit zeker weet wanneer de webviewer klaar zal zijn met die library in te laden. Mijn mening is dan ook: laad libraries in direct in de webviewer, en laat javascript code die de library nodig heeft pas draaien wanneer het hele "document" klaar is met laden (on document load).

nice met dank aan @Jos Hofman en @menno om dit te delen !

via fmp script protocol was je nogal gelimiteerd in de hoeveelheid data die je kon oversluizen, vooral op windows machines. Dit is volgens mij nu helemaal weg. Ik heb nog geen test gedaan van de max, maar ik ga er vanuit dat dat evenveel is als de scriptparameter van een script (maar niet getest). opgelet : je moet nu bij de webviewer wel aanzetten dat het mag gebruikt worden, en niet in de privileges (of op beide )

dat zal todd geist wel zeggen

mja FileMaker biedt ons jammer genoeg niet de tools aan om dit te verwezelijken Get ( SortFields ) noch Sort [ <<byFieldNames>> ] zijn geen functies die FileMaker ons biedt... Of dat zijn toch de 2 functionaliteiten die ik hiervoor zou gebruiken die niet bestaan...

ja inderdaad, de vraag is wat zijn de ervaringen hiermee als je er filemaker pro op zet? ik heb nu al gemerkt dat portalen niet reageren zoals je zou willen (scrollen).

ik doe altijd een go to field op het einde van mijn script dat wordt getriggered door de scanner.

ik snap het niet

ik bereken wel de layoutnaam, maar op basis van ID, hiervoor gebruik ik dan deze custom function: https://www.briandunning.com/cf/858 Dit is natuurlijk wel complexer dan wat Peter voorstelt. en ik maak dan een eigen functie aan voor elke layout, bijvoorbeelder "customer.form", en zo doe ik in mijn scripts: ga naar layout [ customer.form ] de eigen functie 'customer.form' ziet er dan zo uit Case ( Get ( Device ) = 4 ; FM_Name_ID ( 23 ; "L" ; "" ; "" ); //layout voor iphone FM_Name_ID ( 25 ; "L" ; "" ; "" ) //layout voor andere toestellen ) en ik vind dat wel leuk werken om eerlijk te zijn. Vraagt altijd wat setup als je een nieuwe layout aanmaakt, maar nadien zit je wel veilig en toch dynamisch en ook heel leesbaar. ik heb eigenlijk ook eigen functies om niet met Get ( Device ) te moeten werken, en dan ziet de functie er eigenlijk zo uit: Case ( iPhone ; FM_Name_ID ( 23 ; "L" ; "" ; "" ); //layout voor iphone iPad ; FM_Name_ID ( 25 ; "L" ; "" ; "" ) //layout voor ipad Desktop ; FM_Name_ID ( 21 ; "L" ; "" ; "" ) //layout voor grote schermen )

of misschien wel gehakt

Wij zouden Surface Go / Surface Pro willen kopen. Op zich geen zware applicatie, geen plugins (mini kiosk app dat moet kunnen printen). Heeft iemand hier ervaring mee?

als je met herhalingen werkt en je enkel de eerste werkt, dan ben je ergens Extend vergeten te gebruiken. Extend moet je gebruiken bij niet herhalende velden als je ze over alle herhalingen wil gebruiken (of zoiets ) Ik denk dat dit de oplossing voor je probleem is: GetValue ( Extend ( MyTable::MyField ) ; Get ( CalculationRepetitionNumber ) ) Met Extend zorg je er eigenlijk voor dat het veld in elke herhaling bereikbaar wordt, en niet enkel in de eerste