pdf viewer?

[filemaster]

Filemakkers,

 

In een containerveld sla ik pdf bestanden op (gescande contracten). Nu wil ik graag met een knop de pdf bestanden in dat veld kunnen openen (inzien) in een nieuw venster. Is hier een mogelijkeid voor?

 

Alvast bedankt voor jullie reacties....

[fmwebshop]

Als je contracten meerdere pagina's beslaan;

Maak je een nieuwe tabel "pdf" aan om de afzonderlijke pdf pagina's in afzonderlijke records op te slaan.

De "pdf" tabel relateer je aan de invoertabel "contract" met als relatie het contractnummer.

In de invoerpagina van de "contract" tabel plaats je een portaal, nieuwe records maken toegestaan, van "pdf".

Hier kun je gemakkelijk je contractpagina's invoeren. (plakken).

Als je nu nog een "contract" layout aanmaakt met hetzelfde portaal uitvergroot over het hele scherm kun je hier door je contract pagina's heen scrollen.

 

Je kunt ook je pdf bestanden opslaan in een externe map, in Fm alleen een een verwijzings pad opslaan in een veld naar het bestand en dan je pdf bekijken in een webviewer.

De webviewer stel je in met het verwijzingspad.

[SuperWimmie]

Met de scriptstap Send event, waar je de container als veld invoert, kan je de inhoud van de container laten starten.

Als daar een bestand in zit dat Windows (of MAC?) herkent, dan wordt het bijbehorende programma gestart met de inhoud van het containerveld er in.

 

Is dit wat je zoekt?

[edc]

Met de scriptstap Send event, waar je de container als veld invoert, kan je de inhoud van de container laten starten.

Als daar een bestand in zit dat Windows (of MAC?) herkent, dan wordt het bijbehorende programma gestart met de inhoud van het containerveld er in.

Met de scriptstap "Go to field" met 'select/play' aangevinkt lukt het eveneens. In het containerveld is wel enkel de link naar het bestand opgeslagen.

[filemaster]

Mensen....

 

 

Superbedankt! Met één van deze opties gaat het zeker lukken!

 

Bedankt allemaal!

 

Filemaster

[Johnny]

Een PDF kun je naar mijn mening het beste invoegen als object (alleen in Windows) ZONDER link. Waarom? Omdat de PDF dan voor iedere gebruiker in een netwerksituatie is te raadplegen, zonder dat je de PDF hoeft te bewaren. Je kunt het beste een apart bestand maken om PDF's en andere bestanden op te slaan omdat het databestand waar al je gevoelige gegevens in staan anders te groot en te lomp gaat worden. Ik heb geen idee hoever je kan gaan in FileMaker wat de omvang van bestanden betreft, maar volgens mij kan het heel wat verdragen.

 

Wie kan er iets meer zeggen over de maximale omvang van WERKBARE FileMaker bestanden?

 

De opbouw is dan als volgt:

Bestand 1: Naw, facturen, actiepunten, contactnotities etc. (kerngegevens)

Bestand 2: Afbeeldingen, PDF's, Excel, Word etc. (containergegevens), ongelinkt, als object ingevoegd.

 

Mijn ervaringen hiermee zijn goed: even klikken op het bestand doet Acrobat reader of Word of anderszins openen. Geen geknoei met paden en gereserveerde mappen, gewoon alles in FileMaker. Je hebt wel een goede internetverbinding nodig met je server, maar dat is tegenwoordig bijna vanzelfsprekend. Verder moet je natuurlijk ervoor zorgen dat je bestanden zo klein mogelijk zijn. Eén TB aan mp3's laden is vragen om problemen, maar voor de rest kom je met verstandig beleid een heel eind.

[Peter Wagemans]

Wie kan er iets meer zeggen over de maximale omvang van WERKBARE FileMaker bestanden?

