Roger

Hm.. dan doe ik blijkbaar iets fout of zie ik iets over het hoofd. In bijgevoegd plaatje zie je twee layouts. In de voor iOS aangemaakte layout heb ik invloed op de kleur van het onderste balkje, hier wit. In de andere heb ik die invloed niet en is deze lichtgrijs. Dit deel behoort niet tot de eigenlijke layout maar is in iOS wel zichtbaar. En dan vind ik het wel zo fijn dat dit de kleur aanneemt van de layout zodat het één geheel lijkt. Mij lukt het i.i.g. niet om dit voor elkaar te krijgen in een layout aangemaakt als Computer layout. Mocht jij tips hebben hoe je dit wel voor elkaar krijgt dan hoor ik die heel graag! 😀

Ik constateer dat er toch verschilletjes zitten tussen een layout die aangemaakt is als "Computer layout" dan wel als "Touch Device layout". Kan je achteraf het layout type nog veranderen? Ik zie nergens hoe je dat zou kunnen doen.

Deze versie lost het probleem op (in onderstaande link nader beschreven) met de script step: send mail, wanneer de inhoud van de mail een grote hoeveelheid karakters bevat. https://www.reddit.com/r/filemaker/comments/kf63h2/fmp_locks_up_when_trying_to_prepare_an_email_in/

FileMaker rapporteert "that this is not a product issue" en legt vervolgens uit hoe je dit probleem kunt omzeilen. Namelijk door het 'onthouden' van de selectie of de cursorpositie naar de auto enter calculatie te verplaatsen i.p.v. dit te vatten in de parameter van de script trigger. Zie bijlage door Claris aangepast. Chapeau voor hun support! onObjectExit_fixed.fmp12

Een gevalletje Eureka-erlebnis zoals hier beschreven? 😀

Dank voor ieders bijdrage. Op zich verhelderend maar het roept nog wel de vraag op, wanneer moét je nu echt een commit doen? Je kunt natuurlijk redeneren dat bij iedere recordwijziging een vastlegging kan plaatsvinden onder het mom van, baat het niet dan schaadt het niet. Maar je wilt je scripts ook niet onnodig lang maken. Een GTRR via een interface-layout o.b.v. globals, al dan niet in een new window, vereist bijvoorbeeld geen commit om het juiste record te tonen. Dus even om het goed te begrijpen, met dit script: Set (global) field [ INTERFACE::factuur_nr ; FACTUUR::klant_nr ] Go to Layout [ "Interface" ] Go to Related Record [ interface_KLANT__klant_nr ; Using layout: "klant" ] is een commit na de 1e scriptstap niet nodig voor de goede werking. (Ben je het daarmee eens Menno?) Maar is het dan zo dat het INTERFACE record gelockt is en blijft, zodat een andere gebruiker niet ook dit script kan uitvoeren? Volgens mijn test die ik gedaan heb niet. Komt dat door het feit dat het veld in INTERFACE een global is? In mijn test maakt het namelijk zelfs niet uit wanneer je op de ene client actief je cursor in dat veld hebt staan, op de andere client kun je ook dan dit script gewoon draaien. Om dit helder te krijgen heb ik ter test van INTERFACE::factuur_nr even een non-global veld gemaakt. Werkt het dan nog? Gedeeltelijk, namelijk: zonder actieve commit in het script wordt nog steeds het juiste record getoond. De commit heeft echter op de achtergrond wel plaatsgevonden getuige de andere client waarop te zien is dat INTERFACE::factuur_nr gewijzigd is. Ook op de andere client kan het script probleemloos worden uitgevoerd, behalve als op de eerste client men actief in het veld staat. Want dan krijg je de bekende foutmelding dat dit record gewijzigd wordt door een andere gebruiker. Ik weet, dit is hele basale materie maar wel belangrijke, in mijn optiek. Nuttige aanvullingen hierop zijn dan ook welkom!

Als ik naar mijn oude werk kijk kom ik vaak de scriptstap Go to field tegen waar ik daar tegenwoordig Commit record voor gebruik. Ik vraag me af, zit daar qua wat het doet eigenlijk veel verschil in? Ik weet, bij Commit heb je de mogelijkheid Dialog On/Off en opties als Skip data entry validation en Override ESS locking conflicts. Maar deze opties gebruik ik nooit en ik weet ook niet wanneer ik die zou moeten gebruiken. Ik ben eens benieuwd, wie kan hier iets interessants over vertellen?

Ah.. je denkt dus dat dit een bug is. Irritant, ik heb hier weer veel tijd mee verloren. Onder 18 doet het zich ook voor wat mij deed vermoeden dat dit manier is waarop het werkt (of beter gezegd, niet werkt). Ik zal het rapporteren. PS: Leuke manier (via scriptparameter) van je variabelen in te stellen btw!

