fails to properly lock the created window. It seems it will only work if the Notpad in question contains at least some text.
While I helped myself out by starting up my capture notepads so they contain a single newline before setting them to readonly, I failed to see any particular reason for this feature and assume it is a bug.
Well, I'm just trying to set up some notepads at startup where I can capture tells, party and clan communication and I think it's better to have these non-editable...
Personally, I would rather use miniwindows to do the job, Although miniwindows are rather more complex, they're much more visually pleasing, and you can color the text you draw to one (for example, if the MUD itself sends coloured messages and you want to keep those colors). [1]
As an aside, I've been working on a "miniwidget framework" for the past month or so, to try to help make miniwindows easier and more intuitive to use. It's not quite ready for real use at the moment, but it's getting closer every day. Whereas now you would need to use the raw miniwindow functions and implement their behavior yourself, with my framework you would be able to put together some pre-created widgets and you'd have a working visual text area.
If that's something you're interested in, let me know; in a small community like this, it's sort of hard to get word out. (Excuse the shameless plug!)
Well, wonderful. While I would love to have multiply colored text in notepads or similar windows, I think I'll live with my notepads since I think I will neither want to dispense with features I deem essential nor do I want to code scrollbars let alone marking or copy functionality for mini windows, thank you...
I think it would be an immense pain to make a miniwindow be anything coming close to what a notepad can do right on the fly after creation.
Though I think it could even be done, so if you have code ready for that, feel free to post a link for download, Twisol...
Since I'd like to see how fast a miniwindow will be, serving as a resizable, text drawing, word wrapping, scrollable viewport with, let's say, 20000 bytes of differently colored text in it.
If it's still all green then, we'll see whether and how we can add these mark & copy features...
I've personally seen a proof of concept written by someone else, unrelated to my framework, that emulated a Win95-style cmd.exe window completely, except of course that the content of the text area was just a bunch of lines, and there's no keyboard interface to it. It worked quite well for such a simple demonstration.
I agree, it would definitely be a pain to do this... if you had to do it all on your own. That's sort of what the widget framework is supposed to help with, though; it comes with widgets that have already been pre-implemented, so you just say "I want a new CharacterGrid widget" and it gives you a new one. Of course, it's slightly more complex than that, but I think it does a great job of hiding the details to the casual user.
Also, since you mentioned speed... if you have 20,000 bytes of text, chances are good that not all of it will be visible. One obvious optimization is to only draw the text that is visible. That would cut out... well, the vast majority of that 20,000 bytes.
I can't blame you for sticking with your notepads, I did say miniwindows were fairly complex! I just thought I'd bring it up, since if it were easier, it would arguably be a lot better. If you're interested in downloading the framework to give it a whirl, check my signature. Be warned, though - there are almost no general-use widgets available, so you probably shouldn't even bother currently. (That's what I'm working on now, heh)
As a torture test for miniwindows, I made this alias which displays 200 lines of 100 characters, each separate character with different text, and different colour.
Type "test" to run it, and you will see a large window appear filled with random characters. Now you should be able to scroll the MUD underneath without any noticeable slowdown in scrolling speed.
However 200 lines is a bit excessive, 50 lines is more likely, so that would be even faster.
Of course, there are two speeds here - one is creating the window with all the characters in it, this is done once by this alias. The other is simply drawing it over the rest of the text, and that is fast because basically it is just "bit blitting" the image on top of another one.
<aliases>
<alias
match="test"
enabled="y"
send_to="12"
sequence="100"
>
<send>
COLS = 100
ROWS = 200
win = "_test"
font = "f"
function Display_Styled_Line (line, styles, id)
local left = 5
local top = (line - 1) * font_height
for _, v in ipairs (styles) do
left = left + WindowText (win, id, v.text, left, top, 0, 0, v.textcolour)
end -- for each style run
end -- Display_Styled_Line
WindowCreate (win, 0, 0, 0, 0, 6, 0, 0)
WindowFont (win, font, "Lucida Console", 9)
font_height = WindowFontInfo (win, font, 1)
local font_width = WindowFontInfo (win, font, 7)
local window_width = font_width * COLS + 10
local window_height = font_height * ROWS + 10
WindowCreate (win, 0, 0, window_width, window_height, 6, 0, 0x111111)
WindowRectOp (win, 5, 0, 0, 0, 0, 5, 15 + 0x1000)
colours = {}
for k in pairs (colour_names) do
table.insert (colours, k)
end -- for
styles = {}
-- generate test data
for row = 1, ROWS do
local t = {}
styles [row] = t
for col = 1, COLS do
table.insert (t, { text = string.char (math.random (32, 127)),
textcolour = ColourNameToRGB (colours [math.random (#colours)]),
backcolour = ColourNameToRGB (colours [math.random (#colours)]),
} )
end -- each col
end -- each row
-- display test data
for k, v in ipairs (styles) do
Display_Styled_Line (k, v, font)
end -- for each line
WindowShow (win, true)
</send>
</alias>
</aliases>
For advice on how to copy the above, and paste it into MUSHclient, please see Pasting XML.