1 en ander hangt af van hoe WERKBAAR je computer is. De ene computer is de andere niet, ik heb klanten die servers draaien die maar 25MB/sec hd troughput geven, en heb vorige week een opstelling gezien op youtube die 2TB/sec haalde.

No kidding. Heb 'm even opgezocht.

 

Denk erom dat je niet alleen plaats moet hebben voor je bestand, maar ook tijd en ruimte voor voldoende backups van dat bestand.

Tijdens het backuppen van je bestand is de server nogal aan de trage kant, en het hangt van de snelheid van je harde schijven af hoe lang die backup duurt. Reken maar uit.

Steek minstens je tabel met bestandsenclosures in een apart bestand, zodat je tenminste kunt blijven werken met de rest van de bestanden als de server nogal lang aan de backup van dat ene bestand bezig is.

 

Mijn ervaringen hiermee zijn goed:

De mijne niet echt, en ik knoei liever wat met paden tijdens de opstelling, als dat geknoei éénmaal in orde is, dan heb je er geen omkijken meer naar.

 

Wat ga je doen als je database blijkt kapot te zijn na 15.000 records erin opgeslagen te hebben. Backupje terugzetten? Zeker van dat dat backupje wel goed is? Vanaf wanneer gaat het fout met de db, misschien zijn er random records die problemen geven... Kleine nachtmerrie hoor. Die problemen heb je niet als je je bestanden als externe referenties houdt.

 

Met externe referenties is je bestanden-tabel zeer compact, en kan je je server "gelinkte" bestanden perfect incrementeel backuppen. Stel je hebt een verzameling van 1TB aan extern gelinkte bestanden, en je verandert gemiddeld 5 bestanden per dag. Als je elke dag backupt met externe referenties, dan heb je na 1 week 25 bestanden extra gebackupt. Met een file die alles intern vergaart... 5 terrabyte.

[andries]

het nadeel van alles op een FileServer te zetten is dat als iemand het bestand delete op de fileserver ( manueel ) dat dan bepaalde functionaliteiten niet meer werken... het deleten van data in een container veld kan op zich zeer goed gecontroleerd worden.

 

Dit is natuurlijk ook het geval voor een fileserver, maar in het geval waar het bij ons misliep is dat er dus een user was die niet wist van waar al die bestanden kwamen en ze dan maar mooi is beginnen deleten... (we schreven namelijk al de bestanden weg in een overeenkomende projectfolder op hun fileserver) Nadien een bestand verzenden vanuit FileMaker ging wat moeilijker...

 

Ik zelf heb nog nooit echt problemen gehad door al mijn bestanden in een aparte FileMaker file op te slaan, maar ik begrijp wel de bezorgdheid dat een FileMaker file altijd corrupt kan geraken en wat dan... stof tot nadenken iig

 

Trouwens het filmpje is vrij imposant. doet me denken aan de reportage op Netwerk over "de broncode". http://www.netwerk.tv/node/3518

[roncatto]

Heeft er iemand al zo een script gemaakt waarbij je twee knoppen hebt?

1 knop om een pdf file in de database op te slaan

een tweede knop om deze pdf file te tonen

Kan iemand een voorbeeldje uploaden aub voor mac?

[Peter Wagemans]

Ja hoor. Een goeie oefening.

Bijgevoegd een voorbeeldbestandje met een klein PDFje.

Het ding heeft 4 records:

1. een externe PDF ( bestand op mijn desktop )

2. een interne PDF ( deze zal onmiddellijk voor iedereen werken )

3. een externe PDF met een Windows pad

4. een externe PDF met een cross-platform pad

 

De "Voeg In" knop, daar hangt zelfs geen script aan, zo simpel is die. Je hebt zelf de keuze om een externe link te gebruiken, of het document op te slagen in je FileMaker bestand.

Het veldje "pdfinfo" heeft een auto-enter calculatie dat de informatie van de file stockeert zodra je het veld "pdfContainer" invult of aanpast.

