Jump to content

Roger

Leden
  • Posts

    339
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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/
  2. 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
  3. Een gevalletje Eureka-erlebnis zoals hier beschreven? ūüėÄ
  4. 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!
  5. 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?
  6. 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!
  7. 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!
  8. 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?
  9. Ik heb uit betrouwbare bron vernomen dat dit wel eens in mei kon gaan gebeuren..
  10. 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.
  11. 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?
  12. Wel typisch dat dit 'uitgevinkt' stond.
  13. Toevallig een M1 Mac? Zie ook mijn bijdrages in deze topic:
  14. 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.
×
×
  • Create New...