burggraaf

@menno Die laatste indruk hadden wij ook. We mochten van de klant echter geen contact opnemen met de leverancier van deze 'nieuw' geleverde Mac en ook mochten we het OS niet opnieuw installeren. Daarnaast bleken er nog een maar rare issues (software waar geen licentie van was). Derhalve hebben we ons terug getrokken uit dit traject.

@menno De installer maakt niet uit zowel 17, 18 als 19 (laatste versies) geven hetzelfde probleem...

Ik probeer bij een klant fmpa 17 te installeren onder MacOS 10.15.5 via teamviewer. Mac is nieuw en clean. Installatie gaat prima incl. de licentie maar... Daarna houdt het op. Als je Filemaker wilt opstarten dan gaat hij weer vragen om licentiecodes en vervolgens krijg je allemaal half lege Filemaker vensters (tekst ontbreekt). FMPA 18 ook geprobeerd, zelfde verhaal. Filemaker start dus ook niet op. Doe ik het hier op dezelfde manier in de eigen omgeving op exact dezelfde manier ook op afstand (dus ook middels teamviewer met hetzelfde OS) dan is er geen enkel probleem. Wat kan hier mis zijn?

Dat is waar natuurlijk maar... Vervolgens hoef je met PHP e.a. geen licentiekosten te betalen of door te berekenen... De ontwikkelkosten zijn dan wellicht hoger maar het terugverdien model is anders. Als FileMaker ontwikkelaar moet je, als we het maandelijks zien, al meer licentiekosten afdragen dan andere ontwikkelaars maandelijks rekenen voor een complete on-line applicatie. Ook dat is zo, 1, 2 en 3 komt veel voor. Met een deprecated model voor runtimes blijft er weinig over kleinere standaardapplicaties. En... in een veranderende wereld vol kleinere bedrijven (ZZP markt groeit hier enorm) en andere, goedkopere, alternatieven (een appje welke éénmalig 5 Euro kost is voor veel mensen bijna toch echt de norm geworden) vallen daardoor toch heel veel potentiele klanten af. En als ze in het begin niet instappen is de kans ook veel kleiner dat ze later wel zullen gaan overstappen. Ook ik heb elke keer weer moeite om het te doorgronden. Het valt ook vaak lastig uit te leggen, zeker aan bestaande klanten. In mijn beleving gaat FileMaker er teveel vanuit dat bedrijven zelf een applicatie ontwikkelen gezien de lage ontwikkeldrempel. In de praktijk komt dit dus eigenlijk niet voor zeker niet bij de wat kleinere bedrijven. Niet alleen omdat men daar de capaciteit niet voor heeft maar ook omdat je inmiddels toch wel wat ontwikkelcapaciteiten nodig hebt om meer te kunnen maken als een kaartenbak (I loved Claris Filemaker 1.04... ;-) ). En ja, wat dan? Deze kleinere bedrijven hikken toch echt wel aan tegen licentie- en ontwikkelkosten. En de steeds maar groeiende, goedkope, on-line alternatieven dragen daar niet aan bij. Wij, als ontwikkelaars, kunnen best vinden dat prijzen, gezien hetgeen wat je krijgt, in verhouding zijn. En op zich vind ik dat ook zeker. Een middelgroot bedrijf welke een bedrijfsspecifieke applicatie nodig heeft (dus iets wat niet standaard is) heeft m.i. aan Filemaker een mooi product en hele goede tool waarin je snel verder kunt.

In een script heb ik voor het printen 2 opties gemaakt 1 met 'print dialog' on en print 'dialog off'. Dit is makkelijk als je gescript een aantal afdrukken wilt kunnen instellen met een veld. Heeft heel lang goed gewerkt maar sinds een aantal maanden is de print 'dialog off' instabiel. Vaak gaat het goed maar met enige regelmaat wordt er dan niets geprint, je kunt het script zo vaak uitvoeren als je wilt en deze wordt ook goed doorlopen (simpele loop), maar er komt niets. Zet je de regel weer op 'print dialog' on dan gaat alles goed (maar krijg je steeds het niet gewenste dialoogvenster waar je op 'ok' moet klikken). Suggesties voor een oorzaak?