De formule is "GetAsText ( pdfContainer )"

 

Aan "Open Bestand" hangt een scriptje dat de zaken ietwat uitgebreider aanpakt.

Het kan 3 mogelijkheden aan: een intern document, een extern document op de Mac, of een extern document op Windows.

FileMaker heeft een eigen pad formaat, en ik was te lui om dat nu even zonder fouten te gaan omzetten naar het OS pad, dus pikte even volgende custom functie op: http://www.briandunning.com/cf/902 , plakte deze in Clip Manager en plaatste die zo snel in de file. De functie heet FilePathToOS(), en ze werkte zowel voor Mac als voor Windows.

 

In het script wordt er nagekeken of er "file:" in het veld pdfinfo zit. Is dat niet zo, dan exporteert het script de inhoud van het veld naar de temp folder, en diezelfde script stap opent het bestand ook. De KISS ( Keep It Simple and Stupid ) manier dus.

 

Als die "file:" string wél in de pdfinfo zit, dan hebben we schijnbaar een externe referentie, en we kijken even na of we respectievelijk op Mac en Windows de string "filemac:" of "filewin:" hebben. Is dat zo voor Mac, dan opent het script het bestandje via een klein applescriptje dat de applicatie "Preview.app" vraagt om het bestand te openen.

Is dat zo voor Windows, dan openen we het via de "Send Event" script stap. Tragi-komisch is het dat deze script stap zijn origine op de Mac vindt, gepatcht is om op Windows te werken, en vervolgens vanaf 1 of andere versie faalt op Mac...

 

Beide manieren gebruiken de FilePathToOS() custom functie, een ding dat de FileMaker manier om een pad te specifiëren omzet naar het pad zoals het operating systeem dat graag heeft. Als je geen FileMaker Advanced hebt, bekijk dan de calculatie op bovenstaande link en zet ze in een gewoon calculatieveld.

 

In het laatste record heb ik manueel een aanpassing aan pdfinfo gedaan, die bevat dus zowel het pad voor Mac als dat voor Windows. Hoewel het bestand via een externe link is opgeslagen, kan het hierdoor toch op beide platformen geopend worden.

 

Hopelijk kan je hier mee verder.

PDF database.fp7

[andries]

He Peter,

 

volgens mij is het op Mac wel mogelijk om met de send event een pdf te openen. Met de event class "aevt" kan je met odoc het document openen, met pdoc het document printen etc.

 

Ik ga ervan uit dat dit niets nieuws is voor jouw. Is er een rede dat je het dan toch doet via AppleScript? Veiliger, robuuster, betrouwbaarder, sneller?

 

Groetjes

 

Andries

[Peter Wagemans]

Dat dacht ik ook, maar toen deed FileMaker hier lastig over. Ben dit toevallig vandaag bij een klant aan het toepassen, en zie nu mijn domme fout. Je MOET op Mac een applicatie aanduiden, op Windows hoeft dat niet.

Als je dat niet doet:

Ik wist niet goed waar het probleem zat door deze - een beetje lullige - foutmelding van FileMaker.

[andries]

Peter,

 

die fout doet mij vermoeden dat het pad naar je bestand niet juist is. Ik heb die ook al eens gekregen, toen bleek dat ik vergeten was om een pad aan te duiden waar het document zich bevindt.

 

Hier heb ik een voorbeeldje waar het perfect werkt, met de send event (althans op mijn mac toch). Als je de $path uit de document calculatie haalt en die gewoon leeg laat krijg je bovenstaande foutmelding.

 

Ik weet niet of dit iets helpt.testExport.fp7

[Peter Wagemans]

Andries, je begrijpt me verkeerd. Ik heb geen enkel probleem meer, maar gaf aan dat je de applicatie die het bestand opent MOET aanduiden, anders krijg je de lullige foutmelding, die blijkbaar jou ook op het verkeerde been zet.

 

