By pball on Dec 20, 2011This is a simple script that lets you take notes inside a custom window.
Guide:
Type "/notes (optional name)" to open a notes window, if no name is given it will use the first open number available. (spaces are replaced by _)
You can type text into the text editor and hit enter to add the note to the window.
Select one or multiple lines and press the delete key to remove selected lines.
Notes will automatically be saved to file and when a notes window is closed you will be prompted to delete the note. If you hit yes the note will be deleted if you select no the note will be saved and can be opened at a later time.
There is an option to automatically load notes when mirc starts, this can be turned on/off in the right click menu which is available in all windows.
Also included in the right click notes options is the ability for bring open notes to focus and reopen closed notes. When a note window is reopened the size and location are remember.
If you use the alias command and give a name that is being used if the note is closed the note will be reopened and if the note is already open it will gain focus.
Updates:
You can edit entries in notes now. Please read complete before complaining about it doesn't work or is buggy.
Select a single line (won't work with multiple lines selected) then press "e" and the text will appear in the editbox. You can then edit the text and hit enter and it will replace the selected line.
Make sure no lines are selected when trying to type new notes, since if a line is selected and you press e it will replace the editbox with that line and go into edit mode. You can either hold ctrl and click selected lines to deselect them or right click below the lines in the window to deselect all lines
I think I remembered all the features and if you have any problems please let me know here.
Remarks:
When I was thinking how to save notes savebuf and loadbuf immediately popped into my head and they are great. But then when I was basically done I thought hey an ini would probably be a better place to store the info. Since it'd all be in a single file and wouldn't be any harder to access after making simple write/read aliases. So I'll probably redo this thing using an ini for saving notes.
meh if i'm going to continue adding features it'd probably just be best to switch to using a dialog, though i don't know if you can make them user resizeable.
/*
[Addon]
Script=Notes
Version=1
Author=pball
Desc=Create and manage simple notes
For=Mirc
Date=12-20-12
[script]
*/
alias notes {
if ($1) && ($isfile(notes\@Notes_ $+ $replace($1-,$chr(32),_) $+ .txt)) && (!$window(@Notes_ $+ $replace($1-,$chr(32),_))) loadnotes notes\@Notes_ $+ $replace($1-,$chr(32),_) $+ .txt
elseif ($1) && ($window(@Notes_ $+ $replace($1-,$chr(32),_))) window -a @Notes_ $+ $replace($1-,$chr(32),_)
elseif ($1) {
window -e0lk0 @Notes_ $+ $replace($1-,$chr(32),_) 100 100 300 200
savenotes @Notes_ $+ $replace($1-,$chr(32),_)
}
elseif (!$1) {
set -l %num 1
while ($isfile(notes\@Notes_ $+ %num $+ .txt)) inc %num
window -e0lk0 @Notes_ $+ %num 100 100 300 200
savenotes @Notes_ $+ %num
}
}
on *:input:@Notes_*: {
if (!%noteedit) aline $target $1-
else { rline $target %noteedit $1- | unset %noteedit }
savenotes $target
halt
}
on *:keyup:@Notes_*:*: {
if ($keyval == 46) && ($sline($target,0).ln > 0) {
while ($sline($target,1).ln) dline $target $v1
savenotes $target
}
elseif ($keyval == 101) && (!%noteedit) && ($sline($target,0).ln == 1) {
set %noteedit $sline($target,1).ln
editbox $target $sline($target,1)
}
}
on *:start: {
if (!$isdir(notes)) mkdir notes
if (!isfile(notes\popup.txt)) {
write notes\popup.txt Notes
write notes\popup.txt .$iif(%loadnotes,$style(1)) Load notes on Start: $($iif(%loadnotes,unset %loadnotes,set %loadnotes true),0)
write notes\popup.txt .-
write notes\popup.txt .$submenu($menunotes($1))
}
if (%loadnotes) noop $findfile(notes,@Notes_*,0,loadnotes $1-)
}
alias savenotes {
write -c notes\ $+ $1 $+ .txt $window($1).x $window($1).y $window($1).w $window($1).h
savebuf -a $line($1,0) $1 notes\ $+ $1 $+ .txt
}
alias loadnotes {
window -e0lk0 $gettok($gettok($1-,-1,92),1,46) $read($qt($1),1) notes\popup.txt
if ($calc($lines($qt($1-)) -1) > 0) loadbuf $v1 $gettok($gettok($1-,-1,92),1,46) $qt($1-)
}
on *:close:@Notes_*: {
savenotes $target
.timer -m 1 10 closenotes $target
}
alias closenotes { if ($?!="Delete $1 $+ ") .remove -b notes\ $+ $1 $+ .txt }
menu Menubar,Query,Nicklist,Channel,Status {
Notes
.$iif(%loadnotes,$style(1)) Load notes on Start: $iif(%loadnotes,unset %loadnotes,set %loadnotes true)
.-
.$submenu($menunotes($1))
}
alias menunotes {
if ($1 isnum) && ($findfile(notes,@Notes_*,$1)) {
set -l %fn $v1
return $iif($window($gettok($gettok(%fn,-1,92),1,46)),$style(1)) $gettok($gettok(%fn,-1,92),1,46) $+ : $+ $iif($window($gettok($gettok(%fn,-1,92),1,46)),window -a $v1,loadnotes %fn)
}
}
I'll see what I can do with the side listbox idea, then only one note window would be needed. Yeah I was also thinking about seeing if entries could be edited. Perhaps selecting a single line and hitting a key like "e" for edit would put that line back in the edit line and when you hit enter it'd replace that line with the new text. I think having a key to initiate the edit would be easiest since you wouldn't know if a selected line is supposed to be edited other wise.
Gotcha gotcha. Been so long since I played with a window in Listbox mode :|
Why not limit the length of a single input, then? I'm sure there are some people who would try to enter in a decent length of text, and will be mad that they have to adjust the window size to see it. They'd be even more mad if for some reason they couldn't figure out that you can adjust the window size to see more text. I do understand the purpose of this is for short little notes, but sometimes people can't trim what they want in one entry down enough to fit the constraints.
And on the note of interacting with notes.... what interaction is built in so far? Because I can't find any... :( is there some feature I'm missing here?
Yeah after playing with it a bit more I realized the format. As for dialogs, just saying it was my taste, @Windows server your purpose just as well don't they? :D
As for the line length, take a look at using the -p switch on your aline command under note entry. This would force it to wrap if it's too long. Otherwise unless I broke everything up manually, it'll be a mess if I do a decent ramble in one entry. When writing what's in the @Window to the save file (or INI when updated), even though one entry is split up amongst two or more lines, mIRC will remember that it's all one line and enter it as such to the file.
//window -d @Test -1 -1 300 300 | /aline @Test This is Line 1. This is a test without word wrapping. You can see that it's messy (but mainly because this window is so small) | /aline -p @Test This is Line 2. You can see here that this line is broken up amongst several lines for display within the window. | /echo -s $line(@Test,0)
Copy that and paste it in your mIRC's editbox. You can see that even with word-wrapping, mIRC still reports there are only 2 lines there.
You are misinterpreting how the notes are formatted. There is the name of the note @Note_1 and the content, which is made up of separate lines due to using the listbox mode of the @window. So the ini would be formatted like so.
[@Note_1]
[size]= 100 100 300 200
1=line 1 of note
2=another line of note
3=and so on
I also realize having the window be in listbox mode has disadvantages like lines don't wrap so the length of a line is limited to how wide you can make the window. However I wanted to be able to add multiple items to the note and be able to interact with them, something I don't know if you can do with normal lines in an @window
I wanted this to be a simple system so I used built in things like @windows, if you want a complex note system a dialog would be the best method but it's not what I was going for.
How exactly would your INI be structured?
[Note_1]
title=This is my First Note!
body=And this is the Note I left myself.
??
Unless you're going to have multiple items in a section (like this), INI wouldn't do much good. Of course, title and body are just the beginning... you could have a lot of other settings for a particular note saved in the same section, if you can think more stuff up.
A different way to do things would be to have a dialog with an editbox, a text box, and a list. The list is filled with all currently saved notes' titles, and when you double-click one it opens it up in the textbox (and in the editbox for editing). Of course, there would be a save function on it as well. I myself don't see the @Window being the best form of presentation of your system, but that's just my tastes.
wow I like there is finally on topic discussion for one of my scripts. but for something that started as a three line script things are getting complex fast. for the argument of long lines, that shouldn't be a problem for multiple reasons. the window is a listbox so lines don't wrap so you can only see the part of the line that fits in the window and this is a notes script and the point of a note is a short message to remember something.
also personally i feel an ini would just be easier than trying to create some structure to manage different notes when inis have sections and such.
filter -fk notes.txt note_fill *
alias note_fill {
tokenize 32 $1
aline @Notes $2-
}
We can assume for this example that we will not encounter line runout. If we did, wouldn't INIs just have the same potential problem with runout anyway? Bringing INIs up because of the statement in the script description.
The script which handles note input can be made to either toss an error toward the user is the entered text is over X characters long, or if one wanted to take a more complicated route... Make the on INPUT automatically break up the lines at set amounts of characters, and enter each broken-up piece into the file with the ID. If an input is broken up, it can have $2 an identifier to show that it's part of the same line as before, which the filter's output alias would have to interpret. Then the problem should be the maximum length that mIRC can process on any one line.
Though, I do see your point. $read() with the S switch to find the first line (and of course strip out the ID code), and then continue reading until it determines that the next line is the beginning of another note? Then there would just need to be some sort of marker that shows that it is indeed the start of the next note.
var %string $read(notes.txt, S, $+($chr(186),NOTE_ID))
tokenize 32 %string
aline @Notes $2-
var %x $readn
:loop
inc %x
var %string $read(notes.txt,%x)
tokenize 32 %string
if ($chr(186) !isin $1) {
aline @Notes $1-
goto loop
}
Something like that? Use the degrees symbol or some other rarely-used symbol attached to the Note ID to give a pretty definite confirmation on if the next line is for the same note. $chr(186) could also be used as matchtext in a filter or something to grab the names of all currently stored notes, without having to maintain a separate list somewhere.
unique identifier, which would be appended to the beginning of each line within a single text file. Then use filter to pull up the relevant identifier, and discard the identifier from the output. This could be achieved by using filter -k and filtering through an alias which does a tokenize 32 on the input text, then returns $2-.
~= $read's 's' switch, which is actually much more efficient.
You could give each note a unique identifier, which would be appended to the beginning of each line within a single text file. Then use filter to pull up the relevant identifier, and discard the identifier from the output. This could be achieved by using filter -k and filtering through an alias which does a tokenize 32 on the input text, then returns $2-.
Then you would just need to make a system to make the notes manageable to the script and be user-friendly. Perhaps requiring them to enter a title on their note(s), which would replace spaces with underscores. Then, the title (with underscores) could be used as the identifier.
actually Jethro is on the right track. [] work fine in ini files in pre v7 and post v7 mirc, though if you update from pre v7 to post v7 you have to manually change the ~~ to [] since v7+ changed the ini routine or something. I encountered that in my WB script and having to manually change the ini file when switching from 6.xx to 7.xx was the only problem.
There shouldn't be any problem with [] in the text inside an ini, even the title can have [] in it and it'll work fine. In older versions of mirc [] were changed to ~~ in the title portions of inis but not with mirc7.
Yeah I know the code is messy looking, but I purposely did that ^_^
Though I do end up unjumbling it every time I work on it, lol.
how would you make it linkable if adding a link? - err link clickable