Hoi Menno, was het nog geen bedtijd of stond je nog op wintertijd? 😉 Ik ben heel blij met jouw snelle reactie hoor want ik weet nu waar bij mij het probleem zat en nu kan ik tenminste verder. Ik had een auto-calculatie op mijn tekstveld die de tekst-formats verwijdert. Als je die erop zet werkt het helaas niet. Maar dat offer ben ik bereid te brengen. Dank!

Get( ActiveSelectionStart ) werkt (bij mij) niet in een veld dat gewijzigd maar nog niet ge-commit is. Bij een veld-exit laat ik een onObjectExit-scripttrigger bepalen wat de laatste positie van de cursor was of, indien van toepassing, welk stukje tekst geselecteerd was. Dat werkt uitstekend zolang dat veld niet gewijzigd is, want is het dat wel dan geeft de Get( ActiveSelectionStart ) de laatst mogelijke cursorpositie (de positie na het laatste character in dat veld) terug. Is dit een juiste observatie?

Ik heb uit betrouwbare bron vernomen dat dit wel eens in mei kon gaan gebeuren..

Ik werk sinds januari op een MacBook Air M1 en kan bevestigen dat ten aanzien hiervan nog geen verbetering is bereikt. Misschien dat dit nog komt als FM native wordt voor M1 / Silicon. Eens. Die verbinding is dan natuurlijk weg. Maar het zou mooi zijn als je applicatie gewoon geduldig bleef wachten tot de verbinding weer tot stand is gekomen. Goed te lezen dat Marsau tegenwoordig ervaart dat re-connecten meestal goed gaat. Ik denk dat het bij mij 50/50 is.

Hoe komt het toch dat als je computer ontwaakt uit de sluimerstand, dat FM vaak niet in staat is de verbinding met de host te herstellen terwijl de netwerkverbinding gewoon intact is? FM Go heeft daar geen (of veel minder) last van maar op de MacBook maak ik dit wel vaak mee. Vaak blijft FM wel draaien en hoef je alleen je applicatie opnieuw te openen maar soms maak ik ook mee dat FM "onverwacht gestopt is" en moet ook FM opnieuw geopend worden. Irritant is dat natuurlijk en onprofessioneel voor gebruikers. Ik heb het gevoel dat het probleem zich vaker voordoet als er een switch is gemaakt van netwerk maar noodzakelijk is dit niet. Het komt ook voor als je op hetzelfde netwerk bent gebleven. Heeft iemand een verklaring hiervoor en belangrijker, is er iets aan te doen?

Wel typisch dat dit 'uitgevinkt' stond.

Toevallig een M1 Mac? Zie ook mijn bijdrages in deze topic:

Intussen heerst dit probleem nog steeds in FileMaker 18/19 i.c.m. Mac OS Big Sur 11.2.3 (laatste versie die gisteravond beschikbaar kwam) en Apple M1 processor. Ook anderen ondervinden dit: https://www.reddit.com/r/filemaker/comments/kf63h2/fmp_locks_up_when_trying_to_prepare_an_email_in/ https://community.claris.com/en/s/question/0D53w00005EpnpdCAB/why-would-send-mail-fail-if-text-is-more-than-300-words Ik noemde het probleem eerder al vaag en dat is nog zwak uitgedrukt. Want inkorten van de tekst kan helpen maar het is niet zo dat de tekst slecht een bepaald aantal woorden of characters mag bevatten wil het goed gaan. Ik ervaar bijvoorbeeld dat als ik een vier pagina's lange Lorum Ipsum tekst in mijn veld plak, welke de inhoud van mijn mail moet worden, dat dit zonder problemen goed gaat. Dus in Apple Mail wordt dan wel op correcte wijze een nieuwe mail aangemaakt. Ook kan ik hele webpagina's achter elkaar in mijn tekstveld kopiëren en de mail zal foutloos worden aangemaakt en FM zal ook niet 2 à 3 minuten blijven hangen. Maar als de tekst door FileMaker is gegenereerd (o.b.v. velden in variabelen) dan werkt het opeens niet! Zelfs niet als je die door FM gegenereerde tekst via copy/paste handmatig in een mail plakt, die mail vervolgens verstuurt, die mail vervolgens opzoekt in je verzonden items, daar de tekst eruit kopieert en weer plakt in je FM tekstveld. Want in dat geval zal die mail niet worden aangemaakt zoals het hoort. De Inhoud zal leeg blijven, als ook de velden voor de Geadresseerde(n) maar het Onderwerp zal veel kans wel gevuld zijn. FM blijft vervolgens 2 à 3 minuten hangen. In de Script Debugger krijg je terug: "Last Error: [3] Command is unavailable (for example, wrong operating system or mode)". Je denkt, er zit iets in die tekst waar FileMaker of Apple Mail op knalt maar daar is geen sprake van. Het is doodnormale tekst die op een Intel Mac, ook onder Big Sur, feilloos werd overgebracht naar Mail. Ook als je de tekst eerst filtert op alleen cijfers en letters gaat het niet goed. Ook als je alle char (10), (13) en (160) substitueert, gaat het niet goed. Het is dus écht super vaag en vreeslijk irritant. En ik snap niet dat een bug in een toch niet onbelangrijke functie in de software van louter Apple producten niet wat adequater wordt opgelost. Ik vermoed dat het niet in FM zit maar in Rosetta 2, de emulator die FM, dat nog niet native is voor M1, laat draaien op M1 en dat zou betekenen dat FM (Claris) op zich geen blaam treft jegens haar eigen product. Maar zij dienen Apple wel te informeren en erop toe te zien dat dit opgelost wordt. En het roept ook de vraag op waar Claris blijft met zijn native M1 versie.

