Stardust

Misschien een domme vraag maar wat mij betreft wel belangrijk, zijn de printproblemen in v.11 nu eindelijk al opgelost?? Kunnen we nu eindelijk (terug) gebruik maken van scripts om specifieke printopdrachten naar verschillende soorten van printers te maken? Ik erger me al jaren over dit probleem maar blijkbaar schijnen niet veel mensen een nadeel hier in te zien maar wat mij betreft blijft afdrukken toch één van de fundamentele taken waarvan je van verwacht dat dit in 2010 nu eindelijk ook terug met Filemaker feilloos mag lopen . Met vriendelijke groet @All, Danny

Ari, Bedankt, dat zie er zo interessant uit dat ik dit toch eens ga uitproberen!

Tackenco, Ik begrijp heel goed wat je wil zeggen maar wanneer je tienduizenden records hebt is dat echt niet vanzelfsprekend hoor. Het is trouwens oude FM school dat je de afbeeldingen extern plaatst en enkel een verwijzing naar de afbeelding in je bestand verwerkt. Het is helaas niet zo dat bij het effectief invoegen van een foto de grootte van je database exponentieel stijgt met de grootte van deze afbeelding maar dat deze per afbeelding veel groter wordt. Komt daarbij ook dat hoe groter je bestand wordt on 'onwerkbaarder' (foei wat een slecht woord ) het wordt! Ik vrees dat rmw het bij het rechte eind heeft en dat het niet echt mogelijk is, rest me eventueel het 360 script eens te bestuderen dat Hendrik hiervoor aanhaalde ... Alleszins mocht ik een resultaat bekomen zal ik het met de (Clarify) wereld delen Maar toch bedankt voor het meedenken hoor. Met vriendelijke groet, Danny

Pjotter, Hierna de gebuikte velden, ik hoop dat het niet te gecompliceerd is ... Candidate_PathCalc Case( TypeExam = "SRC" ; "imagewin:/" & Substitute( Candidate_Path; "\\"; "/") & "Photo_SRC/" & Left(Candidate_Name;1) & "/" ; TypeExam = "VHF" or TypeExam = "G-VHF" ; "imagewin:/" & Substitute( Candidate_Path; "\\"; "/") & "Photo_VHF/" & Left(Candidate_Name;1) & "/" ;l "" ) Candidate_PhotoPath If ( not IsEmpty (Candidate_Name) or not IsEmpty (Candidate_Initials) ; Candidate_PathCalc & Candidate_Photo_Name ; "" ) Candidate_PathCalc Case( TypeExam = "SRC" ; "imagewin:/" & Substitute( Candidate_Path; "\\"; "/") & "Photo_SRC/" & Left(Candidate_Name;1) & "/" ; TypeExam = "VHF" or TypeExam = "G-VHF" ; "imagewin:/" & Substitute( Candidate_Path; "\\"; "/") & "Photo_VHF/" & Left(Candidate_Name;1) & "/" ; "" ) Candidate_Photo Candidate_PhotoPath MVG, Danny

Helaas maar geen soelaas ... De oudste truc uit het boekje, we nemen de alternatieve afbeelding en plaatsen daar het afbeeldingsveld over werkt evenmin daar de tekst v/d berekening dan getoond wordt Het voorbeeld van pjotter werkt evenmin binnen mijn situatie ... nochtans zou dit de oplossing moeten zijn, in geval er geen effectieve foto bestaat dient er een alternatieve afbeelding getoond worden. Maar dit lukt niet daar men steeds een resultaat in het veld Foto heeft. Dit veld is een berekening zoals in mijn eerste bericht bovenaan omschreven met als resultaat een container of in mensentaal een foto. Wordt er op dit pad niets gevonden, verschijnt de befaamde tekst (zie bovenaan) dus is er steeds een inhoud zodat de inhoud niet kan getest worden via een expressie als IsEmpty of Case(veld_Foto = "") want er is steeds een (niet gewenste) inhoud Waarschijnlijk zal ik er maar met dienen te leven, weerom helaas ... maar misschien dat hiervoor in FM 17 of 18 hiervoor een oplossing aangereikt wordt Desondanks toch iedereen bedankt voor het mee denken Greetz 2 All, Danny PS: hierna de combinatie van de 2 velden over elkaar, u ziet ongetwijfeld (de voor mij) ergerlijke tekst

