Is in een layout zijn noodzakelijk voor het uitvoeren van script steps in die layout?

[Vitruvius]

Vast een domme vraag (ik ben leerkracht geweest, domme vragen bestaan wel degelijk) voor een opgeleide FM Database-bouwer:

Simpele situatie om het duidelijk te maken: tabel A met layout A, tabel B met layout B.

Ik start een script via een knop in layout A. Dat script gaat dingen doen in tabel A, op een bepaald moment moet dat script ook dingen doen in tabel B, moet ik in mijn script dan ook naar layout B gaan of kan het script gewoon velden bewerken in tabel B, ook al zit ik layout A?

Nu doe ik dat, omdat ik de menselijke gedachtegang volg, maar recentelijk ben ik door een ander iets (via een tabblad verbergen van een berekende grafiek) mij gaan afvragen of dat überhaupt wel moet.

Dat zou sommige van mijn omvangrijke scripts (waar nu de pop-up verschijnt: dit kan even duren ...) aanzienlijk sneller kunnen laten gaan aangezien ik dan geen layout meer moet laten zien waar data in staat, waaronder berekende velden.

Kan ik, even verder denken, in dat script naar een blanco layout gaan (layout C, tabel C) waar ik slechts één veld heb (in tabel C) waarin ik een soort van status van het script doe. Zoals Stap A OK, Stap B OK, Stap C bezig.

[Banach]

Dit is in principe mogelijk, toch is overschakelen naar de betreffende layout aan te bevelen. Dit is vanwege de 'context'.

Deze 'context' is, zeg maar, de TOC (Table OCcurrence) waar je op dat moment in werkt. Dit is de TOC die is gekoppeld aan de layout waar je op staat. Vanuit deze context worden velden die gekoppeld zijn via relaties benaderd. Zit je in de verkeerde context dan gaat dit fout doordat beide TOC's helemaal niet of op andere wijze gekoppeld zijn dan je op dat moment nodig hebt. Dit kan nogal eens een instinker zijn omdat je dit makkelijk over het hoofd ziet en in complexere oplossingen soms wel lijkt te werken en dan weer niet. Ook kan het leiden tot onduidelijk gedrag van je oplossing (b.v. soms wel en soms niet sorteren).

Om dit soort problematiek te voorkomen is het advies om goed op je context te letten. Een hulpmiddel daarbij kan de anker-boei methode voor het maken van de relaties zijn. Wanneer je hierin doorschiet maak je voor iedere layout een eigen TOC. Een aardig artikel juist tegen het gebruik van deze methode is van de hand van Kevin Frank:

https://filemakerhacks.com/2016/07/28/life-after-anchorbuoy/

In jouw situatie kun je ook naar een layout (met de juiste context) gaan waar die berekende velden niet op staan. Ik betwijfel echter of dit enige snelheidswinst oplevert voor het draaien van het script omdat het venster niet wordt bijgewerkt in het script maar pas na een Refresh of na afloop. Wanneer je na de laatste actie in het script weer terugschakelt naar de originele layout dan komt de layout met die berekende velden dus nimmer in beeld. Zolang je dan geen gebruik maakt van die velden in je script wordt daar geen tijd verloren.

Kortom, dit is zeker geen domme vraag.

Edited November 18, 2018 by Banach

[Vitruvius]

Er is voor sommige scripts wel degelijk een enorm snelheidsverschil of een veld al dan niet zichtbaar is.

In layout A staat bijvoorbeeld een grafiek die data haalt uit velden in tabel A.

Waneer ik vóór het uitvoeren van een script deze grafiek eerst verberg (grafiek staat op en tabblad, door naar een leeg tabblad te gaan verberg je de grafiek) gaat mijn script letterlijk 1000 keer sneller omdat die grafiek niet continu moet worden aangemaakt wanneer ik doorheen de records van tabel A ga met mijn script.

Verder zijn er bepaalde (berekende)velden die nodig zijn voor bepaalde scripts, maar in geen enkele layout zichtbaar zijn, en dat werkt perfect.

Vandaar mijn vraag of het Überhaupt nodig is om naar een bepaalde layout te gaan.

Als in het script staat 'doe dit met tabelA::veld1' en daarna 'dat met tabelB::veld2' dan kan ik perfect in layout C staan terwijl dat script draait.

 

Lijkt me ...

Niet?

[Banach]

In dat geval zou ik zeggen: Ga ermee aan de slag! Je weet nu dat je dan scripts hebt die 1000X sneller zijn en je weet ook van de context. Misschien heb je ook wat aan de script stap Freeze Window https://fmhelp.filemaker.com/help/17/fmp/en/#page/FMP_Help%2Ffreeze-window.html%23

Ik lees graag je bevindingen.

 

[andries]

ik heb voor elke context ook een layout voorzien die ik "XXX_blank" heet (waarbij XXX de context naam is). op die layouts mag nooit iets staan. Als ik dan records wil bewerken in een script ga ik altijd naar zo een layout, zodat ik zeker ben dat ik geen onnodige rekenkracht in berekeningen of grafieken ga steken die ik toch niet nodig heb.

[Vitruvius]

Ik ga inderdaad eens experimenteren en laat het jullie weten.

[Vitruvius]

Die freeze window is inderdaad ook mooi, maar bij sommige scripts denkt de gebruiker dan dat de databank hangt. Ik voorzien daarom altijd een vorm van feedback zodat de gebruiker weet dat er iets aan het gebeuren is.

Het is wel een goede scriptstap voor scripts die maximaal een paar seconden tijd vragen om doorheen te gaan

[Vitruvius]

Vanwege problemen met TOC (post van Banach) is het inderdaad aan te raden om van elke tabel ook een blanco layout te hebben (post Andries), zo zit je in de juiste tabel-layout relatie zonder dat je data ziet. Zoals Banach al opmerkte gaat je databank anders soms "raar" doen.

[hans erik]

Ik heb voor elke tabel ook altijd een aparte Table Occurrence met een vaste naam en een standaard layout met diezelfde naam. Bijvoorbeeld een tabel ‘personen’ heeft dan altijd een TO ‘a_personen’. Die is nergens aan gekoppeld, maar wordt bijv. gebruikt in table view als ‘inspector’ en in executeSQL. Vooral dat laatste is belangrijk: je kunt naar hartelust TO’s toevoegen, verwijderen of renamen, de SQL blijft altijd werken en is goed leesbaar omdat je nooit escape-karakters of extra FM functies hoeft te gebruiken. NB velden hernoemen doe ik nooit.