Ik wou toch even zeker wezen dat ikzelf je niet misbegreep, en heb textExtport.fp7 gedownload en jet script eens geprobeerd.

Heel bijzonder dat dit voorbeeld bij jou werkt, maar bij mij in elk geval niet.

Get ( TemporaryPath ) geeft een FileMaker geformateerd pad, ( met forward slashes en zo ) maar zonder een prefix en dat gebruik je ongewijzigd voor je export.

Dit geeft "logischerwijze": tijdens de export script stap, hoewel de foutmelding weer een hoog lulligheidsgehalte heeft, FileMaker blijft de traditie van verwarrende foutmeldingen trouw...

Je moet filemac, filewin, imagemac of imagewin & ":" vooraan aan je pad toevoegen, anders werkt die export echt niet. Ik ben zeer verrast dat dit bij jou wel werkt. Misschien heb je het niet getest?

Over de foutmelding: die zou misschien iets correcter zijn als ze zou bestaan uit:

"Het pad dat je opgeeft voor export is niet geldig." en daar nog even bijzet in kleine lettertjes "Het export pad is niet in FileMaker formaat.".

[rmw]

Je moet filemac, filewin, imagemac of imagewin & ":" vooraan aan je pad toevoegen, anders werkt die export echt niet.

 

Dat moet alleen op windows, mac weet een FM pad dat begint met een slash gewoon op te lossen.

Windows loopt vast op /C:/ en moet dus file:/C:/ hebben.

 

Overigens is mijn ervaring dat 'file' op beide platformen zonder problemen werkt. Maar ik laat me graag overtuigen van het tegendeel

 

rmw

[andries]

Peter

 

ik begrijp je wel denk ik Maar ik begrijp ook dat het niet werkt... steek eens een andere file in de container, want mijn pdf staat er in als "reference" (of download de bijlage van dit bericht)... je kan hem zelfs niet manueel exporteren. Wat verklaart waarom het bij mij werkt en bij iemand anders niet... Mea culpa.

 

Verder werkt dit script bij mij zonder een applicatie aan te duiden (wat toch was wat moest volgens jou). Zelfs verder, ik gebruik dit bij een klant die zijn excel, word etc documenten opslaat in FileMaker. Op deze manier opent hij steeds het juiste programma zonder dat ik mij druk hoef te maken wat het juiste programma voor een bepaald bestand is (klant werkt op Mac).

 

Ik heb mijn temporary folder manueel geledigd. Computer opnieuw opgestart. Temporary folder nog altijd leeg. Start FileMaker op en FileMaker creeert 3 bestanden ( een .out en twee .tmp bestanden ) in de temporary folder. Ik run het script en in de temporary folder wordt een folder S10 gecreerd met daarin mijn bestand test.pdf.

 

Voor al de duidelijkheid: Mac OS X 10.5, FMPA 10. Heb dit nog niet op windows of zo getest, dus daar kan ik niets over zeggen.

testExport-1.fp7

[Peter Wagemans]

Nu werkt hij inderdaad wel. Nu snap ik ook de foutmelding, FileMaker vond dus niet het bestand dat hij moest exporteren.

En rmw heeft me iets bijgeleerd. Leuk dat het kan op Mac - minder leuk op Windows.

Ik denk echter niet dat ik scripts zonder die prefix ga schrijven. Het lijkt me een ongeducumenteerde "feature".

"file" lijkt me een goeie om te gebruiken voor relatieve paden ( t.o.v. van de FileMaker file? ), maar gezien servers meestal een andere pad hebben voor Mac of Windows, zou ik het niet durven gebruiken in development.

Ik ga eens wat graven in de FileMaker documentatie. Ik voel me niet meer op mijn gemak...

[rmw]

En rmw heeft me iets bijgeleerd.

 

Het hoogste doel is bereikt.....

Wat is er nu nog na te streven?

 

 

rmw