Pjotter, Bedankt, dit is zeer nuttig en ik kijk zo snel als mogelijk of ik dit kan integreren, jouw voorbeeldbestand werkt alleszins zoals ik het zou wensen. Ik houd je (en de anderen vanzelfsprekend) op de hoogte ... Beste Henk, Je hebt overschot van gelijk ... en ik hoop dat je het me niet kwalijk neemt, maar niet iedereen hier is zelfstandig ontwikkelaar en bijgevolg zijn plugins voor sommigen onder ons geen echt alternatief. Sommige broodheren zijn verdomd moeilijk te overtuigen van dergelike bijkomende functionaliteit zeker wanneer men er rekening met houdt dat Filemaker niet bepaald een lowcost programma te noemen is. Tot spijt van de plugin ontwikkelaars (die ik zeer waardeer trouwens) vind ik het erg dat men relatief veel geld spendeert aan een product en dan achteraf nog bijkomende investeringen dient te doen om bijkomende functionaliteit te verkrijgen, die en dit weerom volgens mijn bescheiden mening, reeds in FM dient ingebouwd te zijn. Ik heb deze discussie reeds gevoerd en heb begrip voor alle standpunten maar eveneens voor m'n eigen standpunt vanzelfsprekend Als zelfstandig ontwikkelaar vertrekt men van een andere en zeer begrijpbare basis, deze bijkomende kosten kunnen verrekend worden in het project, maar het hoeft geen betoog dat zeker ten tijde van recessie het idealer zou zijn dat dit niet hoefde en deze ontwikkelaars hetzij hun product goedkoper zouden kunnen plaatsen of hun eigen winst vergroten. Alleszins toch bedankt voor je antwoorden en ik bekijk zeker de opgegeven links!! Met vriendelijke groet en vooral dank aan al de geciteerden en aan al de andere topic deelnemers evenals aan de lezers ... nu maar hopen dat ik niemand vergeet

Beste Harry, Geloof me, de knutselfase ben ik reeds voorbij en ook hier haalde ik geen bevredigend resultaat als ik het me nog goed kan herinneren ... de tekst 'Dit bestand kan niet worden gevonden: bestandsnaam.jpg', blijft steeds verschijnen, helaas, en een andere kleur van tekst brengt evenmin soelaas Maar toch bedankt voor de tip!

Waarom eigenlijk? Wel dit is héél eenvoudig dan moet ik deze aankopen op eigen kosten, testen en uitvoerig testen en maar hopen dat het allemaal werkt binnen de bestaande configuratie en dan heel hard bidden dat ik het terug betaald krijg en gezien ik atheist ben, is mijn geloof in de overheid niet echt groot te noemen vandaar dat ik liever geen gebruik maak van plugins MVG, Danny

Harry, Bedankt voor de snelle reactie ... maar dit kan ik inderdaad niet ... De fotos staan elders op externe server en d.m.v. een samenvoeging (berekening) wordt de link gemaakt en vervolgens de foto getoond in het betrokken containerveld. Het probleem is dat ik op geen enkele wijze kan controleren (via FM vanzelfsprekend) of dat deze al of niet echt bestaat. Wanneer ik een controle doe op dat bewuste containerveld (rekenveld met als resultaat container) krijg ik altijd hetzelfde resultaat daar deze inhoud altijd gebaseerd is op de inhoud van de velden van het record. Concreet wordt de samenstelling gemaakt d.m.v. : "imagewin:/" & path & "/" & Veld:Achternaam & " " & Veld:Voornaam & " .jpg" Voor alle duidelijkheid, het gaat hier om FM 8.5 en Windows XP (of VISTA of 7). Alleszins bedankt voor het mee denken!! MVG, Danny

