It's not possible to enable/disable timestamps in Custom @Windows. So you can just use /aline @window $timestamp <text> to achieve the same results, and it would be consistent across all custom windows -- again, since the setting can't be toggled.

_________________________At least I won lunch.Good philosophy, see good in bad, I like!

Yes, I am quite aware of that, I just had a discussion about this very subject with Wims in the Help Forum.

Due to that, and this being the Feature Suggestion Forum, I am asking for it to be considered as a feature suggestion for a future release.

As to it being consistant across all custom windows, that why I suggested using a switch, just like /echo -t, and even pointed out that /aline already has a -t that has noting to do with time stamping.

The advantage of allowing tomestamping in any curtom window by window basis via a switch is that it can be enabled as required, without applying it to all, and most importantly, if implemented in the same manner as for /echo removes the dependaancy of $timestamp on the requirement of a time stamp format to exist.

Consider the documentation for /echo regarding the -t switch -

The -tN switch prefixes the line with a timestamp if global time stamping is on or timestamping is on for that window. N is optional and is the UTC value to use for the timestamp.

In other words, no time format - no timestamp.

I still haven't used $timestamp without a format, but it will probably generate an error.

Sort. You don't need to /window -s auto-sort timestampped echos. C'mon Ouims. That would be silleh!

And yes. /echo works in Custom @windows just fine, Erasimus. You can even use the -m and -l switches to adjust the window and text event/message/highlight color, and the -b and -f switches to support the beep and flash global behaviors, and the -i and -c switches to support default indenting and color stripping settings. And -t for timestamps. All these switches you want to use for emulating Message/Channel Text.

_________________________At least I won lunch.Good philosophy, see good in bad, I like!

No, there are a lot of things that you do, that I find silly, but they still make sense, it's the idea that I find silly.

I do not understand why you mention /echo's switches trying to argue /echo is better than /aline.This feature is not about /echo vs /aline, that would be misunderstanding the suggestion.

If you followed the thread in the other forum, it was demonstrated that there is no way to properly timestamp a message using $timestamp since $timestamp relies on the mIRC's option.

However there is something big I completely missed, it's that /echo -t is short for prefixing the line with $timestamp itself, it's not a separate feature which timestamp the line via its own way.I also got it wrong as to how it's working: if you have the option (alt + o > irc > message > timestamp events) checked but you delete the format and save, mIRC will automatically use a default format of [HH:nn]. So the problem with $timestamp is only limited to this option being unchecked.

And this is, if anything, what makes this feature suggestion invalid since we were trying to avoid relying on uncertain things.

That is, to be consistent, a switch for /?line would have to also prefix the line with nothing if the option is not enabled, aka it's not solving the problem: timestamping a line.

Right now there's no safer way than using $asctime or $time (both can take parameter) yourself, as part of your text to be display and the only way to improve this is to create a switch which is not dependent on the mIRC option. However if you keep thinking about it, you'll realize the problem, if it's not dependent on an option, then you have to specify the format yourself, which defeats the purpose of the switch: using a switch like -THH:nn:ss or prefixing your text with $asctime(HH:nn:ss) is very much the same and kind of invalidate this suggestion of a switch.

That being said, the original intention of this suggestion might have been to simply be consistent; that if /echo has a switch to prefix with $timestamp, /?line commands could have a switch to do that as well.

Quote:

Silly of him to not elaborate until questioned though.

I never tried to know, but regardless I still don't know why OP cannot or refuse to use /echo, sorting is just one counter example for /aline vs /echo. I can definitely read that he wanted this for /aline and not /echo, you missed that, somehow, it was and a way to show you he wants /aline and not /echo, and small taunt!

Edited by Wims (04/02/1904:59 PM)Edit Reason: how silly of me

_________________________
Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net

I do not understand why you mention /echo's switches trying to argue /echo is better than /aline.

I wasn't arguing one was better than the other, simply saying that /echo has the requested ability, so why not /aline.... but ...

Quote:

I never tried to know, but regardless I still don't know why OP cannot or refuse to use /echo

Are you saying that you can use /echo to output lines to a custom window ?. There is nothing in mirc.chm on the /echo command to suggest that, and the cutom window section of same file says use /aline etc .. and makes no mention of /echo.

If I can use /echo then problem solved

Oops I missed Raccoon's message stating that you can. That help file, and WikiChip need a complete clean up.

What is the syntax to target a custome window just use @windowname in place of #channel name ???

Are you saying that you can use /echo to output lines to a custom window ?. There is nothing in mirc.chm on the /echo command to suggest that, and the cutom window section of same file says use /aline etc .. and makes no mention of /echo.

If I can use /echo then problem solved

Yeah, you can, with at least one caveat being the sorting behavior (which doesn't seem to be a concern of yours). I checked, it's true that the synopsys says #channel instead of window for the parameter.

_________________________
Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net