Peter Bouma

Je kunt het hoofdgedeelte helemaal verwijderen, het is niet verplicht.

Klopt. Gisteren klant in paniek na weekend-update naar 14.0.6 (Win, 32bit). Symptoom: PDFs gegenereerd vanuit FMP 14.0.6 Windows krijgen blanko pagina's na pagina 1, als je ze opent in Acrobat (Reader of Pro), zowel op Mac als Windows. Acrobat (bij mij op Mac) verandert de PDF stilzwijgend bij het openen (gooit foute code weg?), want er verschijnt een save-dialoog bij sluiten. Op Windows hele vage dialoog dat een onderdeel niet gevonden kan worden. Dezelfde PDF geopend In Preview op Mac ziet er prima uit en zeurt niet om bewaren van wijzigingen. Moet haast wel de nieuwe PDF-engine zijn die in 14.0.6 en 15 zit. Teruginstalleren van 14.0.5 verhielp het probleem. Ik heb niet alle combi's van platform en FM-versie geprobeerd. Ik heb dit (ook) inmiddels gemeld bij FMI.

Stel, in Orderregels zit een veld 'is_niet_op_voorraad', en dat bevat een 1 of niets (checkbox). Maak nu in Orders een berekend veld (bijv. 'is_niet_leverbaar') met de formule: Sum( Orderregels::is_niet_op_voorraad ) > 0 Dat levert in Orders een veld met boolean true/false (1 of 0) op, en die kun je in de portaal Orders op zijn beurt als checkbox afbeelden (met een keuzelijst die alleen een 1 bevat), of er een berekend waarschuwingsikoontje van maken of wat dan ook. Maar eigenlijk is dit model niet helemaal goed: het niet-op-voorraad zijn van een artikel is nl. geen eigenschap van de orderregel, maar van het artikel òp die orderregel. Als er nieuwe voorraad binnenkomt, of uit gaat, zou je telkens op alle orderregels met dat artikel het aankruisvakje moeten bijwerken. Dat zou ik niet doen. Dat gegeven moet helemaal niet op de orderregels worden opgeslagen. Beter is bijv.: in de tabel Artikelen is een getalveld 'voorraad'. Bij verzenden van orders wordt daar van afgetrokken, en bij inkoop of bijmaken van nieuwe, wordt er bij opgeteld. Als het bestelde aantal op een orderregel hoger is dan de beschikbare voorraad van dat artikel, kan het vlaggetje via een niet-opgeslagen berekening (datzelfde 'is_niet_op_voorraad' in Orderregels, maar nu als berekening i.p.v. een gezet aankruisvakje) automatisch aanspringen door middel van de formule Orderregels::aantal > Artikelen::voorraad Dit levert een boolean 1 of 0 op. En die kun je over de relatie vanuit Orders optellen zoals boven beschreven met de formule voor Orders::is_niet_leverbaar. (Uiteraard aangenomen dat Orders — Orderregels — Artikelen aan elkaar gerelateerd zijn) Klein dingetje om op te letten: als in de voorraad iets verandert (iets of iemand past het getal aan), kan het zijn dat de vinkjes/waarschuwingsikoontjes in de portaal op jouw layout niet direct worden bijgewerkt. Dit kan met een Refresh Portal worden opgelost. Sowieso zal het bij het klaarmaken van een order altijd nodig zijn om te controleren of je van een artikel genoeg op voorraad hebt. Peter Bouma

Er zijn verschillende methodes om tussen tabellen een link via ID te leggen zonder ID's zichtbaar in beeld te hoeven krijgen, maar je zoekt hier kennelijk naar een gewone keuzelijst. Dat kan, definieer de keuzelijst Componisten als volgt: Gebruik waarden van veld (bovenste optie), klik knop 'Kies veld' (of woorden van gelijke strekking, ik werk in een Engelstalige FM Kies boven de linkerkolom de tabel Componisten, en kies daaronder het ID-veld. Kruis rechtsboven 'Toon ook waarden uit tweede veld' aan, en kies daaronder voor Componisten::Naam. Kies onderaan voor 'Toon alle waarden'. Kruis 'Toon alleen waarden uit tweede veld' aan, en kies voor sorteren op het 2e veld. De sorteertaal hoef je niet in te stellen. Als je het veld voor id_componist op de invoerlayout van muziekstuk (dus het veld uit de tabel Muziekstukken dat het ID van de componist moet gaan bevatten) nu vormgeeft als een popup-menu, met de hierboven gedefinieerde keuzelijst, kun je uit een alfabetisch gesorteerde lijst namen kiezen, terwijl je 'onder de motorkap' eigenlijk het ID toekent. Bij een popupmenu zal de gekozen naam ook na het selecteren in beeld blijven. Bij een uitklaplijst helaas niet, dan wordt het ID zichtbaar en moet je de naam op een andere manier (over de relatie) weergeven. Het componisten-naamveld moet overigens geïndexeerd kunnen worden, anders kan FM er niet op sorteren. Kleinigheidje: als het aantal componisten groot is (ik weet niet hoe omvangrijk je database is) kan het popupmenu onhandig lang zijn (menu dat van het scherm loopt, en merkbare vertraging bij het tonen ervan). In dat geval kunnen andere technieken interessanter zijn, zoals een script dat een tijdelijk popupvenster met alle componisten toont, waaruit je er dan een kunt kiezen. Daarin zou je dan bijv. ook kunnen zoeken, of extra info afbeelden (bijv. jaartallen om naamgenoten van elkaar te onderscheiden, een portretje etc.). In een popup-menu kun je behalve scrollen overigens ook de beginletter(s) typen om snel naar de betreffende naam te springen, en je kunt ook met de pijltjestoetsen op en neer. HTH, Peter Bouma