Na eindeloos zoeken en dankzij heel veel hulp van verschilende gebruikers van dit forum is het me uiteindelijk gelukt een foto op de layout te tonen en ondertussen werkt dit systeem nu toch al enkele jaren. Maar nu zoek ik me reeds geruime tijd te pletter naar een volgende oplossing: Wanneer er van betrokkene geen foto bestaat, zou ik graag toch een afbeelding op de layout willen tonen, dit staat nu eenmaal veel netter dan de foutboodschap die Filemaker in het (berekende) containerveld plaatst 'Dit bestand kan niet worden gevonden: bestandsnaam.jpg'. Aangezien de foto geplaatst wordt aan de hand van allerlei berekeningsvelden die gebaseerd zijn op de inhoud van de veldwaarden van het record, kan er geen test gedaan worden op het betrokken (berekende) containerveld daar hoe dan ook er altijd inhoud is in dit veld, hetzij de bedoelde afbeelding en indien er geen afbeelding bestaat de tekst 'Dit bestand kan niet worden gevonden: bestandsnaam.jpg'. Vanzelfsprekend voelt u mij reeds komen ... kan ik dit ondanks toch nog oplossen zodat wanneer er geen foto van het record (slechts één afbeelding per record) bestaat er een andere afbeelding i.c. een containerveld dat via een relatie getoond wordt? Ik kijk graag uit naar alle antwoorden maar zonder ondankbaar te willen tonen wil ik het gebruik van plugins ten zeerste vermijden. Met dank bij voorbaat en vriendelijke groet, Danny PS: ik stem morgen tegen de brug ... dan nog liever meer (gratis!) tunnels!

rmw, Ik denk dat je hiermee de nagel op de kop slaat, want inderdaad soms werkt het wel, andere malen niet ... ik ga die instelling is nakijken bij al de clients ... waarschijnlijk zit daar het probleem! Eveneens aan Pescador, bedankt, dit is eventueel ook een oplossing maar ik denk dat voorlopig rmw het bij het rechte eind heeft. Alleszins, JeanWM, in gedachte, besef ik steeds meer en meer hoe belangrijk uniformisering is, vasthouden aan de 'oude' principes is nog steeds de beste wijze om compatibel te blijven naar de toekomst toe. Met dank aan iedereen voor deze bereidwillige medewerking, zonder jullie zou Filemaker heel wat van haar glans verliezen! Met vriendelijke groet, Danny

Hoi Jean, De foto's worden ingescand en op de server geplaatst. De benaming van deze fotobestanden gebeurt als volgt: Familienaam, spatie, Eerste Voornaam, spatie, Initiaal v/d 2de voornaam, spatie, Initiaal 3de voornaam, punt (.), jpg In onze Filemakerbestanden worden deze foto's getoond, dus niet opgeslagen aan de hand van deze gegevens. Het veld Foto is een rekenveld met de volgende berekening: If ( not IsEmpty(Candidate_Name) or not IsEmpty(Candidate_Initials) ; PathCalc & Candidate_Name & " " & Candidate_Initials & "." & "jpg" ; "" ) Het veld PathCalc is een rekenveld met de volgende berekening: Case( TypeExam = "SRC" ; "imagewin:/" & Substitute( Path; "\\"; "/") & "Photo_SRC/" & Left(Candidate_Name;1) & "/" ; TypeExam = "VHF" ; "imagewin:/" & Substitute( Path; "\\"; "/") & "Photo_VHF/" & Left(Candidate_Name;1) & "/" ; "" ) Dit gaat allemaal hele goed, er wordt een record aangemaakt, is er een foto van de ingegeven persoon wordt deze automatisch op de layout getoond. Enkel wanneer er een apostrophe gebruikt wordt in de naam (Candidate_Name) zoals bvb. d'Hooghe of D'Hondt, enz... wordt de foto niet opgehaald desondanks dat de gegevens van het record wel perfect overeenkomen met de benaming v/h fotobestand. Een tweede probleem zijn de voornamen met koppelteken zoals bvb. Jean-Louis, Henri-Pierre, enz... daar wordt bij de omzetting in Filemaker het koppelteken ( - ) niet gezien en wordt deze voornaam gesplitst, wat vanzelfsprekend ook problemen geeft bij het ophalen v/d foto. Een onaangenaam probleem dat zich dus af en toe voordoet Met vriendelijke groet, Danny

