Forums Feature Suggestions Identifier to check if on start is mirc starting

I have an on start event and the fact it runs when the script is loaded is a problem. I want to set a variable only when mirc starts. So perhaps an $isstart identifier which would return true if the on start event was triggered due to mirc starting or false if the script was loaded.

Don't need an identifier for this:

While it is easy to script it's such a fundamental thing for a scripter to want to know I'd say it still justifies a built-in identifier.

Of course I agree with him, this is a simple addition that would be quite useful.

I'll also say I personally don't understand why the on start event has to include on load in it's operation. I'd prefer to see the on start event trigger when mirc starts only. But people would rage and complain of backwards compatibility with that suggestion, event though there is an on load event.

You can also use $event to identify whether it's triggered by LOAD or START

At first I was excited by $event but it returns the name of the event. So it doesn't differentiate between starting mirc and loading the script inside the on start event

IMO this identifier is unneeded. Not because it can be done with scripting but because it's poor scripting to need such an $id'er.

The onLoad event is for just that; when the script is loaded. This is for things such as creating a hash table and filling it with defaults, setting default variables, creating files, etc.

onStart is an event for when mIRC(and the script) starts. This is for things like making sure needed files for day-to-day use are there, loading hashtables, etc.

The ONLY reason I can see the need for a $JustLoaded identifer is for a pretty(and unneeded) echo thanking the user for using your script, and as Argv0 stated, it's quite easy to handle this with the internal scripting engine

Actually, $justloaded is even less necessary, because ON LOAD already does this. In other words, if you actually are just trying to thank your users for using your script, you should be handling ON LOAD, not ON START. If the situation is that a user might unload the script and load it later, you should have some kind of %myscript.isinstalled variable to test whether it was previously installed anyway.

So in fact, I see no real use case for testing whether mIRC is "starting" in ON START.

another way to discern between the ON-START event triggered by a script loading the 1st time vs mIRC itself loading up.

if ($uptime(mirc,3) isnum 0-30) echo -s mIRC probably starting up
else echo -s probably is a script being loaded

I agree with this opinion the mIRC can change the method to the ON START event to make it not working while a user loads an script. i think now the ON LOAD event is not useful because the thinks that you can do with the ON LOAD you can do it with the ON START event.

on LOAD has very specific uses, westor. There are times when you want to do something only on loading the script and not when mIRC starts. So, yes, it is very useful. For example, if I want to create a file with default values when a script is loaded, then I'd put that in the on LOAD event. I wouldn't want that in the on START event because it would create the file every time mIRC starts, overwriting the new values that may have been added.

As far as on START, think of that as starting (not loading) the script instead of just starting mIRC. If I wanted all my hash tables loaded when mIRC starts up, then I would also want them all loaded if a script is loaded after mIRC starts. Basically everything that I would put in the on START event should run when loading a script as well. Regardless if the script is started because mIRC is started or because the script is loaded, I'd still want the stuff to be done. Now, yes, you could duplicate everything and stick it into the on LOAD event as well as the on START event, but that's rather pointless. It's better to just have on START trigger for loading a script and starting mIRC.

If you have trouble with these events, then you're probably using them incorrectly. Use on START for everything that you want to happen when a script starts up (for any reason... loading or mIRC starting). Use on LOAD for everything that should only occur when the script is loaded, such as creating default settings. If you're using these for other things, you should probably consider whether or not there is a better way to do what you're doing.

Now, there may be a scenario where you want something to happen when mIRC starts, but not when a script loads, but that should be rare. If you think you have such an example, please post it here. Someone might suggest a better option.

Indeed, I think the problem is that we've yet to see a concrete example for this scenario. I'm curious as to what pball's use case is. I'm more skeptical that such a scenario even exists.

There are quite a lot of possible scenario, the easiest one being you want to count how many time you started mIRC.
Imo, people should stop discussing the "can it be scripted" part and should rather give their opinion about the "is it a good suggestion". I agree with starbucks_mafia.

It probably has been done this way because most of the time you load a code that include an on start event, you want that event to be triggered, but this is most of the time, I agree we should have a way to tell the difference

I made a script to track up time as a percentage. It sets a fixed start time when it's first loaded and also uses another variable to track the time between start up and exiting mirc. So if you reload the script (to change the output alias for example), the start up variable will be reset and you'll track of your total up time.

I've had other suggestions on how to track the up time of mirc but neither work in the manner my script does. So in short I have a variable I need to set only when mirc starts and I can't check if it already exists to decide whether to set or not (due to another function of the script).

I'll post code if anyone is interested but I have to split now.