Ehm... mijn kennis van OSX strekt niet ver genoeg om dit te bevestigen, ik was slechts op zoek naar een oplossing. Wel is het zo dat bij de 1 de schijf 'naamloos' heet en bij de ander 'Macintosh HD' (vraag me niet waarom). Dus zolang we met deze optie geen naamloos/MyRootDropboxFolder en Macintosh HD/MyRootDropboxFolder zou dat een optie kunnen zijn. Maar nogmaals... mijn kennis van OSC schiet daarin tekort.

Een creatieve denker bedacht het volgende: Maak op elk van mac's een aparte partitie welke op alle afzonderlijke mac's dezelfde naam hebben. Verplaats daarin de dropbox map. En inderdaad... daarmee kun je op elke mac dezelfde route naar de dropbox map genereren.

@peerke Ik snap wat je bedoeld, een dergelijk alternatief had ik ook al in gedachte, maar dat is niet waar ik naar op zoek ben. Dit omdat er op nogal wat plaatsen in de software gebruik wordt gemaakt van een ingesteld pad hetgeen het complexer maakt. Jouw suggestie is inderdaad 1 van de alternatieven als er geen mogelijkheid is zoals er onder Windows wel is.

Onder Windows kun je een netwerkverbinding maken met een driveletter. Dit is zeer handig als je gebruikers bestanden wilt laten wegschrijven naar een map welke voor elke gebruiker hetzelfde moet zijn maar de route er naartoe niet voor elke gebruiker hetzelfde is. Maar... Hoe doe je dat onder OSX? Ik heb nu OSX gebruikers welke ik vanuit FileMaker naar dezelfde dropbox map wil laten schrijven. Alleen... voor de ene gebruiker is de route naar de gewenste gezamenlijke dropbox map: naamloos/gebruiker_dit_ben_ik/opslag en voor de ander: Macintosh hd/gebruiker_ik_ben_een_ander/opslag Is er net als onder Windows een methode of mogelijkheid om, zonder dat je voor elke gebruiker de route naar de map hoeft bij te houden binnen FileMaker, een vaste route in FileMaker kunt zetten zoals een vergelijkbare methode onder Windows. Ik snap dat je OSX niet kunt werken met driveletters maar mogelijk dat je wel op een andere manier vergelijkbaar kunt routeren.

Probeer een snel herstel van office via programma's daarna werkt alles waarschijnlijk weer (probleem na een update van Windows).

Dat heeft op zich ook de voorkeur echter i.c.m. FileMaker Go wordt dit weer een lastige...

We, niet ik, zijn hier al een tijdje bezig met codesigning en runtimes en het lijkt erop dat we voor onze applicatie een methode hebben gevonden. Lijkt, want het is me nog niet helemaal duidelijk of het in alle gevallen werkt (maar het lijkt er wel op). Ik weet wel dat het een hele puzzel was om het in orde te krijgen en het is niet echt praktisch om het te doen maar... mooi als het werkt en je aan het eind van de rit een complete installer hebt. 'Next step' is om het via Applescript te kunnen doen zodat je niet alle stappen handmatig hoeft te doen (wel zo handig als je met enige regelmaat updates hebt). Maar ook dat zal wel weer de nodige tijd gaan kosten.

Klopt, x32 en x64 door elkaar heen geeft een foutmelding in outlook.

ESET AV is het probleem... wel apart..

Vreemd probleem hier op verschillende machines met zowel FM15 als FM16. Als we een sendmail script maken (ook gewoon simpel demosciptstap in lege nieuwe file) dan maakt Outlook 2016 wel het bericht aan laat ook de inhoud van het bericht zien maar bij het verzenden ervan is de inhoud verdwenen. Ook als je er iets handmatig aan toevoegt verdwijnt het bij het verzenden. Met het gewoon verzenden vanuit outlook heeft niemand problemen alleen met de sendmail scrip stap.... Weet iemand waar dat vandaan komt of hoe het te verhelpen is? Of iemand hetzelfde probleem?