Hi, I would like this feature implemented.

Currently, I am using a module system which makes use of /enable and /disable stuff. So that means incompatibility when used with *some* other scripts, which also uses #groups. I know I can use /load, /reload and /unload but I tried it, and it takes 7 seconds longer than using /enable to load all my modules.

So I wish to have something like this, and I wonder why it is currently not possible.

#group1 on

#group2 on
code here
#group2 end

#group1 end

What I mean is something I showed above.

Or, is there any good alternative to #groups that also work well?

#group1.1 on
#group1.1 end
#group1.2 on
#group1.2 end

disable group1.*

It cannot be done, because having #group2 enabled while #group1 is disabled, the script would become pointless.
As an alternative, you can use variables to save your settings. Then simply do if (%var1 == value) { do as if enabled } | else { do as if disabled }

I agree it would be nice.

The reason I gave is what I see to be a major argument against. Or maybe not. But people who script this are gonna get into a lot of troubles - you have to build a lot of checks to make sure both group settings mesh with your script.

If #group2 was nested inside #group1 and #group1 was disabled then #group2 would be disabled also (even if it's state was set to enabled). Having nested groups would mean that you could have an entire block of code and switch it all on or off with a single group (regardless of the state of groups contained within), but also enable/disable peices of the code within that.

I guess $group would need some new properties - maybe a .astate property to find whether an ancestor group is disabled, a .parent property, and perhaps an optional second parameter N to get the Nth child group.

Personally, i see nothing wrong with prefixing a group.. The enable and disable commands support wilcard matches, use them...

#myscript.section1 on
#myscript.section1 end

#myscript.section2 on
#myscript.section2 end

#myscript.section3 on
#myscript.section3 end

/Enable #myscript.*

There's your whole group. I mean dont get me wrong, nested would be kinda nice, but not an easier than to greate a new group prefixed.. Save Khaled some parsing work, and just do it the "long way".

Because that's not the same. If you have an event in a group and some of the code in that event 'requires' another group you can't close the parent group in the middle of the event, create another group around the nested code, then open another group, finish the event processing, and close that group. It just doesn't work.

I suppose you could technically make some extra groups outside of the event with nothing inside and simply check if ($group(#nestedgroupname).status == on) but it's an ugly way to do it.

And what is wrong with variables?

if (%myproject.isEnabled) {
}

Quote:

And what is wrong with variables?

What's wrong with groups within groups?
I've always wanted to do that too.

Not really related to this thread, but I'd also like an option to indent the contents of #groups.

How about saving Khaled some work because you're lazy? Why should he have to create a whole new parsing system to enterpret nested grups because you cant use a variable?

lol .. that is too funny to comment

Please leave this assumption to Khaled, you don't have to (and, IMO, shouldn't) diminish the suggestion just because you think we should save him some work. This is the Feature Suggestions board. Khaled filters them all already, meaning that whether you/me/he thinks this is such a hard work and the feature isn't worth it or not, he simply knows what to do.
So, we don't need to argue about this "save him some work" stuff, whether the suggestion is useless or not.

Also, this suggestion is fine, it's not like "omg make mIRC an OS!!!!!!!" so there is nothing wrong with it, unless you think it would worsen things (for users) by any reason.

I believe i still asked a question of which none of your responce answered it.

Additionally..



I did not say "Khaled is not doing this" nor did i imply it. I simply asked why Khaled should have to put forth (assumingly) a lot of programming time because you cant set a varibale, or use a prefix on a group.



Are you sure? I am just trying to get a good valid reason why this feature should be implimented. Thus far all i recieved was "because its easier". Well, to me, /set %toggle 1 if (%toggle) is just as easy as nesting a group. The suggestion that a(n) new/additional parsing system should be implimented because you think "it would be neat" to doesnt make sense to me.



I never said it wasn't all im inquiring about is "is it worth the extra work on khaleds part, to satisfy your lazyness?"

Yes variables could be used for nested groups, but then again variables could also be used for all groups, so I really don't see where the difference is. Groups are a simpler and cleaner way of doing something. They are directly part of the code which they affect so there is no initialisation required on the script's part, they can't be deleted by overzealous use of /unset wildcards or edited by curious users delving into the Variables section of the mIRC editor. They are simply better for the task at hand because they were created specifically for it.

Well, then read again what I said. The point of my post is that..

..is not going to be answered by any of us. You, me and everyone else but Khaled can't know what's worth the extra work on his part unless it's a clearly unreasonable thing like "mIRC OS" or something. Saying "this isn't worth Khaled's work" simply isn't a valid point to me.


Variables can't do what groups do, as starbucks_mafia said, and it's quite clear they don't, otherwise such an unique feature like groups support wouldn't exist. You're asking us to use "if (!%mygroup.blah) halt" on a lot of aliases and events? No, thanks. BTW, how would I apply this to a dialog? If the "group" is off, close it on the init event? No, that's not even close to be nice, thanks. Make a /dialog alias? Won't work with a $dialog() call, thanks. "Why on earth would you want to disable a dialog table?" Well, I won't start giving explanations here on everything I could do with a feature.

"What's wrong with #groupA.1 on, #groupA.2 off, #groupA.3 on (...)?"
1: That would be the same thing as using variables. I'd have to use "if ($group(#groupA.1).status == on)" everywhere.
2: Organization. Separating blocks of code not because of #groups not being able to be nested, but because of a common context, their subject.

This is all I could type before getting tired.

Yes, if I don't use Groups, I have to use /load /unload /reload stuff, which is much slower than using Groups to enable/disable stuff..

Startbucks:

I didnt offer variables as a complete bypass, i offered it as a suggestion. I was just saying that if you feel the need to have something enabled and disabled within a group, use variables. Yes, I realise variables can be deleted, changes, and whatever else but the point I was making is that it is possible to toggle and event with a variable.

To Cold:

Firstly I didnt give you a cocky attitude, so lose yours", Thanks"

Secondly, to answer your question



1. Instead if having a scructure such as:



I was suggesting


Now that both puts them in individual groups and offers a group toggle via wildcard match. Now how is that putting the if ($group()) crap everywhere?

2. That seems seperated to me? Are u looking for some other block format when you contain a code segment other than what mirc is providing? If it makes u feel any better, you can do..



Now its all nice and "organized"

Do you think it was a cocky attitude because of my "no, thanks" sentences? I can't understand why. It's just a different interpretation of yours, maybe of the whole post, because I didn't feel anything bad like that while typing (here I generally don't), meaning I couldn't intend to be cocky, so there's nothing I can do. Anyway, sorry. But if you want to continue on this subject, here's not the place. Let it be private.

About the main subject, whatever, I'm not into posting big varied examples of where the "if crap(?)" would be needed in such a de-centralized way of grouping, when a lot of relevant points are already there IMO, that's enough.

But that will mean considerably more work for scripters if they use them often.