Jump to content
  • 0

oneindige lus in FM10 met triggers


ovvk

Question

Hallo allen,

Hoewel ik nog steeds experimenteel bezig ben met FM heb ik versie 10 in probeer versie.

Ik heb echter een raar probleem met triggers die in FM10 te gebruiken zijn.

Wat gebeurt er:

 

Ik roep een layout aan die een load event trigger actief heeft. Of te wel als deze geladen wordt dan start ik een scriptje

die de velden leeg maakt zodat ik daarna via een knopske een zoekactie kan doen.

Het werkt perfect, totdat ik in het script welke dus aangeroepen wordt door de loadtrigger een nieuw window wil hebben.

Dan komt FM10 in een oneindige lus terecht die dus alleen maar kan stoppen door een forceerstop te geven.

Overigens werk ik met OS X 10.5.6 op de apple.

Iemand enig idee waar dit vandaan zou kunnen komen, wat doe ik verkeerd?

Kan dit een bug zijn??

 

mvgr

 

Cor

Link to comment

15 answers to this question

Recommended Posts

  • 0

Dat hebben ze dus vergeten bij Filemaker, hadden beter Peter wat raad gevraagd :D , de Doscript kan je namelijk aan en uit zetten.Probleem zit hem idd in het feit dat je een nieuw venster oproept waarin ook getriggerd wordt.Misschien kan je spelen met find modus ? Triggers zijn namelijk apart instelbaar voor find & browse.

Link to comment
  • 0

Ik zou niet weten wat ze dan precies vergeten zouden zijn. Het werken met script triggers, vraagt dat wij developers nu een beetje anders gaan denken. Je kan je probleem omzeilen door bv. een globale variabel of een globaal veld als "switch" te gebruiken, die je aanzet zolang je zoekactie loopt. In je OnLayoutLoad gekoppeld script check je of die switch aan staat. Bijvoorbeeld. Je bent ook helemaal niet verplcht op script triggers te gebruiken natuurlijk :D Ik zou je in je voorbeeld het mogelijk zelfs afraden, je zoekactie wordt hoogt waarschijnlijk toch "getriggerd" door een gebruikers actie, zoals het klikken op een zoek knop of zo ?!

Link to comment
  • 0
Ik zou niet weten wat ze dan precies vergeten zouden zijn

Ik maak nogal gebruik van triggers en vindt het gewoon handig dat je deze kan uit en aanschakelen, een functie set(trigger) zou dus handig zijn maar kan idd vervangen worden door een $$var. Dit netjes in een Custom gieten, wat peper erbij en klaar om aan te vallen.We kunnen het allemaal zelf wel voorzien maar in sommige gevallen is het gewoon handiger indien native, denk maar onlayoutload in combinatie met privileges enz... ik zeur echter niet verder , na jaren begging is het er eindelijk !

Link to comment
  • 0

OK, ik begrijp beter wat je wil. Hou er wel rekening mee, dat de nieuwe script triggers niet werken op de manier waarop de pre-FM10 event plugins - zoals DoScript - werken. Die laatste zijn gekoppeld aan het veld zelf, meestal via auto-enter. De FM10 script triggers zijn gekoppeld aan interface elementen - layouts, velden, objecten. Het verschil is dat een zelfde veld op de ene layout wel en op de andere layout geen script trigger kan bevatten. De pre 10 event plugins koppelden de triggers aan het veld zelf, onafhankelijk van de layout dus. Dat heeft dus nog steeds z'n waarde denk ik.

 

Als je triggers wil in- of uitschakelen in het 10 tijdperk, dan zou je tenminste moeten verwijzen naar:


  • - layout
    - object
    - trigger

 

Ik weet niet of dit nog beheerbaar is...

Link to comment
  • 0

Een tip om lussen tegen te gaan:

Geef aan elke trigger de parameter "Get( ScriptName )" ( euh... Get ( HuidigeScripNaam ) of zoiets? ) mee.

 

Je triggerscript kijkt na of de script parameter leeg is. Als dat niet zo is, dan is het script getriggerd terwijl er... een script bezig was met uit te voeren!

 