Lang geleden dat ik me hier nog eens gemeld heb ... persoonlijke familiale problemen hebben dit helaas verhinderd Maar nu worden we weer met een probleem geconfronteerd waarbij ik beroep moet doen op jullie wijze raad. In onze database wordt de pasfoto automatisch opgehaald, ik zou bijna durven zeggen dat dit probleemloos gaat ware het niet dat we op een probleem stoten bij familienamen waarin een apostrophe of het ' teken in voorkomt, zoals bvb. d'Haeseleer, 't Kindt, enz... De foto's hebben allemaal een bestandsnaam, gebaseerd op de persoonsgegevens, d.w.z. Familienaam spatie en Voornaam. In onze database kunnen we dan eenvoudig deze velden samenvoegen om zo de juiste pasfoto op te halen met uitzondering van bovenstaande 'probleemnamen'. De fp7 bestanden worden gehost op FM server en geopend via FM 8.5 clients, allen onder Windows XP werkend. Heeft er iemand een oplossing bij de hand aub, liefst eentje die vrij snel kan toegepast worden Met dank voor de antwoorden, Danny

Soms zijn de eenvoudigste zaken, de meest wonderbaarlijke! Ik sta verstomd! Danny

Tegen zoveel geweld kan ik (helaas) niet op! Ik zou zeggen, 'meer van dat!' Danny

Wat jij nodig hebt m.i. is de case functie ... Meer info op: http://www.filemaker.nl/help/FunctionsRef-32.html Greetz, Danny

Optic, dergelijke tips zijn nooit offtopic! Trouwens die developer tool, prachtige oplossing om al mijn verspreide tips in samen te voegen. Misschien een tip voor velen, om te beginnen al de AVD tips hierin plaatsen en bovenaan nog ergens een link naar dit forum maken! Bedankt! Jean ... VTM ? Wat wil je me nog aan doen, Vitaya misschien ? Alleszins, ik werk rustig voort en zend je nog wel wat. Danny

Ai ... dat is pijnlijk En te zeggen dat ik dringend een nieuw evacuatieplan moet opstellen en door het zoeken naar een FM oplossing veel tijd verloren heb ... ik weet het 'mea culpa' Het kwaad is reeds veel jaren geleden geschied ... Het bestand waar het van toepassing is, durf ik niet onder jullie ogen te brengen ... dat is geen bestand maar een gedrocht tot mijn grote schaamte Maar ik zal proberen jouw tips om te zetten naar het voorbeeldbestandje. Alleszins moet ik (gelukkig geen rekening houden met schrikkeljaren en is voor de eerste jaren (gelukkig maar) de vervaldatum op 5 jaar bepaald. Maar gun me wat tijd ... ik heb nog zo veel te doen ... Danny

Zoals steeds heb je weer het bij het rechte eind. Inderdaad dient men rekening te houden met de mogelijkheden die in de toekomst kunnen opduiken. Het probleem momenteel was dat ik dringend dergelijke aanpassing wou om verder te kunnen. Ik heb met schade en schande geleerd dat je inderdaad toekomstgericht dient te denken. Al te vaak zijn zaken die vandaag vanzelfsprekend zijn van de een op de andere dag gewijzigd en wordt er van je verwacht dat je ook zo flexibel bent. Kortweg, veel woorden om te zeggen, ik begijp wat je bedoelt. Weerom komen we in jouw behangpapierfase terecht, d.w.z. op voorhand plannen en uittekenen ... Geloof me ik ben het roerend met je eens en als ik al eens raad durf geven aan iemand anders, begin ik altijd met dat aan te geven. Spijtig genoeg zondig ik meestal als eerste om toch vlug iets in mekaar te steken, dankzij FM is dat meestal mogelijk, een groot voordeel maar misschien eveneens een nadeel (a.u.b. niet verder vertellen, ik zou niet willen dat men hieraan iets wijzigt). Je dient te begrijpen dat de voorbeelden die ik gaf slechts een klein onderdeel van een groot en complex geheel vormden en ik was al blij met m'n eerste (niet zo'n goede) oplossing maar de tweede was beter, hoewel arbeidsintensiever want dit betekende een hele aanpassing aan heel wat velden in de actieve database. Mocht ik dat indertijd allemaal voorzien hebben zou dat inderdaad nu heel wat makkelijker zijn, maar helaas ik dien meestal uit te voeren, voor het denkwerk hebben wij hier beter betaalde specialisten. Het desbetreffende bestand is één van m'n toekomstgerichte objectieven om het helemaal van niets terug op te bouwen, maar ondertussen moet ik wel verder kunnen met hetgeen wat ik nu heb. Vanzelfsprekend kijk ik uit naar al je raad, advies en tips. Ik begrijp ze soms niet helemaal maar ik doe op z'n minst ene poging om het te doorgronden Met mijn welgemeende dank en respect, Danny

