Marsau

Bij mij regent het niet, en heb ook genoeg te doen, maar heb toch even meegelezen Ik zou zeggen: gebruik de While functie op de grove lijst, sorteer elk item, en daar UniqueValues. Dat is niet zo moeilijk, of ik moet je verkeerd begrijpen. Ik zou die CF ook met While inrichten ipv recursief, dan kan je alles in één keer doen met meer beheersing van de logica..

Ik zoek een confrere die mij kan ondersteunen bij het koppelen van een bestaand FileMaker-systeem aan een website. Klant wil een klantenportaal realiseren. Gebruik van de data-API ligt natuurlijk voor de hand, maar het gaat hier vooral ook om het neerzetten van paar gelikte webpagina's. Ik heb hier nog geen concrete ervaring mee en zou het graag samen met een ervaren collega oppakken. Wie heeft ervaring en is beschikbaar? Bij gerichte interesse graag een PB.

Natuurlijk: vergroening, geen fossiele energie meer, energie-opslag en streven naar energie-besparing en energie-efficiëntie. Denk dat de vooruitzichten voor energie-zuinige informatie-technologie goed zijn, maar dat het (vooralsnog) trager verloopt dan onze data-honger. Mijn punt was dat intensivering van data (opslag, verwerking, transport) - wellicht kan je dit virtualisatie noemen - hopelijk een winst oplevert in de reële fysieke wereld, als gevolg van substitutie. Voor mooie FileMaker applicaties maak je m.i. dat punt mogelijk snel waar Meer data kan een vergroening betekenen,

Herladen betreft het herladen van de huidige geladen pagina. Opnieuw instellen gaat terug naar de initiële instelling. Dus radicaler, maar mogelijk een zelfde resultaat.

Ik heb het vermoeden (of hoop) dat we met slimme gehoste FileMaker oplossingen bijdragen aan een duurzame wereld. Er is ergens een substitutie effect: we besparen tijd, geld en energie. Dat is de raison d’etre van de applicatie. Afgezien hiervan: denk dat het aandeel FM hosting in dit enorme energie verbruik beperkt is. Je mag hopen dat er een soortgelijk substitutie-effect van energieverbruik in real life situaties is. Ben bang dat dit nog lang niet zo is: er is geen rem op de behoefte aan plaatsonafhankelijke reken- en opslagcapaciteit. Het is ook de vraag wie er op die rem zou kun

M.i. geen directe pdf print in iOS. Wel kan je in het print menu de preview als een pdf op-poppen. En daarna de deelknop gebruiken. Waarschijnlijk niet wat je zoekt. Als het je gaat om een soort print preview zou je ook gewoon de print-layout kunnen tonen. Als het goed is, wijkt ie niet af van de pdf.

M.i. haal je data-typen door elkaar. Met de script step 'Bestand invoegen' krijg je een file reference. Dat is niet gelijk aan een tekstpad die de script step Mail verzenden gebruikt. Door het als een geheel in te voeren gaat de attachment kennelijk in duplo mee. Het is weer de eerder besproken vergevingszindheid van FileMaker dat het toch nog gewoon werkt. Check maar in de data-viewer. Mogelijke oplossing: de laatste waarde van de van de file-reference is het pad wat je nodig hebt. RightValues ( $emailbijlage ; 1 )

Webdirect is m.i. toch een hele andere ervaring dan een native app. Maar bezwaarlijk is vooral het hoge kostenniveau: je zou concurrent users moeten aanschaffen. Misschien te rechtvaardigen als de gebruikersgroep welbepaald is en er een hoge gebruikswaarde aan de app zit. Bij livecode is het helaas niet anders. Een open distributie van een (gratis) app via de App store zou een flinke omzet per user moeten opleveren om de licentiekosten eruit te halen. http://lcfmlessons.livecode.com/a/1341106-license-definitions Ben hiermee iets wijzer geworden over hun manier van tellen van g

De vraag is evenwel hoe de gebruikers geteld worden. Afhankelijk van de distributiewijze heb je wel/geen controle over het aantal downloads. Als elke download tot een ping leidt, dan kan je nooit zeggen dat je x gebruikers hebt. Ze hebben het over 'online' users. De vraag is echter wat dit betekent: iedereen die de app op zijn/haar device heeft geopend, of vastgepind aan het moment dat men met FMS verbonden is. Ik probeer daar nu achter te komen. In het eerste geval lijkt mij Livecode for FM ongeschikt voor mass deployment of toepassing binnen gebruikersgroepen van onbepaalde omvang.

Ik zou het geen 'bug' noemen, eerder een frictie tussen veranderende ontwerpprincipes/vereisten. Denk dat men het destijds intentioneel zo heeft opgezet, en dat men er - zonder kennisgeving - van terug is gekomen. Ik zie geen aanknopingspunt in de aangegeven FM13-documentatie: inderdaad strikte omschrijving van de veldtypen, maar we weten allemaal dat toen wel mogelijk was wat we hier bespreken.. Pas in FM19 wordt het pas anders. Vind het overigens geen probleem, behalve dan dat deze wijziging van de spelregels problemen kan oproepen in bestaande systemen - als je lichtzinnig met de veldt

Vandaag weer even naar Livecode for FM gekeken. De belofte om 'native' iOS en Android apps te maken, en daarbij tegelijk de FMS communicatie te regelen (via Data API) blijft interessant. https://filemaker.livecode.com Ze hebben een prijscalculator opgenomen, en maken onderscheid tussen 'named' users en 'concurrent' users. Het gebruik wordt gemonitord, zodat je aanvullende rekeningen zal krijgen als je te weinig hebt ingekocht. Bijgaand een quote voor 20 gebruikers. Ik vind het schreeuwend duur, kan hier geen business case op bouwen. Jammer.

