All Activity
This stream auto-updates
- Last week
-
Hi Farbice, Thanks for your explanation. You have the right to have an opinion. Let me rephrase that. Your company is one of the contributors of the code of this project, but not the only one. The code in this project is more than your 20 lines of ( very nice ) JavaScript. Remember, that from the moment that you put it in the public domain 2 years ago, it became free for everybody to build upon. And kudos for that. But by doing so, you also gave it away. You can continue calling it yours, but I do not agree that it's yours in the sense of giving you any claims on how derivative work should be published. I do not keep you from taking the project on github ( https://github.com/fmWebViewerWorkingGroup/fmBridgit ) , and fork your own maybe much better one. If you think you should manage that one, please do. Pease let's not continue to argue on this. You made your points and I do not agree. My anger is gone, but my opinion remains.
-
Ja maar da's nauutlijk wel een Apple processor. Dat zal hoogstwaarschijnlijk wel gebeuren. Het zijn wel 2 armen.
-
Top Menno, dit blijkt inderdaad het probleem geweest te zijn. Hartelijk bedankt voor je assistentie. -
SOLVED! In het script "Send Message" op regel 49 wordt de variabele $mail_file ingesteld met TextEncode ( $mail_content ; "utf-8" ; 3 ) Volgens de help van FMP op https://fmhelp.filemaker.com/help/18/fmp/en/#page/FMP_Help%2Ftextencode.html worden de line-endings waar de mailserver van jouw klant over klaagt ingesteld als Line feed (modern Mac, Unix/Linux standard) en dat is onjuist voor een windows-mailserver. Als je dus de instelling van de variabele wijzigt in: TextEncode ( $mail_content ; "utf-8" ; 4 ) gaat het verzenden wél goed. -
Hallo Menno, hier vind je dit voorbeeld https://dbservices.com/articles/send-filemaker-html-emails/
-
Ik heb inmiddels alle varianten van berichten getest en zelfs de meest simpele "Hello World!" als platte tekst mislukt al.
-
Ik heb ook nog wat aan het spelen geweest met een toepassing van DB Services om Html mails te versturen en hiermee lukt het blijkbaar wel zonder problemen. Een inline image toevoegen lukt me hiermee ook, maar ik ben nog aan het bekijken hoe ik hier een bijlage kan bij toevoegen. Dit is blijkbaar jammer genoeg niet voorzien bij het voorbeeld.
-
Voor alle duidelijkheid (ook voor de meelezers) de ontvangende mailserver heeft problemen met het doorsturen van het bericht. De smtp-server doen gewoon hun werk en nemen de berichten aan en versturen ze.
-
Ik heb het geprobeerd te versturen naar het adres dat je me via de PB hebt gegeven en met smtp.office365.com krijg ik een reply van de mailserver dat het bericht niet kan worden doorgestuurd. Gebruik ik echter smtp.gmail.com dan gaat het blijkbaar wél goed en ook via mijn eigen smtp-server gaat het probleemloos. Het lijkt dus gerelateerd aan office365.com te zijn.
-
Menno, ik heb met Patterncount de string die verstuurd wordt door Invoegen uit Url gecontroleerd op de verschillende karakters die U opgeeft. Enkel met Patterncount ( $text ; char(32)) vind ik dat deze 12 x zich voordoen. Als ik hier dan de Substitute op toe pas zoals hierna vermeld Substitute ( $text ; char(32) ; " " ) blijf ik toch steeds char ( 32 ) terug vinden omdat dit hetzelfde is. Of zie ik hier iets over het hoofd. Ik heb effectief met het voorbeeld bestand van Skeleton getest nadat ik de foutmelding gekregen had. Ik heb het nog nog even opnieuw geprobeerd en de fout blijft. Ik stuur je zodadelijk een PB met het mail adres van de bestemmeling. Kan U ook even van bij U uit proberen naar het mailadre. Zo kunnen we alvast uitsluiten of het probleem bij de ontvanger of de afzender zit.
-
Aha dat is dus de truc.. Met open record request wordt de status geforceerd. Ik had zelf al wat in elkaar gesleuteld met een globale variabele maar met deze functie is dat niet meer nodig! ?
-
Ja, zoiets moet het vast zijn. Ik heb nu even FMS17 teruggezet. En kijk dan maar direct naar FMS19. Jammer dat zoiets verandert. Zal wel met veiligheid te maken hebben. Dank.
-
Die get ( recordStateOpen ) werkt inderdaad niet altijd lekker, want soms geeft die pas een 1 bij de tweede toetsaanslag. In het bijgevoegde voorbeeld zit een manier om dat probleem te omzeilen en is redelijk universeel inzetbaar. RefreshObject.fmp12
-
Ik heb net even het voorbeeldbestand van Skeleton Key gedownload en vervolgens 3 smtp-servers geconfigureerd: Gmail, Office365 en mijn lokale smtp-server. Vervolgens heb ik simpelweg alle voorbeeldjes uit het bestand gebruikt om te versturen via beide smtp-servers naar mijn gmail-account. Alles kwam zonder problemen aan, behalve dat via Office365 de mailtjes met attachments er allemaal een minuut of 2 extra over deden. Alle anderen kwamen vrijwel meteen binnen, dus er zullen onderweg wel attachments worden gecheckt oid. Er verscheen echter geen enkele foutmelding. Heb jij het voorbeeldbestand gebruikt of heb je de handleiding gevolgd en zelf de scripts etc. gebouwd? Substitute ( text ; "π" ; "<br>" ) Zal geen "foute" karakters weghalen, behalve π die je bijna nooit zal tegenkomen. Je hebt mogelijk last van tekst die is gekopiëerd uit een webbrowser en daar kunnen CRLF, LF, CR en allerlei "whitespaces" in staan waar je over valt. Die kan je het simpelste weghalen met: Susbtitute ( text ; [ Char ( 13 ) & Char ( 10 ) ; ¶ ] ; // CRLF [ Char ( 10 ) ; ¶ ] ; // LF [ Char ( 13 ) ; ¶ ] ; // CR [ ¶ ; "<br />" ] ; // Wordt html-return [ Char ( 11 ) ; " " ] ; // Line-tab [ Char ( 12 ) ; " " ] ; // Form-feed [ Char ( 32 ) ; " " ] ; // Standaard spatie [ Char ( 133 ) ; " " ] ; // Lijn overloop [ Char ( 160 ) ; " " ] ) // No-break spatie Zie https://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf-and-cr-line-break-types om het verschil te kennen tussen de 3 line-breaks en zie voor de whitespaces bijvoorbeeld https://nl.wikipedia.org/wiki/Whitespace_(karakter)
-
Ik denk niet dat het probleem in de tekst zelf zit. Ik heb intussen de mail inhoud beperkt tot een minimum om hier mee te testen, maar het probleem blijft aanhouden. Hierna ziet U de broncode van de verzonden mail. <!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Test Email</title> <meta name="viewport" content="width=device-width, initial-scale=1.0"> </head> <body style="margin: 0; padding: 0;"> <table border="1" cellpadding="0" cellspacing="0" width="100%"> <tr> <td> Dit is een test ! </td> </tr> </table> </body> </html> Voor de integratie in mijn toepassing had ik een voorbeeld van Skeleton Key gevolgd. Ik heb nu naar de leverancier een test verstuurd vanuitde toepassing van Skeleton en krijg hier dezelfde fout. Het probleem zit dus niet in het gedeelte dat ik aangepast heb of in de inhoud van de mail, maar zit dus in het voorbeeld van Skeleton.
-
Ik ben wat aan het testen om Html mails te verzenden in met Filemaker 19 volgens voorbeelden met cURL die ik op internet gevonden heb. Ik dacht dat alles functioneerde omdat de test die ik verstuurde naar mij zelf, kwam netjes binnen. Nu stuur ik vandaag een eerste mail naar een leverancier en krijg ik volgende melding : Your message contains invalid characters (bare line feed characters) which the email servers at XXX don't support Ik heb intussen Substitute ( $text , "π" , '<br>" ) toegepast in het script maar zonder resultaat. Iemand een idee ?
-
Heb je wel je calls aangepast/gecontroleerd voor FileMaker 18? Op het eerste gezicht zou ik zeggen dat de autorisatie niet klopt en hij geen geldig token krijgt. Weet niet meer uit mijn hoofd wat er gewijzigd is, maar het is verstandig de calls even na te lopen om er zeker van te zijn dat de syntax voor 18 nog klopt.
- Earlier
-
Blijkbaar zat ik op de verkeerde plaats voor de link van Visual Studio 2019 x64 Redistributable. Ik heb hem hier teruggevonden. Alles lijkt mij terug in orde te zijn.
-
Als je in een veld aan het typen bent zou je verwachten dat get ( recordStateOpen ) op 1 staat. Dit is echter niet het geval. Als ik een veld met een script set dan wel. Doel is om een Save knop / Cancel knop te tonen als het record open staat. Ik heb op de layout auto save uitgezet en krijg je het FM save/cancel dialoog als je naast het veld klikt.
-
Ik heb bij mijn versie Filemaker 17 altijd een link gehad met de de MySql database van onze website. Hiervoor had ik toen een ODBC connector moeten installeren. Na de upgrade naar Filemaker 19 merk ik dat deze connectie niet meer functioneert, dus vermoed ik dat ik nog even opnieuw moet doen. De ODBC connector haal ik van de deze site. Hier selecteer ik Windows, 64 bit en de Msi installer. Zodra ik deze uitvoer krijg ik een melding dat deze toepassing Visual Studio 2019 x64 Redistributable nodig heeft. Als ik dit op zoek op internet vind ik deze link. Wat installeer ik hier nu van of is er een andere manier om via Filemaker 19 een link te maken naar een externe MySql database ?
-
dat is ook zo, nogmaals bedankt
-
Beste mensen, ik heb een database verplaatst van de FMS17 naar FMS18. Op de FMS17 werkt de API-call prima. Op de FMS18 lijkt de opeens niet meer te werken. Request validation failed: Parameter (Authorization) is required In FMS is natuurlijk wel de API-access geactiveerd. Iemand een suggestie?
-
Je kan je vragen altijd op dit forum stellen, er zijn tientallen gebruikers die je met plezier zullen helpen.
-
Ook met iets dergelijks. Heel goed geholpen, je zult denken dat ik nog niet zoveel progress heb gemaakt in die twintig jaar Hoe dan ook heel erg bedankt en ik ben maar zo brutaal of ik je als het nodig is weer om hulp mag vragen wellicht met je mailadres. Voel niet verplicht maar zou wel heel er leuk zijn
-
Ja, maar waar ik je precies mee heb geholpen, weet ik ook niet meer. Ik weet alleen nog dat de applicatie payship heette, want je had me een kopie gegeven om te bekijken en aan te passen. Was nog in de tijd van inbellen met ISDN enzo, dus toen waren we niet continue online en smartphones hadden we ook nog niet ?
