Zugg Software :: View topic - [3.03a] Impossible to have an event's event the same as it's ID name.

Posted: Sun Feb 01, 2009 4:37 pm

Problem:
I cannot create an event with the event name the same as the ID. When I attempt to do this it will not save and will not show up in the tree view. Nor will it create valid xml code nor import correct code when it is the same.

Further Testing: It looks like other things might be affected by this as well such as triggers. I just repeated this experiment with triggers and it looks to have the same behavior.

Procedure:

Posted: Mon Feb 02, 2009 5:14 am

Confirmed. The events gets created, but the ID name does not get persisted.

Posted: Mon Feb 02, 2009 6:15 pm

Confirmed and added to bug list.

Posted: Wed Feb 25, 2009 8:25 pm

OK, I looked into this and while it's true, I'm not sure why it matters. In all settings, if the IDName is the same as the Name field, then both values are used the same.

In your example, I created an event called "test1" with an id of "test1". Yes, CMUD clears out the ID field because it's the same. But the event still works fine:

#RAISE test1

I can still enable and disable it using the "test1" name. So I fail to see where this has any impact on preventing anything from working properly.

Posted: Wed Feb 25, 2009 11:40 pm

If they start different then I edit the name and accidentally make it the same as the event, all the sudden the id field gets clobbered. It's not a huge issue, true, but its an example of it not performing how one would expect it to perform.

If I put an event ID in an event, I expect it to stay put. I think I'd be justifiably distressed if I put in text and then it disappears on me, even if it is functionally the same. I just don't like the idea of it clobbering my ids when I accidentally name the ID the same as the event.

Posted: Thu Feb 26, 2009 1:00 am

This is really done to simplify things for novice users. From a novice point of view, you don't need to worry about "ID" values. You don't normally use IDs for most triggers. In most cases, just using the full name instead of the ID is good enough. So there isn't a need to make a distinction.

When both the ID and the full Name are the same, CMUD clears out the ID field, indicating that the ID is no longer needed. If the ID field was not cleared, then changing the full Name would not be synchronized with the IDName.

Let me say it a different way...consider when you first make an event:

#EVENT MyEvent {#show fired}

In this case, "MyEvent" is both the ID and the Full name of the event. So I can toggle it on and off with:

#T+ MyEvent

Now I go into the settings editor and give it a different ID Name of "TestEvent". Now I toggle it on and off with:

#T+ TestEvent

Now I go back to the settings editor and change the ID back to "MyEvent". The ID field gets cleared. OK, fine, I can still toggle it on with

#T+ MyEvent

as expected. Now I go back to the settings editor and change the Full Event Name to "NewEvent". Now I toggle it on with

#T+ NewEvent.

If the ID Name didn't get cleared out, then the ID would still be set to "MyEvent" and doing "T+ NewEvent" wouldn't work. In other words, once you set the ID Name, there would be no way to go back to the original setup where you only had one name to worry about...you'd have to worry about both the Event Name and the separate ID Name from then on.

By clearing the ID Name when it is the same as the Event name, CMUD returns to the initial setup where there is only a single name assigned to the event (or other setting). The only other way to do this would be to add some sort of "Clear Name" button, and I'm really trying to minimize the number of buttons and options and only add something when absolutely necessary.

So yes, I agree it's a bit odd, but it does that for a good reason and it's just one of those things you need to get used to with CMUD, just like with the learning curve for any other software.

Posted: Thu Feb 26, 2009 2:39 am

Well, I would point out the following:

1) I think Event objects should all have IDs (and which should be unique). Unless you have only one event object per event type you will need to to differentiate the event objects by their ID to keep from disabling/enabling the wrong event object. If you have only one event object per event type then you hardly need an event for it in the first place.

1a) If event objects need IDs to keep from referencing the wrong one, then having an ID should be the norm and not referencing the object by the event name itself.

1b) If having an ID is the norm then it shouldn't clear out my ID under any circumstances. I put the ID there for a reason. If I want it cleared out I can easily select the text and hit delete.

2) Why would you need a button to clear out the ID field? Why wouldn't the delete key work to clear out the field? I don't follow how clearing out an ID field needs a button any more than clearing out any other field would require one.

3) Regardless, I always have an ID unique from the event name, so this whole feature/bug is mostly moot for me, I normally wouldn't run into this. I considered just not posting a further comment except that I so disliked the fact that CMud had cleared out the IDs I had intentionally put the way they were.

So we'll just have to disagree on this one. I thank you in any case for taking the time to clarify your reasons and thoughts on the matter. I do appreciate all the time you spend on the forums helping us out with problems and making Cmud a better product because of it.

Posted: Thu Feb 26, 2009 5:24 pm

Having IDs is not the norm. The intent is that you put the functionality (events, triggers, aliases, etc) into a class folder, or an entire module, and then enable/disable the module itself.

The purpose of Events is to have multiple scripts that respond to a single condition. For example, you create a trigger that detects your prompt and fires an "OnPrompt" event. Then, multiple packages can tie into this with their own OnPrompt events. The package that detects the prompt and raises the event doesn't have to know or care about any other packages that might respond to this event. If you wanted to disable certain functionality, you'd disable the module that contains the event, rather than the event itself.

If you find yourself manipulating individual events, then you really aren't using events any differently than triggers (which can be fired using the #FIRE command, similar to the #RAISE command for events).

As I said, IDs are for advanced scripters. In the majority of cases, you don't need to use ID values. Just keep your scripts organized into functional classes and enable/disable the classes...that's what classes are for.