Jump to content
  • 0
Sign in to follow this  
Vitruvius

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

Question

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.

Share this post


Link to post

8 answers to this question

Recommended Posts

  • 0

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 by Banach

Share this post


Link to post
  • 0

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?

Share this post


Link to post
  • 0

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.

Share this post


Link to post
  • 0

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

Share this post


Link to post
  • 0

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.

Share this post


Link to post
  • 0

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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  
×
×
  • Create New...