Jump to content

hans erik

Leden
  • Posts

    1086
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ik ben het helemaal met je eens, Peter. En ik vrees dat Claris ook zwaar aan het 'not-invented-here' syndroom lijdt. In plaats van hun tijd te steken in een 'me too' product als ClarisConnect zouden ze er goed aan doen de lijst met suggesties eens af te stoffen.
  2. Klant van mij gebruikt de webviewer onder Windows onder andere voor het displayen van een directory. Dat ging tot en met FM19.2 altijd via Explorer, maar nu maakt FM19.3 gebruik van Edge. En het probleem is, dat Edge de directory listings anders weergeeft: een grote vette kop bijvoorbeeld. Mooi, maar onhandig. Ik denk dat Edge voor dit soort lijstjes een ingebouwde of default css gebruikt. Weet iemand waar die css zich bevindt in Windows10 en zo ja, is dat aan te passen of werkt het op een andere manier?
  3. Ik was niet helemaal nauwkeurig: het versienummer in de naam heeft alleen zin als je de nieuwe versie en de oude versie naast elkaar gebruikt, of in verschillende toepassingen, of wanneer je handmatig de functie in een toepassing bijwerkt (zowel de inhoud als de naam). Kopieer je een nieuwe versie naar je bestand, dan is het voor Filemaker een nieuwe CF. Je zou dan alle berekeningen na moeten lopen om de CF om te zetten en dat wil je niet. FileMaker kijkt natuurlijk naar het interne ID van de CF, niet naar de naam. Als je via de naam vd CF ook de versie wilt weergeven moet je EN de naam EN de programmacode bijwerken. Heb nog niet gekeken of dat met de XML conversie automatisch kan... Javascript: ja dat zou inderdaad kunnen met de nieuwe JS functies. Javascript wordt natuurlijk door de web engine uitgevoerd, niet door FM zelf. Vraag me af hoe dat dan in serverside scripts zou moeten werken?
  4. Ik denk overigens dat je een CF altijd 'downward compatible' moet maken: de nieuwe versie voegt functionaliteit toe. En als er bijv parameters toegevoegd worden moet je er dus rekening mee houden dat die leeg kunnen zijn. Voor het resultaat is het simpel: als dat een ander formaat heeft, moet je gewoon een andere functie maken. Een eenvoudige optie is verder om de versie van de CF in de naam op te nemen, bij cf_datumformat_v12, en nieuwe versies krijgen dan altijd een andere naam. Dan zie je aan de naam welke versie je gebruikt... In de Meetup gisteren (28/6) werd een constructie gesuggereerd waarbij een CF in een FileMaker veld wordt opgeslagen en wordt uitgevoerd m.b.v. een evaluate() functie. Dat zou ik toch afraden, om meerdere redenen: 1.Performance. De evaluate functie is notoir traag. Bij een kleine CF maakt het niet uit, maar het kan flink uit de hand lopen; 2.Security. De evaluate functie zet de deur naar 'code insertion' op een kier. Zodra iemand zich toegang kan verschaffen tot de inhoud van het veld zijn de rapen gaar. Dat is ook een probleem met executeSQL, iets wat Claris opgelost heeft met de parameter constructie. 3.Welk probleem los je op? Want je blijft meerdere versies (onder)houden.
  5. Nou, het zou natuurlijk al helpen als je bij het maken van een nieuw script of layout gewoon met een popup-menu kunt kiezen in welke map het ondergebracht moet worden. Met name omdat Filemaker je op veel plekken nog steeds in een modaliteit drukt en dat ook nog eens vrij knullig doet. (overigens: die 'mappen' zijn natuurlijk helemaal geen mappen. Het zijn een soort constructies die op mappen lijken, maar je kunt ze niet sorteren of wat dan ook. Maar dat terzijde) Voorbeeld: je maakt een knop aan op een layout en je besluit dat je geen bestaand script kunt gebruiken maar een nieuw script moet aanmaken. Je kiest dan een mapje waar het script moet komen en je vult de naam vh script in. Klik je op Cancel, dan is er toch al een nieuw script, laat staan dat je de map nog kunt wijzigen. Ook zou ik wel een script als template willen gebruiken... Het kan allemaal wel, maar altijd met een omweg. En een 'Date Modified' of een 'label' bij een script (ook als kolom a.u.b.) zou natuurlijk niet verkeerd zijn.
  6. Ik vind de huidige manier waarop je custom functies kunt beheren een beetje te simplistisch. Maar dat geldt eigenlijk voor een heleboel zaken zoals layouts, scripts en keuzelijsten. Een FileMaker applicatie groeit en groeit en groeit. Op een gegeven moment heb je 300 layouts, 1200 scripts en 186 keuzelijsten en het voortschrijdend inzicht maakt dat je eigenlijk de boel op iets andere manier wilt indelen. Dan heb je dus een probleem, want FileMaker heeft wel de tools om duizenden scripts aan te maken, maar niet de tools om die ook te managen. De display lijsten zijn al 20 jaar niet noemenswaardig aangepast. Enerzijds is dat geruststellend omdat continuïteit een groot goed is, anderzijds begint het al een jaar of 15 een beetje te knellen. Dus komen er allerlei tools op de markt om de lacune op te vullen, maar het blijft behelpen en Claris had dit al geleden moeten oplossen.
  7. De Meetup op 17 mei was een soort 'open discussie' waar verschillende onderwerpen langs kwamen. Paar interessante punten: - hoe veilig is FileMaker (server)? Kun je nare dingen doen door bijvoorbeeld via WebDirect en/of Javascript in de webviewer code te inserten? Heeft FileMaker vooral 'Security by Obscurity' of biedt het beveiligingsmodel (username/ww, plus Encryption At Rest voor de backups) afdoende beveiliging - vooropgesteld dat je het model serieus implementeert? - add-ons: de neiging bestaat om het over 'plugins' te hebben, maar dat is echt iets anders... Enfin, er zijn nog niet heel veel add-ons en misschien is het goed om met name de Javascript-based add-ons te vergelijken met het aanbod van andere oplossingen. Jos Hofman noemde terecht Carafe (Soliant Consulting). - is er voldoende instroom van nieuwe, jongere ontwikkelaars en zo nee, wat kunnen we daaraan doen? Om weer eens oude koeien uit de sloot te halen: Claris heeft om mij nog steeds onduidelijke redenen de Runtime verwijderd zonder er iets anders voor in de plaats te bieden. In de FileMaker Community krijgt een voorstel om juist het tegenovergestelde te doen heel veel bijval! Kortgezegd: maak van de Runtime juist een 'unique selling point' en trek er nieuwe klanten mee aan. De meeste FileMaker ontwikkelaars komen voort uit gebruikers. Hoe meer nieuwe gebruikers, des te meer ontwikkelaars! In een volgende meetUp hopen we meer aandacht aan deze punten te besteden. Stay tuned.
  8. Ik denk dat Gerard wel gelijk heeft. Wat nog lastig kan zijn is dat je verschillende versies hebt van een CF: welke wordt gebruikt in welk bestand? FMPerception heeft een leuke procedure hiervoor.
  9. Tsja... allebei dan! Je maakt een app aan met één van de standaard apps, en dan zou je op een heel gemakkelijke manier via een add-on een andere module moeten kunnen toevoegen.
  10. Je mag hopen (en verwachten) dat Claris dit met add-ons oplost, zodat die malle ‘standaard apps’ voortaan tot het verleden behoren. Je maakt dan een default app aan, vervolgens voeg je de extra componenten toe als add-ons.
  11. Probleem van een dergelijke oplossing is, dat je een constructie overhoudt met meerdere fysieke bestanden, elk met één of meer tabellen. Zonder hier gelijk een basiscursus Filemaker en datamodellering te willen geven: dat is niet een optimale oplossing. ik zou het volgende pad volgen: - begin met een standaard app; - kijk goed hoe die in elkaar zit, hoe layouts gekoppeld zijn aan tabellen, en tabellen onderling; - koppel zelf een tweede app eraan en kijk of je snapt hoe die koppeling werkt. Is dat allemaal voor elkaar, probeer dan de tabellen en scripts van het tweede bestand naar je begin app te kopiëren, en werk van daaruit verder, mrt 1 bestand dus.
  12. Dan zou ik toch eerder voor een MacMini kiezen. Je hebt tegenwoordig een weelde aan 4K en 5K monitoren voor weinig geld. Het grappige is dat mijn beeldscherm (een LG) officieel tot ‘maar’ 3840 x 2560 gaat, maar in werkelijkheid tot meer dan 6000 pixels breed gaat. Dan moet je er wel een loupe bij pakken. Ik hou het meestal bij 2560 breed, de grafische kaart levert dan een gestoken scherp beeld.
  13. Als je de Calendar addon van FM19 gebruikt, zul je merken dat de maand/weekdag en tijdweergave ingesteld wordt volgens de taal van FileMaker. Niet handig als je gewend bent om Engelstalige FileMaker te gebruiken maar wel een Nederlandse kalender wilt! tip van de meester: de addon haalt de taalinstelling op met Get ( ApplicationLanguage). Dat kun je dus aanpassen, nl. in de berekening van de WebViewer. Vervang de Get (AppliocationLanguge) door "Dutch" (of iets anders) en Voila. Ik denk dat iets soortgelijks ook geldt voor de andere add-ons, zoals de KanBan.
  14. Ehm, ik heb nog even wat gechecked. Ik heb een layout A met een gerelateerd record (niet in een Portal) en de cursor staat in een veld X, heb net wat tekst ingetypt. Het veld is dus nog geselecteerd, het record dus gelocked en de tekst nog niet gecommit. In een ander venster run ik een script (in een andere tabel) dat mbv een executeSQL de inhoud van veld X selecteert en displayt. De oude, opgeslagen versie verschijnt. Logisch. Als ik in layout A buiten het veld klik (wat 'go to field()' ook doet) en ik run in het andere venster de SQL, krijg ik de nieuwe versie. M.a.w. Filemaker voert wel degelijk een commit uit, anders kan ik nooit de nieuwe versie krijgen.
  15. @DonamdWerk je met Windows of MacOS? Het lettertype dat Filemaker gebruikt is onder Windows volgens mij Arial 9. Zo te zien is het een probleem van een niet-zo-fantastische anti-aliasing, wat o.a. gebruikt wordt als de ingestelde schermresolutie niet overeenkomt met (een veelvoud van) de 'werkelijke' resolutie. Dus als jouw scherm bijv. 2560x1440 ondersteunt en je hebt je beeldscherm (via je Control Panel) ingesteld op 1280x720, zou het goed scherp moeten zijn, maar als je je beeldscherm instelt op 1920x1080 kan het zijn dat de grafische kaart er een bende van maakt.
×
×
  • Create New...