ovvk Geplaatst: 17 januari 2009 Delen Geplaatst: 17 januari 2009 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 Quote Link naar reactie
0 rmw Geplaatst: 18 januari 2009 Delen Geplaatst: 18 januari 2009 Nieuw venster levert je ook weer een 'load layout' trigger op.... Dus daar ga je Mijn ervaring tot nu is dat je in het ontwerp van scripts op basis van events niet zonder de scriptdebugger kunt.... rmw Quote Link naar reactie
0 ovvk Geplaatst: 18 januari 2009 Auteur Delen Geplaatst: 18 januari 2009 rmw bedankt, het verplaatsen van de plaats binnen het script haalde niets uit, het wachten is op FM adv (Nederlands) daar zou iets van scriptdebugging in moeten zitten. of binnen het ontwerp kijken of ik een ander event kan gebruiken. mvgr Cor Quote Link naar reactie
0 Ron9_15 Geplaatst: 18 januari 2009 Delen Geplaatst: 18 januari 2009 Dat hebben ze dus vergeten bij Filemaker, hadden beter Peter wat raad gevraagd , 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. Quote Link naar reactie
0 Jeroen Aarts Geplaatst: 18 januari 2009 Delen Geplaatst: 18 januari 2009 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 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 ?! Quote Link naar reactie
0 Ron9_15 Geplaatst: 18 januari 2009 Delen Geplaatst: 18 januari 2009 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 ! Quote Link naar reactie
0 Jeroen Aarts Geplaatst: 19 januari 2009 Delen Geplaatst: 19 januari 2009 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... Quote Link naar reactie
0 Koen Van Hulle Geplaatst: 19 januari 2009 Delen Geplaatst: 19 januari 2009 Voor de Technet leden, je kan een mooie white paper over script triggers en hun gedrag downloaden op de FileMaker.com site. Koen Quote Link naar reactie
0 Peter Wagemans Geplaatst: 19 januari 2009 Delen Geplaatst: 19 januari 2009 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... 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 Quote Link naar reactie
0 ovvk Geplaatst: 19 januari 2009 Auteur Delen Geplaatst: 19 januari 2009 Allen bedankt voor de reacties! ga nog even experimenteren met de triggers, en tegen de tijd dat ik aandrang krijg om de MAc door het raam te gooien kan ik altijd nog de globale variabele methode gebruiken. Mvgr, Cor de Bruin Quote Link naar reactie
0 Ron9_15 Geplaatst: 19 januari 2009 Delen Geplaatst: 19 januari 2009 De Get(WindowVisible) is ook wel handig om na te gaan in welk venster je script loopt. Quote Link naar reactie
0 Peter Wagemans Geplaatst: 8 februari 2009 Delen Geplaatst: 8 februari 2009 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... 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? Quote Link naar reactie
0 Jeroen Aarts Geplaatst: 8 februari 2009 Delen Geplaatst: 8 februari 2009 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?! Quote Link naar reactie
0 Ron9_15 Geplaatst: 8 februari 2009 Delen Geplaatst: 8 februari 2009 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. Quote Link naar reactie
0 Peter Wagemans Geplaatst: 8 februari 2009 Delen Geplaatst: 8 februari 2009 Goed om te weten. OnLayoutLoad en zo triggeren dus, zefs al is je window hidden. Quote Link naar reactie
0 ovvk Geplaatst: 9 februari 2009 Auteur Delen Geplaatst: 9 februari 2009 @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 Quote Link naar reactie
Vraag
ovvk
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 naar reactie
15 antwoorden op deze vraag
Aanbevolen berichten
Doe mee aan dit gesprek
Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.