SphereServer BugTracker - SphereServer |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0001881 | SphereServer | new feature request | public | 01-01-11 21:39 | 09-01-11 23:31 |
|
Reporter | jeem | |
Assigned To | ShiryuX | |
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | |
Platform | | OS | | OS Version | |
Product Version | | |
Target Version | | Fixed in Version | 0.56c Nightly | |
Nightly Version | Not Available |
Experimental Flags | None |
Option Flags | None |
Internal Build Number | |
|
Summary | 0001881: Enhanced Custom Triggers |
Description | Using custom triggers, on occasion I need both ARGN values and ARGO. I've been doing my work with VARs and TAGs but it'd be nice to be able to use multiple arg values. Usage could be like this:
trigger @customtrigger,tat_as_argn|tat_as_argo,ARGO,ARGN1,ARGN2,ARGN3
trigger @customtrigger,tat_as_argn|tat_as_argo|tat_as_args,ARGO,ARGN1,ARGN2,ARGN3,ARGS
trigger @customtrigger,tat_as_argn|tat_as_args,ARGN1,ARGN2,ARGN3,ARGS
trigger @customtrigger,tat_as_argo|tat_as_args,ARGO,ARGS
trigger @customtrigger,tat_as_argns,ARGN1,ARGN2,ARGN3 |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | |
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
01-01-11 21:39 | jeem | New Issue | |
09-01-11 06:26 | ShiryuX | Note Added: 0000820 | |
09-01-11 07:19 | jeem | Note Added: 0000821 | |
09-01-11 18:39 | ShiryuX | Note Added: 0000823 | |
09-01-11 23:31 | ShiryuX | Note Added: 0000824 | |
09-01-11 23:31 | ShiryuX | Status | new => resolved |
09-01-11 23:31 | ShiryuX | Fixed in Version | => 0.56c Nightly |
09-01-11 23:31 | ShiryuX | Resolution | open => fixed |
09-01-11 23:31 | ShiryuX | Assigned To | => ShiryuX |
Notes |
|
|
I like the idea, since it's pretty useful, though, seems a little hard to implement, since we will need a special order for the arguments and I don't think everyone is gonna respect them. Also, I don't want to break backwards comp. |
|
|
(0000821)
|
jeem
|
09-01-11 07:19
|
|
We could have new trigger types for backward compability. Flags could start from 04 and we could keep the 3 types we already have.
Or, we could have a 4th type which will be called as tat_ar_allargs or something. Then the trigger will take all available arguments defined. Like this:
trigger @customtrigger,tat_as_allargs,ARGO,ARGN1,ARGN2,ARGN3,ARGS
If we don't need any one of the arguments, we could just live it empty or 0.
trigger @customtrigger,tat_as_allargs,0,25,4,0,empty
This way, all arguments will be defined in only one order. |
|
|
|
I like it, makes sense, ARGO, ARGNs, and if there are more arguments, ARGS.
TAT_AS_AUTO, TAT_AS_ALL or something :P |
|
|
|
- Added 0001881: TAT_AS_FULL trigger type to TRIGGER function to set ARGO, ARGN and ARGS.
Example: TRIGGER @MyTest,<def.TAT_AS_FULL>,01,100,200,300,here,start,my,args
will call @MyTest with ARGO.UID=01, ARGN1=100, ARGN2=200, ARGN3=300
and ARGS=here,start,my,args (this supports ARGV[].) |
|