Allow timestamp on /aline (etc.) via a switch similr to -t that exists on the /echo command.

Unfortunately -t is already in use on /aline to force line re-wrapping in the custom window (why wasn't -w or -r used for this ?)

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.

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.

Have you tried /echo

Have you tried /window -s

Yes, but it only works with channel windows and the status window.

With custom windows you have to use /aline, /dline, /iline, /cline or /rline, and none of these currently support time stamping.

NOTE: /dline would not require time stamps - it is for deleting a line.

????

From WikiChip


Sorry I don't see the relevance.

There's no problem using /echo with a @custom window

When you sort a window with /window -s or -S, line added with /echo won't be sorted.

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.

@Erasimus, the reply from wims of "have you tried window -s" was directed at me. Silly of him to not elaborate until questioned though.

As I alluded to and others have pointed out -- unless you plan to sort the lines in the custom window -- you can use /echo to add lines to a custom window. as you would any other buffer

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.

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!

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


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 ???

That was addressed to Raccoon.




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.

Thanks .. as I said, prblem resolved.

The feature request was based on not having the information about /echo's ability to deal with custom windows.

Just checked it and it works, so this can be closed, as far as I am concerned