Laat ik op een Mac werken! Thanks !😃

Mochten ze nou bij Claris nog eens een idee kunnen gebruiken voor een nieuwe feature voor de volgende versie, eentje die ze er zo ingefietst zouden hebben, dan wil ik ze graag helpen 😃: Een sneltoets om de Script Debugger op te roepen / te verbergen en idem voor de Data Viewer.

Via een derden platform krijg ik op minimalistische wijze adressen aangeleverd. Bijvoorbeeld: 49 Woodlands crescent Glasgow (input) Mijn vraag is: Kun je, wat handmatig appeltje/eitje is, een adres automatisch compleet maken via de Google Maps route. Genoemde input invoeren in Google Maps levert een keurige output op (zie ook bijlage): 49 Woodlands Cres Bothwell Glasgow G71 8PX Verenigd Koninkrijk En ook deze url: https://www.google.nl/maps/place/49+Woodlands+Cres,+Bothwell,+Glasgow+G71+8PX,+Verenigd+Koninkrijk/@55.8099586,-4.0764577,17z/data=!3m1!4b1!4m5!3m4!1s0x48886a91788cdbb7:0x90b62cc926511bae!8m2!3d55.8099556!4d-4.074269 De data uit de url destilleren lukt wel, al is het toch vervelend dat er na de plaatsnaam geen komma volgt, waardoor de postcode achter de plaatsnaam staat. Temeer omdat de postcode in dit voorbeeld uit 2 delen bestaat. Wij mensen zien in 1 oogopslag welk deel hier de plaats en welk deel de postcode is maar voor de computer is dat minder evident. Iemand die daar een slimme suggestie voor heeft, be my guest. Want nu krijg je: 49 Woodlands Cres Bothwell Glasgow G71 8PX Verenigd Koninkrijk Maar waar het me in deze topic echt om te doen is: Is er een manier om vanuit FileMaker de input (onopgeknipt) naar Google Maps te sturen en vervolgens de url terug te vragen?

Dat is een juiste observatie. Ik voelde me nl. nogal senang bij A/B en zo werd dit het fundament van de paar applicaties die ik heb gebouwd en onderhoud. En van alles wat je aan een bouwwerk kunt veranderen is de fundering toch wel het lastigst. Ik raak hier dus een beetje confused van. Nu zie ik dat in deze 'nieuwe' methode nog wel veel A/B-techniek is overgebleven. Begrijp ik goed dat het grootste verschil is dat ankers ook aan ankers worden gekoppeld? En als dat zo is, biedt dat dan echt zoveel voordelen en zóveel minder TOC's? Ik lees ergens in de commentaren: "plus it makes the UI for field selection very challenging for calculations, layout objects, sorts, etc. (both because of the naming convention not being unambiguous and because of the sheer number of related TO’s)." Vind je dit een terechte opmerking? Ik ben benieuwd welke methodiek zoal door de ontwikkelaars hier op Clarify wordt gebruikt en waarom ze voor die methodiek hebben gekozen.

Ik denk dat dit de crux is in situaties waar het misgaat met calculaties. Goed om je bewust van te zijn. Dank voor je nuttige toevoegingen Menno!

Dit bleek te maken te hebben met een niet bestaand noreply-mailadres als afzender, dat vanwege gewijzigde security-settings niet langer door de SMTP-server werd geaccepteerd. Dit had niks te maken met Big Sur.

Hoe zit dat dan met variabelen? Deze worden altijd als alfanumeriek opgeslagen. Ik werk vrij veel met multi-value-key velden. Die zijn zover ik weet uitsluitend mogelijk met tekstvelden. Ik wist niet dat dit FM uniek was maar vind dit toch wel een heel prettige functie die ik niet graag zou missen en waar ik wel op wil kunnen blijven vertrouwen.

Thanks Marsau!

Ik blijf het een bijzonder verhaal vinden. Als er een numerieke waarde in een tekstveld staat, is en blijft dit een absolute numerieke waarde en die gebruiken in calculaties zou geen andere resultaten mogen opleveren dan diezelfde waarde in een getalveld. Het lijkt mij geen gevalletje bug fixing maar eerder een bug die nog gefixt moet worden. Ik ben benieuwd naar de volgende update.