 |
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
 Posted: Thu Nov 22, 2007 5:13 pm
[2.13] Odd things with optional params in #EVENT
|
I have been debating reporting this since 2.11, since my testing of it uses an undocumented syntax. For these test I am using the full #EVENT syntax of
| Code: |
| #EVENT [event] [arglist] [script] [class] [id] |
All tests can be done in the same session.
1. Launch CMud
2. Close Sessions window (ESC)
3. Enter at the command line as seperate entries
| Code: |
| #EVENT {a} {b} {c} {d} {e} |
| Code: |
| #EVENT {a} {b} {c} {} {e} |
4. Open the Package Editor (CTRL-G)
Once you expand the class d you will see that we have 2 events. The expected result would be only 1 event because the ID field is the same. This same result occurs if the 2 commands are entered at once with a ;. Note very closely the Params and Priority fields of the event outside of the d class, they show b and 30 respectively.
5. Delete all the settings created by step 3
6. Enter at the command line
| Code: |
| #EVENT {a} {b} {c} {} {e} |
Now when you check the new event in the PE you will see the Params field is blank. Click on the XML tab for the event though and you will find it has an arglist of b. While you are looking at it note that the priority for this new event is still 30 and the internal id=3. All the XML is colored correctly.
7. Click the Script Text tab for the event
8. Delete the event created by step 6.
9. Enter at the command line
| Code: |
| #EVENT {a} {b} {c} "" {e} |
Now when you check the event in the PE you will also find the Params displays nothing. Looking at the XML tab we find that again the internal id=3, priority is 30 and the arglist is there. Coloring is lost though. If skip step 7 or click to the untitled window setting then back to the event the XML will be colored correctly.
10. Enter at the command line
| Code: |
| #EVENT {a} {b} {c} {d} {e} |
Now we find that this properly created the class and moved the event into the class. The test in step 3 didn't have the same effect, that test instead created a second event.
11. Enter at the command line
| Code: |
| #EVENT {a} {b} {c} {f|g} {e} |
Now you will find that the class tree of f/g was properly made and the event is placed in the g class. All is well.
12. Enter at the command line
| Code: |
| #EVENT {a} {b} {c} {f} {e} |
Now as you examine the settings in the PE you will find that once again the event was moved. Depending how you had the tree displayed and what setting you were viewing the tree may not have updated.
13. Repeat steps 11 and 12 as needed to view the different ways the tree does not update. When the event is selected no update occurs in the tree.
A summary of what I think the actual bugs are, and yes I know we don't really want to be doing this kind of settings creation with commands.
1. A totally new setting isn't actually created in step 6. Something from the deleted record is being used. Somewhere around step 10 it actually creates a new event setting for the move, but I didn't notice it when it happened.
2. The XML arglist and the Params display disagree when bug 1 occurs, or possibly just when the class parameter is null. I didn't which is the actual cause from a fresh launch.
3. The ID parameter of the command isn't properly used to move the setting when the class parameter is null, this looks to also be related to bug 1.
4. The XML doesn't color when steps are done in the right order. Again looks to be related to bug 1.
5. The tree is not updated when the setting is being viewed, and the command moves it to a different class. Probably this one is already in the low priority area. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Fri Nov 23, 2007 3:15 am
|
Confirmed.
For steps 6 and 9 this is a caching issue with the package editor, if the package editor is closed when you enter this command at the command line then the Param field comes up blank, but it if the PE was open and you just navigate to it, then the Params field is populated properly.
I didn't pay close attention to the XML color stuff, but I noted all the other bugs. |
|
_________________
Asati di tempari! |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Nov 26, 2007 4:45 pm
|
I'll take a look at this. It might still be problems with using {} with optional arguments.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Nov 27, 2007 11:30 pm
|
Actually, one of the main problems with this is that you don't have the right syntax. The "arglist" is not a separate argument. The proper syntax when using an argument list is similar to an alias:
| Code: |
| #EVENT event(arglist) {script} class id |
So, step (3) should be:
| Code: |
#EVENT a($b) {c} {d} {e}
#EVENT a($b) {c} {} {e} |
Now, with that correction, the problem still exists with a second event getting created. I'll continue to check these other issues, but I wanted to clarify the syntax. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Nov 27, 2007 11:38 pm
|
OK, there was definitely a bug with it creating a new event instead of changing the class of the existing event. Also, there was a problem where it could mis-interpret the second parameter as the argument list in some cases.
The priority and ID might get reused if it was the last setting in the database that was deleted. The issues with the tree not updating isn't going to be fixed until the DevExpress components are upgraded in January. The XML color problem is related to a problem with the Scintilla editor not getting reparsed (it's in zScript mode instead of XML mode), and that is on the low-priority list. |
|
|
|
|
|
|
|