Even vlug voor de TV een proefbestandje gemaakt. Ik denk dat dit ongeveer moet zijn wat jij wilt zeggen Jean? Vergeef me mijn titel, maar het klonk zo mooi Danny Date Testing.fp7

Jean, Dit is nog een oude db en daarom zeker nog niet volgens de regels der (FM) kunst. Bijgevolg staat alles in 1 tabel. Danny

Een mens zou er woest van worden ... een ganse dag het hoofd breken, vervolgens zoeken naar een oplossing op het forum ... niets vinden en daarom uiteindelijk een berichtje plaatsen hier op het forum, ten einde raad! Vervolgens nog eens naar je probleem kijken en Eureka ... opgelost! Een script uitvoeren met een loop maar dan niet met een Setfield stap maar wel een Copy en Paste stap. Concreet maakte ik gebruik van SetField VD = VVD waardoor ik algauw in een cirkel terecht kwam, rekening houdend met het feit dat VVD een calculatieveld is. Wat heb ik dan gedaan wel heel simpel, gewoon terug een loop waarbij voor elk record eerst de (oude) waarde uit VVD gecopieerd wordt en met de volgende scriptstap wordt deze geplakt in VD. Hierna past FM het (calculatie)veld VVD terug aan op basis van de waarde die zopas in VD geplakt werd. Met mijn excuses voor mijn probleem dat er in feite dus geen was Danny

De stelling: Afleveringsdatum - AD: vaste datum, kan en mag niet meer gewijzigd worden Verlengingdatum - VD: gebaseerd op de afleveringsdatum + (365*5+1) VolgendeVerlengingDatum - VVD: indien de VerlengingDatum leeg is is dit de Afleveringsdatum + (365*5+1) anders is dit de Verlengingsdatum + (365*5+1) Case(IsEmpty(VD); AD + (365*5 + 1); VD + (365*5 + 1)) Dit gaat goed totdat men 5 jaar verder is ... vervolgens komt men in een cirkel terecht en zijn de verkregen resultaten niet langer bruikbaar. Wat ik ook bedenk, ik kom er niet uit ... manuele aanpassingen zijn niet mogelijk vanwege het aantal te behandelen records, de data dienen dus berekend te worden en het liefst zonder gebruik te maken van globale velden of variabelen. Wie weet er raad a.u.b. ??? Danny

Wel dit vind ik nu een uitstekend idee! Danny

Ik kan geen Frans, maar volgens mij heeft het met kritiek oid te maken Vrij vertaald, 'De wanhoop is een superieure vorm van kritiek' MVG, Danny