Counting the number of times mIRC is started isn't really a valid example. Yes, you'd have 1 extra time, but then again, mIRC is running when the script is first loaded, so you might as well count that. After all, you're counting how many times mIRC is started and if you don't count that first time the script is loaded, then you are missing one time. You're already missing all previous times mIRC has been started, but you can't get those. You might as well at least get the time it's running when the script starts, though. There isn't any reason to ignore that one.

And I don't think this is a case of "can it be scripted" anyhow. The suggestion is FOR a scripting option. The fact is, it's already doing what it should be doing. I'm not seeing a good reason for any changes. You can easily tell the difference using a variable.

I'm not sure why it matters if you start checking time when the script is loaded. If you don't do that, then there will be 0 uptime until you exit and restart mIRC, which seems like a bad way to handle that.

on LOAD sets your fixed variable. on START sets your other variable that gives you your uptime from the time mIRC starts, but also gives you something to use from the first time the script is loaded without having to restart mIRC to make it work. That certainly sounds like how it should work, and that's what it does.

I just don't see why you'd want it to not start providing uptime as soon as the script is loaded without having to restart mIRC first.

How it is not really valid? The purpose is to be able to say how many time you 'really' started mIRC, the example doesn't mention/care about previous times or if you might accept the value to be one more. It's a valid example you cannot handle without scripting and the fact that on start is triggered when you load a script has been and still can be a problem

It's a made-up scenario that there would be no good reason for doing. If you really cared, it's a simple -1 calculation. Remember that the request is for a SCRIPT solution as it is. If you can already do it very easily, then there is no good reason to spend time to create some other way to do it.

It's a plausible scenario among several others that would require scripting to know that information.I disagree, I'm pretty sure there's a lot of things that has been added that could have been done easily with scripting.

I agree with the addition of this identifier. The ON START event is a dual purpose event (LOAD/START), therefore we should have a way to distinguish between LOAD and START. I have had a scripted solution similar (identical?) to argv0's for a long time, but there should be a built-in identifier.

Rock: I'm curious, what did you need this identifier for?

Counting the number of times mIRC started would just be



Or, reworded: it would be "the total - 1", as Riamus indicated. No identifier needed here.

instead of subtracting by 1, technically you would have the ON START event increment your variable, and the ON LOAD decrement it. The START/LOAD events offset each other whenever the script is loaded, then all that remains is the count of mirc startups.

OnLoad, used to set the script up initally. As stated before.

Then the onStart, which handles each time the script is started


It would appear that this has gone from a feature request to being a tutorial on what each onStart and onLoad are used for.

I never said it was needed, I just gave one example, any other example would have its solution as well since it's scriptable, again this is beside the point.

Note: %numtimes in your code will always be 0, == $null should be used.

Ahhhh you got me there lol. It's been so long I can't even remember. But it's still there in my loaded file full of snippets. I do know it was a part of another something that does not appear to be there any longer.

Edit: Removed lol.

The "not needed" part is certainly not beside the point[/b]. It absolutely [i]is the point. The point is that you can completely avoid some $isstarting identifier by simply using the events as they are meant to be used.

Moreover, the fact that there has yet to be a real world use case for this shows that the benefit to such an id is really just hypothetical. The examples so far have been purposefully contrived, and that is my point. Of course you can have some arbitrary scenario where you could have ON START used for everything but script load, but where is the value in that? If there is some real value, show it, it matters. Because if not, why should it be added?

It should be reiterated that the original scenario was not actually meant to be done with ON START. That's why it looks super awkward with 2 event handlers. If the goal was to show something ON LOAD, then ON LOAD should be used. I'd question the scenario where "show something except during script load" is needed-- and even if such a case existed, your script probably has some kind of install flag that can be used to detect this already.

Ultimately what it comes down to is that every possible scenario I can think of can either be done with ON LOAD and/or is probably meant to be done with ON LOAD, not ON START. We should encourage users to use events as they are meant to be used. Is there really a consensus around adding bloat to the language just to give users another way to do the exact same thing in a less proper way? I can't get behind that.

If someone (hopefully pball, since this is his thread, so I assume there was a reason why he requested this) can explain what scenario would rely on this feature, and cannot "easily" be implemented with ON LOAD, I'm all ears.

Wims, you can always make up something that would fit what you want it to fit, but that doesn't mean it's really going to be used. Your example, as I stated, is something that is unlikely to be needed because your first load of the script is already showing that mIRC is running. And if you don't want it to show that mIRC is already running, then you can subtract 1 as stated. It just doesn't show any reason to make changes.

Yes, there are things that are added that can be done easily with scripting. HOWEVER, this request, as I've stated before, is FOR a scripting method. If you already have a scripting method that is easy, what is the benefit of adding yet another one? Besides, if you really want an identifier added, it would make more sense considering your example to request a # of times started identifier. That would be used far more often. Not that I think it is needed, but there is more value in that.

RoCk, an identifier would act just like a variable. You'd still need your IF/ELSE. The only difference is unsetting the variable when done.