Voorbeeldje in bijlage.

 

DoScript werkt inderdaad helemaal anders, en is inderdaad helemaal nog niet afgeschreven. Integendeel. Script triggering wordt eigenlijk nu pas een beetje ontdekt door het gros van de FileMaker developers. Er zijn inderdaad een pak "voetangels en schietgeweren", en ja, wie geen debugger draait, is ferm gezien. Ook met de DoScript heb ik al menigmaal op mijn gezicht gegaan... :wink:

 

Wat ik meestal doe met DoScript, is de Data Viewer en de Debugger tegelijkertijd openen en in de DataViewer mijn formule proberen.

Werkt alles een beetje naar wens, kopieer ik de formule en plak ze dan - bijna altijd als "auto-enter-calculation" in mijn velddefinities.

 

Op de FMSummit in maart dit jaar ( het wordt weer Antwerpen! ) geef ik een sessie over script triggers in FileMaker Pro 10. Zo'n sessie voorbereiden, daar komt heel wat werk aan te pas, ik ben dus al uren aan het experimenteren geweest met die script triggers, om toch een beetje te weten waar ik "straks" over zal gaan praten. Die sessie zal ten andere ook gebeuren met een FIleMaker Pro 10 Advanced, zonder script debuggger kan je heel moeilijk tonen wat er zo allemaal gebeurd.

Loop vermijden.fp7

Link to comment
  • 0

Ron, dat vind ik een zeer interessante reaktie.

Destemeer (wow) omdat ik "Get (WindowVisible)" intik in de FileMaker Pro Help en daar gewezen wordt op artikels in de FileMaker knowledgebase.

OK, nog niet zo raar, maar als ik dan ga zoeken op "Get (WindowVisible)" in de FileMaker knowledgebase ( http://www.filemaker.com/kb ), dan vind ik 1 "recommended article" ... "Script Triggers and FIleMaker Pro 10". Waar ik dan vervolgens NIKS in vind over Get(WindowVisible).

 

Per ongeluk kom ik er echter achter dat je eender wat kan intikken. Tik bijvoorbeeld "Ron" in, en je begrijpt direct wat ik bedoel... :mrgreen:

Iemand van sales heeft blijkbaar zijn weg naar de knowledgebase gevonden.

 

Even serieus, het feit dat een script in een verborgen of achtergrond venster draait - en dat kan in de nieuwere versies - heeft misschien wel invloed op de script triggers. Heb je daar ervaringen mee, Ronald?

Link to comment
  • 0

Volgens de help geeft Get(WindowVisible) 1 terug wanneer het huidige venster zichtbaar is, en 0 waneer het niet zichtbaar is. Het huidige venster is niet per se het actieve venster, aangezien je nu een script in een niet-actief venster kan laten lopen.

 

Onzichtbaar (waarde 0) zijn vensters die expliciet verborgen zijn via 'Verberg Venster' (Hide window), of die impliciet geopend zijn via een verwijzing naar een externe FileMaker databron (alla dat is toch wat ik vermoed).

 

Ik vermoed dat Get(WindowName) een interessanter functie is in het kader van Script Triggers en vensters?!

Link to comment
  • 0

was een beetje spielerei met de triggers....

In de context van gestelde probleem zou je een file hidden kunnen openen.Door de visible te evalueren gebeurt er niets (fm triggert ook hidden windows indien aangespoken via open hidden !), leuke is echter als je de hidden naar voren haalt gebeurt er niets meer daar de trigger al werd uitgevoerd.Kan dus in een rare case handig zijn als een layout on open niets mag doen en nadien wel bvb.

Link to comment
  • 0

@all,

 

Bedankt voor alle goede tips!

Ik heb het inmiddels opgelost door een globale variabele (switch) te setten in het opstartscript

zodat deze switch(es) overal beschikbaar zijn.

Hiermee voorkom ik niet de infinitive loop maar heb ik wel invloed op het wel of niet uitvoeren van het script.

Ik vermijd nu de events bij het openen en sluiten van layouts.

 

groet

 

Cor

Link to comment

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.

×
×
  • Create New...