Banach

Web. Tenminste volgens Claris.

- Uitgefaseerd slaat op het feit dat al enige tijd geleden is aangekondigd dat het kunnen maken van runtimes zal verdwijnen. - FM10 is nog een zogenaamde MDI applicatie; één hoofdvenster waarin de andere vensters geopend worden. Dit is nu anders zoals je al opgemerkt hebt. Het hoofdvenster is verdwenen, ieder venster lijkt een eigen applicatie (SDI) te zijn. Daarbij is het inderdaad zo dat bij het sluiten van het laatste venster ook FileMaker als geheel afsluit. Er is echter een scripttrigger welke geactiveerd wordt wanneer het laatste venster gesloten wordt. Je kunt daar je eigen script aan hangen. Bijvoorbeeld een dialoog met 'Weet U het echt, echt, echt heel zeker dat U de applicatie wilt afsluiten?'😊 - Bij online aankoop krijg je een download link voor zowel de Mac als de Windowsversie.

Met de aangekochte versie van FM18 kun je nog steeds runtimes maken.

Ik denk niet dat het aantal bits hiervoor wat uitmaakt. Dat is iets dat de compiler verder wel regelt. Ik kan mij dan ook voorstellen dat heel wat programmaregels al heel lang onveranderd zijn gebleven

@HE Wat een openbaring! Inderdaad werkt zo'n ADB toetsenbord nog perfect samen met een iMate. Dat had ik niet verwacht. Zojuist naar aanleiding van jouw post even geprobeerd op een iMac 2017.

Ik zie toch echt dat je 'eigen volgorde' gebruikt bij het koppelen van bron- en doelvelden. Dat moet dus namen vergelijken ('matching names') zijn. Wanneer veldnamen in bron en doel niet overeenkomen gebruik je de tussentabel waarin je wél alle veldnamen precies gelijk hebt aan die in Excel.

https://fmhelp.filemaker.com/help/17/fmp/nl/#page/FMP_Help%2Fshow-hide-menubar.html%23

En wat doet mijn voorbeeldje bij jou?

Ik ben hier eens wat dieper ingedoken omdat ik vind dat wanneer je importeert op matching field names je geen tussentabel nodig zou moeten hebben. Ook is het correct vanuit de tussentabel importeren in de hoofdtabel nog niet zo eenvoudig! Uiteindelijk denk ik dat we hier op een onvolkomenheid in FM zijn gestoten welke in ieder geval in FM18 bestaat en wellicht al eerder niet naar verwachting werkte. Ik kreeg het uiteindelijk wel goed zoals je in bijgevoegde bestandjes kunt nagaan, maar waarom het ineens wél goed werkte na verschillende pogingingen waarin het niet goed ging, weet ik eerlijk gezegd niet precies. In het import.fmp12 bestand zit een scriptje dat door de knoppen "import data1" en "import data2" wordt aangeroepen. Enige verschil is de scriptparameter data1 of data2. Hiermee wordt even voor dit testje het Data1.xlsx of het Data2.xlsx Excel bestand geïmporteerd. Beide Excel bestanden hebben dezelfde kolommen echter in een verschillende volgorde. Toch importeert FM de gewenste velden (4 van de 9) in de juiste velden. Maar dit ging niet zonder slag of stoot. (a) Wanneer de importeerstap zonder dialoog wordt uitgevoerd en er geen file specificatie in is opgenomen worden de juiste velden gematched. (b) Ook wanneer er wel een dialoog moet worden uitgevoerd en er tevens een file specificatie in de scriptstap staat gaat het goed. (c) Echter wanneer je geen dialoogvenster maar wel een file specificatie geeft krijg je een foutmelding: Er zijn geen velden welke geïmporteerd kunnen worden (o.i.d.) Ik denk dat ik het tot mijn stomme verbazing goed gekregen heb door eerst (a) of (b) uit te laten voeren en daarna het script op (c) aan te passen. Raar, maar waar. Wellicht heeft een van de andere forumleden een verklaring van wat hier fout gaat. import.zip

Gaat het dan om hetzelfde Excel bestand? Of is dit een ander Excel bestand? In de eerste situatie is er iets mis met je FM want dit is niet het normale gedrag van FM. In de tweede situatie (hier ging ik telkens van uit) is het na importeren in de tussentabel nodig om de benodigde velden te matchen met de labels zoals die in het Excelbestand staan. De veldnamen in de tussentabel maken daarbij niet uit. Je kijkt naar het eerste geïmporteerde record. Dit bevat de kolomnamen zoals deze in Excel staan, mits je dat bij het importeren hebt aangegeven. Vervolgens kunnen we gaan kijken naar een procedure om de betreffende kolommen in je definitieve tabel te importeren.

Daarmee zal je een schoon bestand hebben gemaakt. Voor 30 losse bestanden is dat naar verwachting wel heel veel werk. Waarom probeer je niet eerst een recovery mbv FM18? Dan heb je gelijk de nieuwste versie en ondertussen zijn je bestanden ook nog eens naar het laatste bestandsformaat geconverteerd. Ik denk dat je dit al kunt testen met de trialversie van FM18. Let wel op dat je dat doet op een kopie van je bestanden want je kunt na conversie niet meer terug naar FM11.

Laatste volgorde is prima. Dit houdt in dat er precies zo als de keer ervoor wordt geimporteerd. Wanneer dan niet de zelfde kolommen in de zelfde velden terecht komen kan dit alleen betekenen dat het Excel document niet dezelfde kolommen heeft als de vorige keer. Voor dit soort inconsequente bestanden denk ik dat je dit alleen kunt oplossen door in een tussentabel alle kolommen uit Excel te importeren en dan de juiste kolommen welke je in FM wilt hebben selecteren aan de hand van de kolomlabels.

En wat gebeurt er wanneer je alle kolommen importeert waarbij de niet gebruikte kolommen in dummy velden komen, desnoods met gebruikmaking van een tussentabel?

Helemaal geweldig! Bedankt voor deze oplossing.

Het is vaak eenvoudiger om twee verschillende layouts te maken; de kijk-layout waarop alle velden 'dicht' staan (niet gewijzigd kunnen worden) en een wijzig-layout waarop de velden die gewijzigd mogen worden 'open' zijn. Een andere oplossing is dat je op ieder veld een trigger zet (on ObjectEnter). Het getriggerde script checkt dan aan de hand van door jou bepaalde criteria of het veld gewijzigd mag worden. Mag dat niet dan geef je direct een commit. Zie voorbeeldje. lock.fmp12