andries

en waarom niet gewoon de "onRecordCommit" layout scripttrigger met als resultaat exit false? Komt ook in de buurt van de grote knop die je er achter zet om de commit tegen te gaan. Script aan knop Set Variable [ $$commitAllowed ; True ] Commit Records Set Variable [ $$commitAllowed ; False ] Script die je als trigger aan de layout hangt (OnRecordCommit) if [ not $$commitAllowed ] Exit Script [ False ] else Exit Script [ True ] end if

Je kan een runtime versie maken, maar hiervoor heb je de advanced nodig, en dit zal ook niet lang meer mogelijk zijn...

Hallo wat ik zou doen (ik gebruik gewoon in het algemeen liever Case dan If...) Case ( Gallery price < 150; "below 150"; Gallery price >= 150 and Gallery price <= 250 ; "150-250"; "above 250" ) Een Case stopt met evalueren vanaf hij een "true" vindt. Dus van boven naar beneden, tot een conditie waar is. Met dan de default ("above 250") indien geen enkele "true" was.

wij zijn bezig met een FileMaker add on om Excel files te maken waar dit wel in zou kunnen! vanaf iets demo waardigs zal ik het tonen!

je kan wel vanuit een kleurcode dynamisch een 1x1 pixel in die kleur laten aanmaken, als je die berekening in een container zet kan je die tonen in je portaal. https://excelisys.com/filemaker-pro-13-tip-n-trick-v2-filemaker-pro-progress-bar/ het voorbeeld gaat om een hele progressbar, maar je kan ook enkel het deel gebruiken om je kleur te maken. succes!

he Peter blij dat het je boosheid onverschilligheid wordt, en ik ben er zeker van dat we dit wel nog tot een goed einde gaan maken. ik wil toch nog graag nuanceren dat het niet gaat om 1 keer iets te delen. Het is ook meer dan een custom function, zoals je zelf tijdens het gesprek aanhaalt. De angst is dat als die in open source wordt gelanceerd (waar ik zelf ook voorstander van ben), dat die code door een niet betrokken partij integraal, zondere enige toevoeging van meerwaarde, in een file wordt gestoken waar je dan opeens voor moet betalen. Ik snap die angst ook, want het is al gebeurd in het verleden. Zonder zelfs vermelding van waar het idee kwam, of de code, of het idee. De personen die daar over klagen delen ook al jarenlang in de FileMaker community, dus egoisten zou ik ze zeker niet noemen Maar ik denk dat hier even wat tijd moet over gaan (een weekje of zo) en dan vinden we wel weer de energie en goesting (voor de Nederlanders: zin) om hier mee verder te gaan! Een leuke week aan jullie Groetjes! Andries

Quickfind? of nieuwe requests maken, dan doe je een OR find: of in dit veld of in dat veld. Enter Find Mode Set Field [ CompanyName ; $name ] New Record/Request Set Field [ FirstName ; $name ] New Record/Request Set Field [ LastName ; $name ] Perform Find Dit zal zowel in CompanyName, FirstName als LastName gaan zoeken.

het kan dus wel, als je de functie die filemaker.performscript in een async gooit. async function callFileMaker(){ let result = await FileMakerWrapper.performScript ( "SaveRecord" , $record ); alert(result); } callFileMaker();

ik vrees dat we er niet gaan geraken. want await kan enkel binnen een asynchrone functie.... wat dus wil zeggen dat mijn functie eerst en vooral dus al asynchroon moet zijn... en dus binnen een asynchrone functie kan ik synchroon wachten op een andere asynchrone functie... begrijpen wie begrijpen kan

een andere voorbeeld in fullcalendar is de drop event. waar je een info object binnenkrijgt met een revert functie (hun error functie dus). en dan kan je doen. fm.performScript ( "update record", event ).catch ( (error ) = > info.revert() ); waar info.revert() is de functie die je kreeg van fullcalendar die je moet aanroepen als het opslaan misloopt.

haha, net het voorbeeld dat ik ga geven zo meteen op dotfmp ik heb verder de await nog eens onderzocht, but as usual: filemaker implements dinosaurs... so not supported in webviewer

en zie wat ik hier vind (thanks to russel) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await kunnen we doen var response = await fm.PerformScript() waarin response dus het scriptresultaat van filemaker zal zijn. iedereen blij

top! hoewel ik het niet snap waarom je daar zo hard aan vasthoudt, eender welke integratie dat je ooit wil gaan doen zal met callbacks werken en niet met pauzes. persoonlijk ben ik dan van zoiets meer fan om de performscript nog wat uit te breiden met een timeout, die dan een error gooit als timeout bereikt is. fm.performscript ( "myscript", "myparam", timeout ) .then ( () => alert("filemaker script called" ) ) .catch( () => alert("timeout") )

er is geen pauze in JavaScript... dat is het hele punt net van asynchroon programmeren: doe dit, als het goed gaat doe dan dat. Daarom dat Promises er zijn gekomen, omdat je dan overzichtelijk kan programmeren zonder in de callback hell terecht te komen. $("GET","/myData") .then ( ( data ) => fm.performScript( "SaveData" , data ) ) .then ( ( fmScriptResult ) => alert( "data has been saved:" + fmScriptResult ) ) .catch ( alert ( "something went wrong" ) ); "data has been saved" zal pas aangeroepen worden als filemaker klaar is met zijn functie. De code "wacht" dus wel om uitgevoerd te worden. Of beter gezegd: de code staat geregistreerd om uitgevoerd te worden, indien filemaker zegt dat alles goed is gegaan en dat de rest mag uitgevoerd worden. Dit lijkt mij de juistere (of in ieder geval meer Javascript gerichte) manier van werken, ipv een valse pause te gaan maken (want je code loopt wel verder, alleen zit die in een continue loop).

eigenlijk ging dit vroeger ook al met het hash change trucje dat ik toonde op een fmsummit enkele jaren geleden. Voordeel is dat nu dat hele complexe stuk eruit kan.