Forums Scripts & Popups /haltdef & highlight.

I'm not sure where to ask this. According to the mIRC help docs, haltdef shouldn't halt any processing, but I can't seem to get highlight working properly when using /haltdef in an on TEXT event. A testcase should be sufficient to demonstrate this.

Many of you will already know how to add a highlight. If you do, add one that you can easily trigger and skip this, but make sure you add a tooltip message and check the tip message checkbox.
1. Type /abook -h to get to the highlight window.
2. Check the "Enable highlight" checkbox, if it isn't already.
3. Click the "Add" button to get to the Add Highlight window.
4. Enter $me in the "Highlight lines that contain these words:" textbox.
5. Check the "Tip message:" checkbox and add this text to the "Message:" textbox down the bottom of the dialog: ring... ring...
6. Click "OK" back to the main mIRC screen.

Enter the following code into a new script and save it:

You'll need 2 connections to trigger this, so open a new connection to the same server and join a common channel. Assuming the nickname for your first connection is foo and the nickname for your second connection is bar, activate the common channel window for bar and type /timer 1 5 say hi, foo! Switch to a different task, and wait 5 seconds.

I know mIRC help states "Note: Halting the default text for an event affects how mIRC displays the most basic information about IRC events to a user, so it should be used carefully.", but if I can't write a script that uses haltdef (or some alternative) and allows highlighting to function properly... well I see that as a significant loss of control and flexibility.

Granted, being able to halt the highlighting is great. It's what I was looking for earlier (to stop people from repeatedly highlighting me, which is very annoying) and I'm greatful that I've found this out. Is it possible to halt the default text, while allowing highlights to work properly?

Ok, it's way too early to test this out myself, but my only thought at this time is that perhaps the problem lies in the echo.
Try using the -m switch in the echo command and see if your behaviour still occurs.

*goes back to bed*

The problem lies within the haltdef. My testcase will prove this: if you comment out haltdef, the tip shows up like it should. I tried your suggestion. I even tried commenting out the echo altogether. The problem lies within the haltdef.

It works perfectly with -l :

Of course. -.- Close but no cigar.

Is this a joke ?
Ok you know that haltdef is halting the mirc default behavior. You're setting some highlight in mirc option (that affect the mirc default behavior)
You're using an on text event with haltdef so mirc won't do anything and complaining that mirc should do something ?

edit :
That's the problem, why would you want to use haltdef if you want mirc to execute his option, you can't have both, that's why /echo have some switch (-l here)

I was recently trying to script something similar to this and came up with a solution like this. If I get the jist of what you're trying to do I hope this helps


The if statement checks if highlighting is enabled then checks if the string $1- matches the highlighted words. If it does it will echo with the highlight function and highlight it in the specified colour.
If not it will echo normally.

Thankyou!


I believe your analysis of haltdef may be flawed. You claim it halts 'default behaviour'. I guess further processing (of remote scripts) fits quite nicely within this term 'default behaviour', so haltdef should be a wrapper for /halt by your (incorrect) definition. Lets take a quote from the mIRC help files:

Thus, your terminology is incorrect in the first place. I was asking if it's possible, and moving towards the "request feature" if it wasn't, because it's so unobvious that you don't even know what I'm talking about. Asking me "Is this a joke?" in this circumstance is extremely disrespectful. It implies that I am some form of intellectually inferior being, that my requests are not to be taken seriously. Yes, I was being fucking serious. I was trying to point out useful functionality that appeared to be lost, and request any possible solutions. Stop being a douche.

defunkt, thanks to you too

On a slightly related topic, what does -m do:
The -m switch indicates that the line should be treated as a user message, not an event.

This isn't very clear to me, because 'user message' and 'event' aren't very well defined in terms of /echo (eg. it doesn't trigger any events). Does this mean it wouldn't log the message?

I have long been wondering about that myself, and I see the -m switch applies quite often to custom text events. I have yet to find out what it functions in terms of its relevant purpose.

The -m affects how the switchbar buttons higlight
according to settings in options/display.

I think you mistook the -m for -n switch.

No he didn't.
The -n switch prevents the switchbar button from receiving *any* highlighting.
The -m switch makes it look, highlight-wise, as if a user sent a message to that window (handy when editing incoming user messages).

So -n is no highlight, -m is user message highlight, no switch is event highlight.

Yes I'm claiming it halts default behavior, but I didn't say it was halting further processing, wouldn't make sense since /halt is here.
And Yes the help file is talking about the default text but that would not be the first time there's an error.
I think I do.
The "is this a joke" part was because you seems to have pretty good knowledge in msl and not beeing able to figure this out is weird.
I still think that haltdef halts more than text, and that's why /echo has some switch to apply highlighting, beep/flash etc but if this is wrong, it's a bug then.

Ok, thanks much 5618, could you please give me an example of illustrating how these two switches come about?

Say you have @test opened and minimized (button visible).

/echo @test text
will highlight the text of the button in dark blue (like events do)

/echo -m @test text
will highlight the button (in red ) as if user text came in (on a channel for example)

Very nice. Thank you.

Wims, you know as well as I do how unorganised the mIRC help files are. The problem and solution would be far more easily identified if they were defined within documentation for /haltdef. I still think this is more relevant to haltdef -- haltdef should have the switches, not just echo. What if someone wants to write the message to a dialog using /did and echo 'you were highlighted, see the highlights window for more information'? ... not that I'm saying that would be a good idea...