GetTriggerType or equivalent Get Function?

[James Gill]

I'm currently using Script Parameters to pass a parameter of TriggerType so that I can tell a particular Script to activate only on a particular Script Trigger.  Right now I have to manually enter the TriggerType parameter and I'm wondering if there is a Get Function that would allow me to do this as if I want to change when a script is called, I have to manually change the parameters across all of the fields.  I've looked through the docs and I can't find anything, but I just want to make sure that I haven't overlooked a Get Function that would do what I want.

[comment]

tell a particular Script to activate only on a particular Script Trigger.

 

Not sure what you mean by that.

[Wim Decorte]

Different events (trigger types?) are handled by attaching different scripts to the proper events.  Since you know exactly what event you are handling I'm a little lost as to why you would want to know the event's name/type?

 

The code to handle an OnExit for instance would typically be vastly different than an OnObjectKeystroke or OnSave, or OnCommit... 

 

It sounds like you maybe want use one script to handle all events and then want to know what event happened?  If you have that much same code that runs on each event then put that in a subscript and call it in the scripts that handle individual events.  There really is no point in trying to come up with one script that handles all events.

[James Gill]

Generally, I use parameters to group a specific layouts Script Triggers into a single script so that if something layout specific changes, I can easily make the changes.  The solution I'm working with has a ton of scripts, so I'll take space savings wherever I can get them.

I'll take the general tone of the responses as this being a silly idea.

[comment]

I'll take the general tone of the responses as this being a silly idea.

 

I am still not sure I understand what you're saying, but if I do, then yes. It looks like you're throwing all your needles into a haystack, then asking how to find them.

[Wim Decorte]

 The solution I'm working with has a ton of scripts, so I'll take space savings wherever I can get them.

 

Space saving would not be high on my list and certainly well after "code maintainability".   It sounds like your quest for space savings is hurting exactly that with lots of hard-coded references.  Optimizing should not cause more problems than it solves...

[James Gill]

Space saving would not be high on my list and certainly well after "code maintainability".   It sounds like your quest for space savings is hurting exactly that with lots of hard-coded references.  Optimizing should not cause more problems than it solves...

 

I'm not sure how creating 1 script to handle 9 event triggers (Layout ScriptTriggers in this case) is less maintainable that creating 9 individual scripts to do the same thing.  If you're referring to the hardcoded parameters, in which case you've discovered

the cause for me creating this thread

 

 

I am still not sure I understand what you're saying, but if I do, then yes. It looks like you're throwing all your needles into a haystack, then asking how to find them.

 

I'm not sure I follow so I'll give an example.  Say I have single layout that contains several complex dependancies that, depending on what Script Trigger calls them, must do different things.  From what I'm gathering, your best approach would be to create a single script for each trigger, named such that it would be obvious that each script is called from a particular Scrip Trigger type, and then branch your script from there.  

 

All I'm doing is creating a single script that receives variables passed as parameters from the Trigger Type that called it.  Yes I'm hardcoding a $TriggerType parameter, but in reality it's only hardcoded in the ScripTrigger.  If I need to change it, I know exactly where it's hardcoded.  Heck, if I really wanted to I could create a CF to handle that and then all I'd have to do is change the CF.  That being said, I feel that the benefits I gain from being able to see the logic behind how the layout functions and effects related to data vastly outweighs the "hardcodyness" of it, hence my asking if there was a function that did this.

[comment]

Let me start at the end: (if it wasn't clear by now) there is no function to tell what the triggering event was. There are functions for some specific sub-events, e.g. Get(TriggerKeystroke). I guess that if Get(TriggerKeystroke) returns something, then you would know that the script was triggered either OnObjectKeystroke or OnLayoutKeystroke. Doesn't seem like this would accomplish what you're looking for.

 

The other thing may not be that important. For myself, it's hard to see why you would want to pack all those scripts into a single wrapper, when each needs to do completely different things. I am afraid I didn't understand your example. Technically, calling a script "Specific Script A" is the same as calling a script "General Script" with a parameter "A" (which then the General Script will use to either call sub-script "A" or just do the thing itself based on If statements). Practically, it's an unnecessary complication. You have already branched at the trigger setup; there's no point in all flights going through Atlanta.

[Fitch]

James, I have been down that road, but have come around to Wim and comment's way of thinking. I see a lot of developers coding like this:

Master Script

-Header section

If...

--do script A

Else If...

--do script B

End If

-Footer section

We want to develop DRY, and not repeat that header and footer logic in both A and B subscripts. But it's generally easier to maintain with this kind of structure:

-Header script

-Footer script

-Script A

--calls Header script

--does stuff

--calls Footer script

-Script B

--calls Header script

--does stuff

--calls Footer script

[bruceR]

Can you give a simple actual example of a script system that works like that?