Ik denk dat je de Case-statements voor cliënt, groep en rubriek gewoon met een AND achter de datumcondities (binnen de Let) kunt zetten: Let ( [ x = If ( IsEmpty ( R212::gDatumVan ) ; Date ( 1;1;1 ) ; R212::gDatumVan ) ; y = If ( IsEmpty ( R212::gDatumTot ) ; Date ( 12;31;4000 ) ; R212::gDatumTot ) ] ; R212::cDatumObvTimestamp ≥ x and R212::cDatumObvTimestamp ≤ y and //client Case ( IsEmpty ( fc ) ; True ; not IsEmpty ( FilterValues ( fc ; deClient ) ) ) and //groep Case ( IsEmpty ( fg ) ; True ; not IsEmpty ( FilterValues ( fg ; deGroep ) ) ) and //rubriek Case ( IsEmpty ( fr ) ; True ; not IsEmpty ( FilterValues ( fr ; deRubriek ) ) ) ) // einde Let HTH Peter

De ampersand (&) op de WHERE-regel hoort daar niet thuis, je zit daar nog 'binnenin' de SQL-query. HTH Peter

Oeps, je hebt gelijk, het kan wel, van het ene FM-bestand naar het andere. Ik heb het door elkaar gehaald met de onmogelijkheid om in FMGo van de ene TO naar de andere te importeren binnen hetzelfde FM-bestand. Dat kan in de desktop-FM wel, bijv. om uit een TO van een externe bron (server bijv.) te importeren naar een bestandseigen TO. In FMGo moet dat buitenom, en dat kan inderdaad met de truc die Menno beschrijft. Dank voor het ophelderen.

Sorry, dat was niet precies genoeg geformuleerd: je kunt op een iPad niet van het ene lokale fmp12-bestand naar het andere lokale fmp12-bestand importeren. Wel van iPad naar server en omgekeerd, mits die import vantevoren in FM Pro is ingericht natuurlijk, want imports definiëren kan ook niet in FMGo.

Ben bang dat dat ook niet gaat werken, want je kunt op een iPad ook niet van het ene FM-bestand naar het andere importeren. Ik denk dat je toch uitkomt op een text-achtige export (csv ofzo) als tussenstap, met daarin de base64-gecodeerde handtekening/foto.

Zoals zo vaak bij FM zijn er verschillende benaderingen mogelijk. optie 1. Leg een relatie van de planningtabel naar de vakantiedagentabel, van het ene datumveld naar het andere (planning::datum = vakantiedagen::datum). Je kunt nu (vanuit planning) over die relatie kijken of er een vakantiedag zichtbaar is, door te testen op not IsEmpty( vakantiedagen::ID ) of eenvoudigweg not IsEmpty( vakantiedagen::datum ). optie 2. Zet de beoogde planningsdatum in een lokale variabele ($datum bijv.), spring even naar een layout van de vakantiedagen, doe daar Set Error Capture[ On ], doe een Perform Find[] naar vakantiedagen::datum = $datum. Als je iets vindt ( test op Get( FoundCount ) > 0 ), was het een vakantiedag. Onthoud dat resultaat in een andere variabele, doe bijv. Set Variable[ $is_vakantiedag ; Get( FoundCount ) > 0 ], dit levert in de variabele een true of false op, die je later weer kunt gebruiken. Ga terug naar de Original Layout (van planning), en baseer de rest van je procedure op de de waarde van $is_vakantiedag. Voordeel van deze methode: je hoeft er geen extra relatie voor aan te maken in het Relatieschema. Scheelt toch weer een beetje 'rommel'. optie 3. Gebruik een SQL query (vanaf FM12): Set variable[ $is_vakantiedag ; Let( query = "SELECT * FROM vakantiedagen WHERE datum = ?" ; not IsEmpty( ExecuteSQL( query ; "" ; "" ; planning::datum ) ) ) Wees precies met het intypen van de juiste veld- en tabelnaam (eigenlijk TO-naam), ExecuteSQL geeft alleen maar "?" als er typfouten in zitten. Na deze scriptstap zou $is_vakantiedag ook een true of false moeten bevatten, waar je in het vervolg op kunt testen: If( $is_vakantiedag ; ... ; ... ) Voordeel: ook hier heb je geen aparte relatie naar vakantiedagen nodig (net als bij 2), en het is ook nog eens een tamelijk compacte scriptstap, waarvoor je niet van je planningslayout af hoeft. Klein puntje: in deze opzet wordt aangenomen dat je met vakantiedagen feestdagen bedoelt, die voor iedereen gelden. Als het erom gaat te bepalen of sommige deelnemers/cursusleiders/wie dan ook voor de boogde datum toevallig individueel vakantie hebben ingepland, komt het aspect van de persoon waaraan die vakantiedag gekoppeld is er nog bij. HTH, Peter

Ik heb eens ergens opgevangen (maar weet niet meer waar) dat FM zijn tekst intern opslaat als UTF-16, d.w.z. niet 'up to' 2 bytes, maar gewoon altijd (groepjes van) twee bytes per teken (2 voor verreweg de meeste tekens van de moderne talen, en 4 voor zeer exotische tekens — en Emoji). Dan is de FTS dus redelijk correct met de bewering dat 1G aan tekens (in doorsnee) 2GB aan bytes zal innemen. Maar toegegeven, ze zijn er een beetje vaag over, en ik heb bij het leren ook een beetje zitten twijfelen wat er nou bedoeld werd. Op http://help.filemaker.com/app/answers/detail/a_id/14164 staat iets heel anders (<10.000.000 tekens "per herhaling"), maar dat zal toch echt fout zijn. En er moet inderdaad onderscheid worden gemaakt tussen Unicode, wat gewoon een lijst is waarin lettertekens/karakters uit een waslijst aan talen en schriftsoorten (en een heleboel meer) ieder een standaardnummer hebben gekregen, en de binaire encodings, zoals UTF-8 en UTF-16. Bij UTF-8 kan een teken (een Unicode codepoint) door 1, 2, 3 of 4 (vroeger ook 5 of 6) bytes worden gerepresenteerd. Waar het bij deze encodings om draait is dat aan iedere byte uit een stream bytes te zien is of die op zichzelf staat, of deel uitmaakt van een groepje dat samen een karakter vertegenwoordigt. Als de hoogste bit 0 is, hebben we te maken met single-byte, en dat komt 100% overeen met de oude low-ASCII (t/m nummer 127). Is voldoende voor Engels en een bescheiden groepje andere talen met Latijns schrift zonder accenten. Zodra de hoogste bit van een byte aanstaat, hoort een UTF-8-byte tot een groepje dat samen één karakter definieert. De op één na hoogste bit bepaalt dan of een willekeurige byte de eerste of de volgende is van een groepje van 2 of meer. Voorbij codepoint 127 zijn de bits die het Unicode-getal representeren over de 2 (of meer) bytes verdeeld, met overslaan van de bits die aangeven wat voor type byte het is. De binaire rekensom die de Unicode-waarde geeft is dus niet opgebouwd uit aaneengesloten bits, maar bijv. 5 bits van de ene byte en 6 bits van de andere. Vanaf codepoint 2^11 (2048) moet je al naar meer dan 2 bytes. In UTF-16 past alles tot codepoint 65535 in 2 bytes. Dat is genoeg voor de meeste moderne talen, ook voor het meeste Japans en Chinees voor dagelijks gebruik. Allerlei antieke schriften (bijv. spijkerschrift), reeksen zeldzamere Chinese tekens, muzieksymbolen en Emoji hebben hogere nummers, die krijgen in UTF-16 een encoding van 4 bytes lang. Ik heb even zitten proberen, maar Filemaker accepteert zonder enig probleem ook die 'zeer hoge' Unicode-tekens (dus codepoints > 0xFFFF). Je kunt in een FM-veld dus gerust Emoji invoegen, een pak van mijn hart. Maar mocht je een hele roman in Emoji willen schrijven (iemand gaat dat doen), dan zul je dus waarschijnlijk minder karakters in 1 tekstveld kwijt kunnen dan de 1 miljard die FM je belooft. Ik ga dat vanavond niet meer uitproberen.