Ga naar inhoud

Roger

Leden
  • Items

    347
  • Registratiedatum

  • Laatst bezocht

Berichten die geplaatst zijn door Roger

  1. Ik ontdekte dat op layouts waar de lijnen paars i.p.v. zwart werden getoond, dit leidde tot problemen in de pdf. Klanten meldden ons ineens dat ze facturen niet meer konden openen met Acrobat, wel met Voorvertoning. Ik kon dit oplossen door de lijnen te vervangen. Het probleem dat de lijnen op het beeldscherm verdwijnen als op de layout wordt ingezoomd werd niet opgelost.

    Scherm­afbeelding 2024-03-25 om 10.27.26.png

  2. In mijn layouts werk ik veel met haarlijnen, lijnen met een dikte van 0,25. Deze worden sinds de update naar Mac OS Sonoma anders weergegeven, dunner en soms ook anders van kleur, paars i.p.v. zwart. Helemaal vervelend is dat wanneer op de layout wordt ingezoomd, deze lijnen helemaal verdwijnen. Bij het printen gaat het wel goed en is er niets veranderd. Iemand ook deze ervaring?

  3. Ik was benieuwd, wanneer je data uit een Excel file wilt importeren en je Excel bevat meerdere tabbladen (werkbladen), of je tegenwoordig in je script kan aangeven uit welk tabblad data geïmporteerd moet worden. Hier werd ooit in 2010 een vraag over gesteld op dit forum. Toen kon het niet en nu kan het nog niet. Prima. Wel jammer dat je zo een extra dialog in je proces krijgt waar keuzes gemaakt moeten worden waarmee de gebruiker de procedure nat kan laten gaan. 

    Ik heb wat zitten experimenteren met tabbladen te verbergen en te beveiligen. Eveneens geëxperimenteerd met zogeheten Named Ranges; een serie cellen die je een naam geeft en die dan ook door FM als importoptie worden aangeboden. Maar wat je ook doet, je krijgt het niet voor elkaar dat FM je die dialog niet voorschotelt. Saillant, FM is zelfs graag bereid alle data te importeren, dus ook data van beveiligde en verborgen tabbladen/kolommen/named ranges. Ik denk dat menig Excel adept die zijn gevoelige data toevertrouwt aan zorgvuldig beveiligde spreadsheets zich dat niet realiseert.

     

  4. 14 minuten geleden, Banach zei:

    Ik zou zeggen: probeer het eens! 😀

    Ja das een goeie Banach! Dat ik daar nou niet opkwam... Ik zie niet hoe het zou moeten en tegelijkertijd verbaas ik me erover dat deze functionaliteit niet in FM zit. Vandaar toch maar de vraag gesteld. Wellicht is er een plugin voor o.i.d. Ik hoopte eigenlijk dat iemand een goede tip had.

  5. Op 28-3-2010 om 16:22, Willem_P zei:

    maar ik zoek een mogelijkheid om tijdens het lopen van dit script een weeknummer in te voeren dat verwijst naar het door mij gezochte tabblad

    Een worksheet/tabblad of zelfs een named range opnemen in je script, kan dit 14 jaar later eigenlijk nog steeds niet?

  6. 1 uur geleden, bigbadwolf zei:

    Die optie is er niet, omdat er technisch geen verschil in zit.

     

    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! 😀

    Schermafbeelding 2022-02-23 om 15.06.33.png

  7. 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!

     

     

     

     

     

     

     

     

  8. 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?

  9. 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! 

  10. 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!

     

  11. 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?

  12. 15 minuten geleden zei Peter Wagemans:

    Ik ben benieuwd of het beter gaat op de M1 Macs.

    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.

    22 minuten geleden zei Peter Wagemans:

    Hoe "intact" is je verbinding, als je notebook in sluimerstand was

    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. Op 02/02/2021 om 18:10 zei Roger:

    Het verbaast me niet, mailproblemen onder Big Sur, ook i.c.m. Apple Mail. Ik loop er tegenaan dat de inhoud van de mail soms leeg blijft en dat FileMaker in dat geval zo'n drie minuten een strandbal laat draaien. De mail (inhoud) inkorten helpt dan maar is geen oplossing. Heel vaag. Ik moet er nog verder induiken om erachter te komen wat er nou precies aan de hand is. Feit is dat onder Mojave dit probleem zich niet voordeed. Als ik wijzer wordt in deze zal ik het hier posten.

    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.

  15. 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?

     

     

    Schermafbeelding 2021-02-15 om 12.04.05.png

×
×
  • Nieuwe aanmaken...