bigbadwolf

Kan het zijn dat je ‘forward typing’ hebt aangezet voor het veld? Als dat zo is kan het afhankelijk van de index van het veld inderdaad wel vertragen…

Ik heb nu (nog) een vergelijkbare iMac uit 2012, maar de problemen die je beschrijft komen me niet bekend voor. FileMaker is niet altijd even stabiel, maar het komt maar zelden voor dat hij mij niet bij kan houden. Weet niet wat je allemaal op de machine in de achtergrond hebt draaien? Maar dat kan er natuurlijk wel voor zorgen dat de processor (ook) druk is met andere processen.

En eerlijk gezegd… met FileMaker Go onder iOS zou het erop neerkomen dat het voornamelijk interessant is om in te zetten voor Android gebruikers. En dan is de keuze voor WebDirect ook helemaal niet zo verkeerd. Zeker niet als je er vanuit gaat dat de gebruikers toch altijd online zijn.

Kan op verschilleden manieren. Eenvoudigste is waarschijnlijk door een relatie te leggen tussen de afdelingsnummers (en eventueel een relatienummer zodat je niet in de knoop komt met bedrijven die dezelfde afdelingsnummers gebruiken). Met een simpele berekening kun je dan een lijstje maken. Substitute ( list ( RELATIE::email ) ; ¶ ; "; " ) Een script kan ook, maar dat moet je dan laten lopen om het veld weer te vullen.

En je krijgt waarschijnlijk geen geld terug als je minder gekocht hebt… ;o) Is inderdaad schreeuwend duur. Voor dat geld kun je bijna een App laten ontwikkelen.

Omdat je niet specifiek een substitute doet voor bepaalde teken (behalve dan de Char-codes), kun je die eenvoudig om de hele code heen zetten: Upper ( TrimAll( Substitute ( TextFormatRemove ( If ( IsEmpty ( self ) ; ArtikelRelatie::Omschrijving ; Self ) ) ; [ Char ( 10 ) ; " " ] ; [ Char ( 13 ) ; " " ] ; [ Char ( 160 ) ; " " ] ) ; 1 ; 1 ) )

Downloaden/uploaden via de Admin Console ben ik al een poosje op afgebrand. Ik schuif ze altijd over via de FTP. Sneller en praktischer.

Misschien kunnen we beter helpen als we een duidelijk(er) beeld hebben wat je voor ogen hebt. Je hebt het nu ineens over zoeken, terwijl je het eerst hebt over de weergave van de tekst. Dit zijn twee totaal verschillende zaken. Zoeken heeft niets te maken met de grootte van de letters. Als je niet kunt zoeken ligt dat eerder aan de wijze waarop je zoeken en of het veld wel geindexeerd is.

Je hebt gelijk, maar het is een slechts een voorbeeld… Als je het helemaal goed wilt doen moe tje natuurlijk ook foutafvanging doen na de ‘go to related records’… if [not get ( lasterror )] // geen fout is in dit geval resultaat 0 delete record of go to related records if [not get ( lasterror) delete all records end if else show custom dialog ( terugmelden dat er iets fout is gegaan met de mail ) end if

Duidelijk. Als je dus na het verzenden afvangt of er niet iets fout is gegaan met de verzending zou je daarna kunnen besluiten de gescande artikelen te wissen. Zo te zien staan ze in een portal, dus dan moet je of naar de gerelateerde records, of het huidige record wissen (vergeet dan niet in de relatie aan te geven dat gerelateerde records gewist moeten worden). Zoiets dus: if [not get ( lasterror )] // geen fout is in dit geval resultaat 0 delete record of go to related records delete all records else show custom dialog ( terugmelden dat er iets fout

Ja, dit is mogelijk… alleen wat niet helemaal duidelijk is uit je verhaal is of de gescande artikelen eerst in FileMaker terechtkomen. Als dat inderdaad zo is, dan kun je na het verzenden afvangen wat het resultaat is geweest (is de mail zonder fouten verzonden?) en de regels wissen.

Daar moet je dan wel weer direct aan denken. Als je het door het veld zelf laat oplossen heb je er geen omkijken meer naar.

In dat geval is het wel zo eenvoudig om op het veld als invoercalculatie TextFormatRemove ( Self ) te gebruiken. Hoef je er ook niet aan te denken als je plakt.

Dat is minder eenvouding dan je denkt. Velden zijn in FileMaker niet dynamisch, en er is ook geen ‘signaal’ als de tekst niet volledig zichtbaar is in het veld. Het enige wat je zou kunnen doen is grofweg bepalen hoeveel tekens er in een veld passen en daarnaar te handelen via een scripttrigger op het veld. Als er teveel tekst is zou je via de trigger het corps (lettergrootte) kunnen wijzigen. Niet waterdicht, maar dit is ongeveer wel het maximale wat je kunt doen. En ergens loop je toch tegen de grens aan van wat nog leesbaar is (als dat tenminste nodig is).

Bij de velddefinities (storage-tab) kun je aangeven of een veld (in dit geval zou het een tekstveld moeten zijn) een globaal veld moet zijn (dat wil zeggen dat het niet specifiek bij een record behoord, het hoort bij alle records en heeft overal dezelfde waarde). Met parsen bedoeld Marsau dat je alle regels in de tekst langsloopt en vervolgens daar iets mee doen. Je kunt ook in plaats van een globaal veld gebruik maken van een globale variabele ($$). Dit heeft in dit geval hetzelfde effect. Het ‘parsen’ doe je dan op de inhoud van de variabele. Bij het definiëren van een variabe