As argv0 said, there hasn't been a really good example shown that is using on START and on LOAD correctly that doesn't work well because of how the events are designed. You can determine your event easily with a variable if absolutely necessary, though it shouldn't be necessary in the first place if the events are used properly. Instead of hypothetical scenarios, I agree with argv0 that pball should explain (or show code) his situation. It is almost guaranteed that it can be done easily by using the events properly.

I was talking about my point, not your, yes what you are saying is beside my point: you repeated in all your post that "it's scriptable, it's not needed" it's ok we get that, there's no need to repeat it again; however I'm saying that it's not because it's not needed that it shouldn't be added, again please answer the question: how many feature has been added that wasn't needed?The example I gave is a perfect and valid real world use case, again it's not because you can workaround it with scripting that the example isn't valid so I already showed a value there, not sure why this example is contrived for you, it's not for me.

The origianl scenario is irrelevant to the suggestion.

I agree that we should encourage users to use events as they are meant to be used, but clearly on start isn't meant to be used as an on load, it has been done like that for good reasons, or not, but again, cases where the difference must be made exist, yes it's workaroundable with scripting, but yes we should still be able to tell the difference without storing our own variable, you would end up having tons of variables for every little workaround like that and I clearly prefer having tons of built-in $ident than tons of global variable, which is imo (the global var) the less proper way to handle this

You are not understanding that pball's example is as basic as the one I gave, the same basic workaround exists with scripting.

How many features have been added that weren't needed? Really? So it's your opinion that we Khaled should add every possible feature regardless if it's needed? Yes, some things that aren't really necessary have been added. That is not a valid reason to add more things that are not needed. If you've noticed, Khaled has been trimming things down in mIRC over the past few versions (instead of adding bloat) by removing things (mainly settings) that are not needed.

The difference of using a variable or an identifier is so minor that it really isn't worth Khaled spending time making that kind of change. I'd much rather see him work on useful things that will benefit everyone. If the events are used correctly, you should not have any need for a variable anyhow. I still say your example isn't a good one. Most people would count the first use of the script as the first use of mIRC in that situation. Almost all of the remainder (besides apparently you) would not care one way or the other. If you can give an example that many people would run into, then please do. If all you can do is give examples that might only affect a handful of people, then there isn't any reason imo to do anything with this suggestion. And before you say it, yes, some things have been added in the past that benefit very few people. But that does not mean Khaled should add every idea that benefits only a few people. Besides, as I said before, if you are really that concerned about your example, you're far better off asking for an identifier for the # of times mIRC has been run instead. That would be far more useful and help far more people and would solve your example.

Asking for something that can be done without scripting even though it's scriptable is one thing. Asking for another way to script something is entirely something else.

And, pball, whenever you get back, please post your script (at least the on LOAD and on START events) so we can see why you think it's necessary.

I never said that, re-read my post please. Well what I mean is that something that can be scripted doesn't make it pointless to add.

Might be true and I would respect his choice, but note that adding this one wouldn't take time.
It doesn't matter, it's a valid one, please stop talking about what people would do if they were to implement it, it's pointless.
If you read carefully I'm not the only one; it's your opinion and I explained why I disagree, I don't need to give another example.

I cannot speak to language bloat, I can only say that I oppose language bloat in every instance unless it makes scripters lives significantly easier. That means it should take more than one line of code to re-implement.

Khaled might certainly have added features that weren't needed-- and I am saying that I disagree with those choices, and that we shouldn't use mistakes as a guideline for future development. FWIW, there are very few of these mistakes, though... I can only think of a very small set of exceptions.

In other words, if it is not needed, it should not be added. I don't know anybody who would willingly want to bloat the language just because you can.

!!Responce to no one!!

I have noticed that often when someone asking for something to be added to mirc they got the same answer, "It can be scripted", yes it can be scripted, and if not it can be done with a dll, i for one would like to see some new things added to mirc, if only things that cant be scriptet would make it in to mirc, then we would need to wait for ages for a new release, if no new fetures are added "they can be scripted", we only can look forward for bug fixes to be released, and this part of the forum is useless and a waste of space, no point for someone to try come up with new ideas if they only get the answer "it can be scripted or use bla.dll and it can do it".

I agree with sparta and whoever else mentioned the over used "it can be scripted" excuse. I also like that someone else mentioned on start is basically two events in one and it'd be nice to tell for which reason it was triggered.



I'm sure everyone and their grandma will try to make a better version and say how crappy mine is. But I made this to do a few things specifically. The initial time is set when you load the script and it should show 100% uptime after you load it. It also keeps a temp variable which tracks time every 10 min in case mirc fails to trigger the on exit. In which case the temp var and start var will be used on the next start up to update the total uptime. What it doesn't do, is not reset the start var when the script is reloaded (what the proposed identifier would fix). I don't care if you just say well don't reload it and it won't have that problem. If I want to change the output format and up reloading the script it'll throw the tracked time off.

