Jump to content

Roger

Leden
  • Posts

    341
  • Joined

  • Last visited

Recent Profile Visitors

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

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