ive been thinking about putting auto completion into FASMW.
what i mean is when im coding i press CTRL+SPACE and a listbox
drops down with a list of words to auto complete what im typing.
or even finish the word if theres only one choice.

you could load the contents of the drop down list in a file say "dropdown.txt"
that way it can be customised.
mainly i would like it for the windows api commands as the assembly
instructions are typed easy enough.

now, the implementation.
have to parse the text file and load each line into a listbox.
the listbox is initiallity hidden, but when CTRL+SPACE is pressed
unhide it and place it at current position in the FASMW text control.

im a beginner at assembly, however i do have some experience with the windows api but my problems are.
getting the current position to place the listbox.
understanding FASMW source code to place my code in the right places
and making sure i dont mess up FASM and its compiling.

efficient text file parsing. and also the listbox.
because how would the listbox know which word to highlight as you edit
the textbox contents.

im very keen to see this, as the other IDE's/ editors out there do not suit my taste even though they have the drop down feature.
FASMW would be ideal for me with this.

Have you any idea of how much memory it takes to add all words contained in a file as items to a list box? Moreover if the source file is rather long (say, the Fasm core "X86_64.INC" file ).

This would be possible, but would need a lot of dynamical memory and is kinda hard to do, also to add new words which are typed in or inserted.

I have some more feature request, I could also imagine myself on working on them:
-Add a redo feature. That wouldn't too hard to add, since FasmW already has an undo function and a command history buffer.
-The maximum line length should also decrease when the maximum line length shrinks.
(-File history)

Anyway, this topic should be moved to the "IDE Developpment" section.

Code completion is implemented in Fresh already...

MCD i would only like to add the main ones like windows api functions,
especially really common ones like MessageBox and CreateWindowEx and the like.
its just a bit tedious to keep writing them.
but yeh i dont want to add everyword in a file. and although adding new
words dynamically could be good, i dont want that either. both to cut down on memory usage and development time

i mainly like small, quick and simple things, and i like FASMW. its like notepad with source colouring, which is good. but notepad with source colouring and a drop down which i can customise would be better for me.
i have tried several IDE's and they just havent been what im looking for.

decard, i remember trying fresh a while ago and not been too keen on it. i seen the screenshots on the homepage and it does have the drop down but overall its not what im looking for. im not discouraging it, it looks impressive and well done to the author! just too much for what i need.

sorry about the placement in the "windows" section. my mistake, i was unsure.

MCD i like your redo feature so would like to see that.
what is the command history buffer you are on about, i seem to have missed that feature in FASMW but sounds interesting. is it like in command prompt when you press down/up arrows to see previous commands you have entered.

There's no command history buffer in fasmw, the undo buffer just keeps the modified segments of lines and stored editor status, and on "Undo" just restores those segments to their contents one step back. This is universal and doesn't care what operation what actually done


Such feature would need scanning all the lines on such operation (since you don't know how many lines with the maximum length are there at the moment) and would seriosly decrease performance on large files. Also I personally take advantage the feature of the "peak length", like increasing it to get the area inside which I can move with arrows freely. In old editor control (imitating the DN's editor) all lines had the fixed length of 256 characters, and you could move around freely in that area - the new one doesn't impose any limits on the line length, so I had to implement this "peak length" feature, which just traces how many space you needed at most and provides this space for you.

I was a bit wrong. But it would still be quiet easy add a redo feature.


Not really, it would be enough to not only have the maximum line number length, but also at which line this occurs and then just check the line(s) that are actually modified.

Remember there can be more than one line with maximum length. And even if you keep record of all such lines, when the last of them gets edited to be smaller, you will need to make list of all lines with the new, smaller, maximum length. Scanning all the lines cannot be avoided. Well, unless you make some data structure to hold information about all the lines for each possible length, and moving the lines between the blocks when they get edited - but it would be actually simpler to design some other edit control from scratch. And - as I said, this feature actually works like I'd like it to work - well, it was designed to exactly as is.

OK, I was a bit wrong on this one - donkey7 pointed out to me that it would be just enough to hold the count of lines for each length in the table. I tried implementing it in the latest (0.92.7) version of fasmw's interface. Please check it out.

yeah, it works
but sometimes FASMW crashes or dosen't show eding characters in long lines. both issues takes place only on lines of huge (unusual) lengths.
some people are used to set an 'free area' using previous behaviour of asmedit. now it's impossible without adding some long line (maybe comment), so i propose to add an 'minimum_line_length' feature. it would be even more convenient than old control.

Can you find out some how to reproduce the crash?

I'm uploading the 0.92.8 - fixed one critical bug and the "free area" is now always at least filling the whole editor window width - the best of two worlds, in my opinion.

Screen-shot from the download page:

This means that the new version of file was being uploaded - just wait for the upload to finish when you see it. My connection is kind of slow.

the bugs i've written about are still present.
one of them is crashing when pasting repeatedly some string of characters (thus making an huge line). interestingly, fasmw crashes on rather random line lengths, but not less than 240.

i'm using athlon 2200+, 512ram, win98se pl with unofficial service pack and of course latest (0.92.8) version of FASMW editor.

Try the 0.92.9.

for me it shows (w2k sp4 ru)

yep, latest version of FASMW shows entire line (as versions 0.92.6 and below), but still crashes.
i discovered that FASMW crashes only when we are at the end of line and we are pasting an string and current line length is LCM(240,length_of_string_to_paste). (LCM - least common multiply)
then FASMW shows an error (i have polish windows):

Oh, this was an older bug actually (but for older versions the value was 248 instead of 240) - great thanks for finding it out. Please try the latest version - I simplified some of the code and fixed the above problem.

BTW, have you tried using OllyDbg as a JIT (to replace the standard Windows message like above)? I find it really useful.

it seems to be fixed now, but i found one more bug.

fasmw hangs up and crashes when i make some very long line (several dozen thousands of chars). i think that before the crash happens, fasmw allocates huge amounts of memory - just after crash my disk was fullfilled by windows swap file (i had have about 300mb of free disk space) and after a moment swap file was cleaned.

i'm not using any debugger. when my program crash, i run disassembler (actually wdasm) and find where is the problem, then put an int3 instruction in source code and look what windows prints in error message. this may look rather complicated but i usually don't need to debug my program. i'm testing my progams after almost every change so i know what most likely can cause the problem.

Yeah, forgot to check it with such huge lines myself. Again thanks for all the testing. It's fixed now, I hope you won't find much more.

As for debugging, I was also used to the methods similar to yours, especially when debugging things in DOS, where often you couldn't afford any debugger (also under some extenders or with unreal mode the programs simply cannot be debugged). However in Windows I've chosen to use the Ollydbg, because it often saves me switching between programs - I've got the disassembly and the register contents just at the time of crash, if some registers contain pointers, I can go to that memory area immediatelly and analyze some data structures to see better what would have caused the problem, etc.