mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline OP
Hoopy frood
OP Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
[Note: this also applies to /iline, because they share the switch and the event occurs for both commands]

Bug:
The -n switch for the listbox will stop a line from being added, but it will not stop a line from being recoloured. This is contrary to the same -n switch applied to the buffer (not the listbox). This in itself is not such a big deal. The problem lies in _when_ the listbox is updated... As you will see, the listbox line only changes colours when the window is unfocused then refocused later on.

Reproducing the bug....

1. Starting conditions:
Create a window and aline hello to both the listbox and the buffer:
//window -el20 @test | aline 1 @test hello | aline -l 1 @test hello

2. In the @window's editbox, try to /aline -n:
//aline -n 4 @test hello | aline -nl 4 @test hello

You'll notice at this point, no colours have changed.

3. Watch the colour change:
Now, unfocus the window by clicking on another window, and then refocus the @window

You will now see that from the same command, the buffer line is unchanged, but the listbos line has changed colours.

Discussion:
mIRC mentions in the help that it will prevent a line from being 'added' if it doesn't exist. It does not, however, say anything about changing colours. A bit ambiguous here, but ok. That's fine. As I have mentioned, the fact that the colour is able to change is fine with me. The real problem lies in:

a) the discrepency between the switch used in the buffer and the listbox
b) the time in which the colour change takes place

Solutions:
Besides fixing the timing issue of when the colour is updated [if at all], the issue of "should the colour be updated" would have to be addressed. It's either:

a) the buffer /aline is the right one, and the colour should not change (leave that functionality to /cline)

- or -

b) the colour should be changeable by using /aline -n in both the listbox AND the buffer (this gives some functional advantages like not having to check if a line exists before deciding if you only need a /cline or if you need to /aline it altogether). If this were to be done, then the timing issue of when the colour changes would need to be fixed in the listbox (and the buffer).

DONE.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2002
Posts: 208
H
Fjord artisan
Offline
Fjord artisan
H
Joined: Dec 2002
Posts: 208
It seems that it's not a matter of the window focus changing, but when mirc redraws the text. For example, selecting and deselecting the line does it. Moving another window on top of the text also does it. In one test, I moved my status window so that it covered the bottom half the text in the listbox, and only the bit that was covered over got changed red -- a strange sight indeed! Changing window focus itself has nothing to do with it, as long as the text is not hidden, or the window resized. Seems that the root of the delay is that mIRC changes the text color in memory, but skips the part where it redraws it on screen.


If I knew now what I will know then... maybe things will have been different...
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline OP
Hoopy frood
OP Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I'd like to just clarify that out of the two solutions, solution b is my preferred one. The ability to recolour a line using /aline means that extra functionality is also added: You can recolour lines by line data rather than line number (equivalent to using $fline() in conjunction with /cline, but much less awkward to write out).

It also makes sense in this situation, because the intent of a /aline -n command is to have a line added if it is not already added. And under the circumstances that you attempt to add a line that already exists, your intention is probably to also 'refresh' that line.. that would be a refreshing of the colour.

That's my little rant, though this is kind of a feature suggestion and bug report in one because I am quite certain the original intention was that the line colour not be changed. Of course as I just dsecribed, there are some advantages to allowing the colour to change..and since its already half implemented... cool


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2004
Posts: 73
M
Babel fish
Offline
Babel fish
M
Joined: Oct 2004
Posts: 73
There is a further bug related to this. Try using the aline command *without* a colour on a listbox item that you previously coloured. Guess what happens smile
It acts exactly if you had called the /cline -r to revert the colour back to it's default.
This is the reason I think this bug needs to be fixed so the colour does *not* change with aline -ln.

The workaround actually requires the awkward $fline you mentioned:
Code:
  
/aline -ln $iif($fline(@window,text,1,1),$line(@window,$ifmatch,1).color) @window  text

Joined: Feb 2004
Posts: 206
D
Fjord artisan
Offline
Fjord artisan
D
Joined: Feb 2004
Posts: 206
Post deleted by Darwin_Koala

Last edited by Darwin_Koala; 13/08/05 11:26 PM.

Darwin_Koala

Junior Brat, In-no-cent(r)(tm) and original source of DK-itis!
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019

03/03/2004 - mIRC v6.14

69.Added $line().color property, returns line color.


Gone.

Link Copied to Clipboard