Forums Scripts & Popups Get mIRC to watch text file and dump text live

Hi All,

My first post so please bare with me...

I am trying to get mIRC to watch a .txt file that is constantly getting written to by a paging receiver application. I am after a script or line of text I can use to extract/watch a .txt file and dump it live to a channel.

There are two possible ways to do this:

Script to watch .txt and dump lines as they are updated by another application

The paging decoder program "PDW" is able to run a .bat file with arguments. Is there a way to get a bat file enter text into an already opened channel as each message enters?

I hope this isn't to confusing. Any questions please ask. I am very eager to get this working asap but an exhausted my searching ability on the net.

Thanks in advance.

Cheers!

My recommendation for sending the contents of a text file to a pm/query or channel window, is to use mIRC's /play command.

With mIRC 6.35, type /help /play
then choose the 2nd /play option

Hi RussleB,

Thanks for your quick response.

We have tried using the /play command but it doesn't check for 'new' data in the text file. It just 'plays whole text file' and not just 'new' data in the text file.

I know this is a weird thing but it would be awesome if someone had ANYTHING close to what we are after.

Thanks in advance.

Cheers,
Josh

if the application is not able to send mIRC any indication of having written to the file (incorporating a DLL that triggers events or otherwise) then you'll have to poll the file periodically to check if it's changed. there are several ways of detecting a change in a file, an efficient method being to compare $file().mtime to see if the value returned differs from what it was previously. of course, a change there might not necessarily imply a change in the file's contents, it's possible that an external process wrote to the file and then removed what it wrote. this might not apply to your case in particular, but it's something worth considering in general

other checks involve examining the data that makes up the file, such as comparing $crc() or $md5() before and after results, but these run slower than checking $file().mtime which might be a crucial distinction if you plan to perform this check every second or so.

If it is only ADDING lines to the file, you can check the $lines and if it's greater than the last check (stored as a variable), then display the new lines. That won't work if it's removing lines or changing lines.

Any check of whether the file changed or not would be pointless, since you gotta find out what changed anyways.
You might as well go right away and scan the file for the changes.



This alias can be triggered manually, or used with a timer.
A note on this is that this check can take a while if the file is long!
If you set it to run every couple of seconds, be ready for mIRC getting frozen.

Good luck,
ziv.

that is extremely illadvised, a very quick and simple check such as $file().mtime is certainly not pointless as you save mIRC the trouble of having to load a potentially large file into memory and 'scan' it or otherwise when it doesn't have to. if this check is performed even slightly more often than the file is modified, it should be employed. consider what would happen if the external application was such that it added lines to the end of the file, on average, every 30 seconds (it is a paging application after all). what you're advocating will traverse the file line by line with the notoriously slow $read() until it either reaches the end or finds a line change. now imagine this being done on a significantly sized file every second (or however often the OP deems suitable), resulting in an unnecessarily intensive check an average of 29 out of 30 times.

that is why simple checks such as those on $file().mtime are valuable, it allows you to abandon the operation and save yourself extra unnecessary overhead on a good portion of thse checks. then, if the mtime has changed, we can go forward with a more thorough test such as the one you described (though preferably with file handling commands or such)

Additionally, if the file was of sufficient size, due to the slowness of $read, it could take longer to check the file for changes than the delay the OP wants.

/fseek <handle> <pos>!

Do you people know ANYTHING about file handles at all? AT ALL? I find it SO frustrating people don't understand what is truly a basic concept. Only with mIRC users too can't seem to grasp this.

Okat okay... i understand it's not so basic. Give me a sec i'll write an alias that shows how to use it.

In the meantime, look at this post as it holds the key...

There try that...

Yet, as you fopen a file to check for changes, mIRCs file handling might prevent that other app to access the file and do the very changes you're looking for...

It closes access to file the file when done. It does not keep the file open when it doesn't need to. Please be realistic. The amount of time the file will be open is but milliseconds.

And it'a not my fault mIRC opens every file with write access. I've asked for read-only access with this command. I don't understand why write permission isn't required to be declared when you use /fopen.

Don't you know anything about /filter at all? AT ALL? I find it SO frustrating people don't understand what is truly a basic concept.



Consistently performs twice as fast as the file handling method
Oh yeah, less code too.

I never said or implied that there wasn't a better/faster way of accessing the file. The post that I was replying to used $read, thus that is what I referenced.

/fseek takes no time at all. Like 0 ms to move to any position in the file. Regardless of size. /filter has to read the entire file every time. And you use $lines which also reads the entire file.

What my alias does is read thru the file the first time, then stores the file pointer position at the current end of the file. Each subsequent time, it then attempts to read the file starting where the file ended the prior time. If the file hasn't changed, it reads nothing, and the file position stays the same. If the file has been appended with new data, it reads up to the new data and stores the new position of the file pointer.

The amount of code is irrelevant. And why did you change the subject? I shouldn't even be responding to this. But you've distorted what I stated. Hixxy, fseek is a low level operation. One that mIRC itself performs. The /fseek command basically

/filter doesn't read the entire file when the -r switch is specified, it reads the range specified with the [n-n2] parameter.

Like I said, this works twice as fast as the file handling alternative.

Just stop it Hixxy. This thread isn't about /filter versus file handles. I've explained how alias works. And that's all I can do. Stop stating one is faster than the other. It's nowhere near as simple as that.

Remember that YOU are the one who started the "this is better than that" argument. If you can't accept someone else has a better/faster method, then don't start such discussions.

hixxy :*

we could also use /loadbuf -a here :P

I didn't start this. I offered a solution. A solution that works and can used even inside a hires timer monitoring a very large file and have no impact on mIRC's performance. It won't lockup. And if you don't believe me try using it yourself.

You know... just go here... http://en.wikipedia.org/wiki/Fseek

It's because of people like hixxy that make trying to explain how to use file handles next to impossible, F*ck it I think it's most of you people who have post counts into the 1000s. Really. I do.