If you can make something smaller than what I have and works in the manner I'm looking for great. But I think being able to stick a simple if statement with the identifier I'm suggesting would be perfect.

Like
if ($isstart) set %uptimepercent.start $ctime

What's wrong with telling someone that something can already be done? If you say: "mIRC should be able to do X" and I say: "mIRC can do X, here's how: ...", why is that not a good response? Why would your response be "but I don't like that and still want X!"?

To me the problem lies in the fact that people are not asking for functionality, but rather they are asking for the same functionality in a different form. In other words, when you say, "mIRC needs <specific identifier here>" you're not asking for a solution to a problem, you're asking for your own solution to a problem with an existing solution.

This begs the question: why can't the existing solution work? Note that in many cases, the existing solution can be scripted.

The problem of IGNORING existing solutions is that we end up with a scripting language that has hundreds of solutions for the same problem. It's the known problem of software bloat. Bloat is NOT a good thing. We don't need more than one way to do things-- it just makes the language complex, the implementation large, maintenance much harder, and for little benefit.

Lastly I should point out that the "it can be scripted" solution in this case is EASY. It's so easy, in fact, that using "ON *:LOAD:" is actually fewer characters than using an "if ($isstarted)" check if you actually ran into that scenario. And, especially in this case, when the solution is already about *scripting*, telling somebody that it can be scripted seems perfectly apt to me. "I need a way to script X" -- "here is how you script X" ... what is the problem?

In your case "$isstarting" is just a matter of checking whether your timer was created. You can also solve any other problems by unsetting %uptimepercent.start when you exit (and when you clean .temp), that way you can also check that .start is not set before setting it (in case only the timer was somehow turned off and script reloaded).

argv0 pointed out exactly why the answer here is that it can be scripted. The question was for scripting in the first place. Therefore the answer is going to be related to scripting it. Even if a new identifier was created or some other scripting change was made, it would still be "it can be scripted". You can't complain about that answer in this thread because that is exactly what this thread is asking for.

To everyone- In addition to what argv0 said, many feature suggestions are supported. Even suggestions where scripting is possible. That does not mean that people have to support every suggestion. If people think a suggestion is a bad idea or a waste of time, that should be stated. Suggestion forums (here or anywhere else) are not a place to boost your ego by having everyone agree with you. If your suggestion is good, people will agree. If not, they will not. And if they don't, then you shouldn't be so upset and complaining just because they don't agree with you. Everyone has different opinions and there is absolutely nothing wrong with stating your opinions. Don't get bent out of shape when someone disagrees with you ... especially when it isn't even your thread. Everyone here has had some of their own suggestions disregarded or turned down (those who have been here long enough to make more than a few suggestions). There is nothing wrong with that.

Two points here... First, if people disagree with your suggestion, you should listen to their reasons with an open mind. Then, if you still think your idea is worthwhile, use their comments to improve your suggestion so that it can gain support. If you still don't have support after discussing it, then it probably isn't a good idea. Accept that. No one has all good ideas.

And second, don't get upset when someone offers you a scripting solution. Scripting is a vital part of mIRC and is therefore a valid solution to a problem. And don't assume that someone giving you a scripting solution is saying your idea is bad. I've seen many threads where someone offers a scripting solution and certain people get involved and start complaining that "it can be scripted" is some horrible thing to say. And in many of those cases, the person offering the suggestion was offering a workaround until another option was available. There is nothing wrong with that. Simply put, if a scripting solution is available, it should be offered. That doesn't mean another solution can't be created if the scripting solution is not great. It just means the person asking for a feature will have an option in the meantime.

So let's stop complaining about people offering scripting solutions. It's a waste of time and just confuses the threads so that no one knows the real benefits or downsides of the suggestion. That is especially true in a case where the suggestion is asking for a scripting solution in the first place.

Case in point: my suggestion long ago that Khaled have mIRC make my coffee for me in the morning was shot down and I was told "It can be scripted"

This is actually still on my to-do list - milk and sugar?

It would probably be useful to have an identifier that indicates whether mIRC is starting up - I think I originally intended for on START to trigger only on startup but eventually changed it to trigger when a script is loaded as well to cater for any on START initializations. mIRC already has an internal variable that returns its startup state, so I will go ahead and add an identifier that returns this value for the next version.

yes, a splash of milk, scoop of sugar, please and thanks

Thanks Khaled and a high five to the others who liked my idea.

Milk and Sugar is for Cereal
http://cn1.kaboodle.com/hi/img/2/0/0/11b/e/AAAAAmkbbE0AAAAAARvliQ.jpg?v=1215975551000