@Timendus: TASM is a buggy POS, so I'll try and see what the problem is.
Does the "Test All" project build at all? That should build. If it doesn't, try replacing the TASM.EXE with the version from the earlier beta... The only major difference is it sticks ../bin/ in front of the output filename so that the output binary appears in the ../bin/ folder (I was trying to neaten the whole "help, I have 120 files in my project folder!" thing).
New version (EXE update only):
http://benryves.com/bin/LATENITE_BETA_0.0.1.1.zip
Major bugfixes;
-- memory access bug caused by icon cache trying to cache icons in an image list control that was only half-existant fixed (this caused a cryptic protected memory read/write access error rather than the expected missing object error).
-- behaviour when saving dirty files when closing the application works as it should.
-- invalid path/filename combinations on the new project form stripped properly.
-- creating new projects will now prompt on every file overwrite, and will also exit more gracefully.
Minor bugfixes;
-- streaky lines in the error/search result boxes should be culled with some window message interception.
-- "search in project" should no longer lock the CPU at 100% until finished
-- syntax highlighting massively speed-optimised.
-- labels (xyz:) are now highlighted better, not just "any word with a colon in it"
-- source files now load at a low priority and in the background (you can't see them loading). This is only a problem with massive files (eg ti83plus.inc) which seem to never ever load. This needs fixing, I am open to suggestions
New 'features';
-- the open dialog now lets you open multiple files at once (OK, not such a great feature).
IMPORTANT WARNING:
The syntax highlighting code was partially rewritten by me - most importantly, the bit that was rewritten was the bit that worked out which lines were dirty and the bit which performed the actual plain text -> RTF colour conversion. If it gets this conversion WRONG, that line will be invalid (and possibly the line after it if it mangles a newline character).
Those of you who have done plain text->HTML then HTML->plain text conversions (eg to escape for a database) will know that in some instances a slightly weird string can completely mess everything up. Nobody is perfect, and so I must beg that you
perform backups of your code before you use this editor.
I have had the editor eat up two of my source files - one was my keyboard equates file (it didn't escape a { properly - think of it like HTML's <) which had a couple of lines missing. (The other was a more important file, but that was my pure stupidity in renaming a string, causing the save function to write a
different string to disk on top of the actual file.
I just don't want the editor to go wonky and damage some of your work without you having saved. On a more cheerful note, I managed to open and save every single one of my (recent) Z80 ASM files and edit them without the contents being damaged. There might be one bizarre situation I am yet to cover.
About the theme bug fix:
I got around this with a real hack that
should not work. It does on my PC. What I essentially did was to create a new class that inherited from System.Windows.Forms.ListViewBox (the dodgy control) and added this:
Code: Select all
/// <summary>
/// Hacky override to fix the garbage lines.
/// </summary>
protected override void WndProc(ref Message m) {
if (m.Msg == 0xF) { // 0xF is WM_PAINT
GridLines = false;
GridLines = true;
}
base.WndProc(ref m);
}
It intercepts the window message and checks to see what it is - if it's a WM_PAINT message (repaint the control) it switches gridlines off then on again before passing control to the base class. I can't see how this works... so if you still get them on your machine, give me a shout!
Slow, slow, slow!
Perhaps it would be a good idea to discuss the use of ;; a bit more first though. Not that it's really neccessary, but it would be nice if one source produced the same XML in both Latenite and the website...