Als je opzoekt dan neem je een (hopelijk) onopgemaakte basiswaarde mee. Dus pas dan daar de FormatRemove truc toe. Of anders: verwerk de opzoekrelatie in de calculatie. Kan ook Succes!

Schetsmatige, mogelijke oplossing: Ik denk dat je hier met de publieke benadering van GoogleMaps niet uit komt. Maak een Google API-key aan en selecteer een van de geo-location API's (ik weet zo even niet welke het meest geschikt is). Als resultaat van zo'n query zou je een JSON object moeten krijgen waaruit je alle deel-elementen kunt halen die je voor je completering (of correctie?) nodig hebt. Hou er rekening mee dat je iets serieus aan fout-afhandeling moet gaan doen. Dat heb je al als 0 of >1 zoekresultaten hebt. De Google APIkey vereist registratie en kost in principe

Begrijp me goed, Hans Erik. Ik heb helemaal geen problemen met de strikte, exacte benadering. Maar wat ik denk: a. dit FileMaker gedrag (versie <19? ) is ooit ontworpen; was geen bug, maar 'intended to be', als onderdeel van een poging een superflexibele ontwikkelomgeving neer te zetten ('Apple'-like, zou ik haast zeggen); b. Deze feature werkt nu - zoals het nu schijnt, zonder enig tamtam - niet meer. Gewijzigde spelregels zou je kunnen zeggen, en daarmee kunnen fouten ontstaan als 1001 bloemen voor degenen die er tot nu toe achteloos gebruik van hebben gemaakt. Neemt niet

Ehhh, als je nou als bcc een eigen (archief) e-mailadres meegeeft... Weet je exact wat er (al dan niet geautomatiseerd) het systeem uit gaat. Voor meer info check bijv. https://skeletonkey.com/filemaker-18-smtp-curl/ https://dbservices.com/blog/send-filemaker-html-emails of https://www.soliantconsulting.com/blog/html-email-filemaker/ No plugins required.

Mooie benadering, Hans Erik. Als je wilt verwijzen naar andere herhalende velden is het isoleren van het herhalingsnummer met Get (NummerBerekeningHerhaling) of Get(CalculationRepetitionNumber) wel onvermijdelijk, denk. Tevens dan erop letten dat je Extend (...) dan consequent toepast, anders wordt het niets.

Nou ja, bug fixing? Eerder een wijziging van de spelregels. Of misschien zelfs afwijkingen van de ontwerpfilosofie. Een numerieke waarde als een tekst kan direct als zodanig behandeld worden, en dat is wat je zou kunnen noemen de 'intelligentie' van low-code ontwikkelomgeving, in tegenstelling tot het strikte 'autisme' van en programmeertaal. En zoals eerder gesteld: de 'stiekeme' wijziging kan leiden tot bugs in bestaande systemen. En die zijn dan niet per se toe te rekenen aan 'incompetentie' van de ontwikkelaar.

En je mag aannemen dat bij interne container opslag hetzelfde geldt. Enkelvoudige opslag voor identieke bestanden. Zou ook iets leuks zijn voor het OS. Zat gisteren even te zoeken naar de wijze waarop je op de server de container mappen apart zet. Een vereiste is dat je aparte ('additional' volgens FMS) database folders gebruikt. Pas dan verschijnt de optie voor separate containeropslag. Was vroeger ook al zo, maar misschien toch iets transparanter.

Dat zeker, maar wel een potentieel risico voor bestaande systemen, waar die accuratesse niet consequent is toegepast. Die 'vergevingsgezindheid' of flexibiliteit om bijv een getal als tekstuele waarde toch als getal te behandelen was naar mijn gevoel typisch iets van FileMaker, zoals ook de mogelijkheid om altijd veld/tabel/script etc namen te kunnen wijzigen.

Is toch een kleine ramp als het klopt. Is die selectWeek wel een numerieke waarde? WeekofYearFiscal levert sowieso een numerieke waarde op, dus een getasnumer() zou niets kunnen toevoegen.

Ja, dat kan vrij gemakkelijk; het zit al in de naam, nietwaar. Het kan op 1001 manieren. De kunst is om te bedenken wat je precies wil of nodig hebt; de techniek volgt.

Ja, ik vond dat ook een hele prettige ontdekking. Heb het evenwel nooit geverifieerd; bij secure opslag is dat ook onmogelijk. Waarom denk je dat het daar anders is?

Dus wat jou betreft niet uit oogpunt van stabiliteit en performance, Hans Erik?

Leuke script uitdaging. Bibliografische informatie kan tricky zijn, en je moet je afvragen of jouw tabel de optimale indeling heeft voor deze referenties. En of er niet meer tabellen zouden moeten zijn (bijvoorbeeld een aparte tabel voor auteurs) en een aparte constructie voor deel-publicaties. Ik zou een globaal veldje gebruiken om de tekst in te plakken of integraal te importeren, en daarna een script elke regel (kennelijk een pdf bestand, hopelijk met voldoende consistente benaming) parsen en de beoogde records aan te maken en te vullen. En daar ligt ook de kern van je uitdaging:

Gebruik dan de calculatie variant van deze get-functie. Gaat prima werken. Maar zoals jij het stelt werkt de Self-functie waarschijnlijk ook. Schijnt een onderschat beestje te zijn.