Hi Ketil,
I have some suggestions for RadASM (& some problems with it):

1- Each time I upgrade to a newer version, I have to add my own keywords (my own structures for ex.) in the Colors & Keywords dialog, I also have to edit the .ini files to set for example editor colors.
So I suggest separating user-defined keywords, preferences, ... in separate files for example.
2- 'public' keyword appears as an argument in procedures' arg list tooltip.
3- 'uses' keyword is not highlited (Just for completness ;-) )
4- Waiting for supporting text moving using cursor in the code editor...
Posted on 2004-02-28 04:17:11 by John Kiro
Hi John Kiro

1. Normally, when you update, just keep the old ini files. Release notes will tell you how to manually update the ini files.
2. Thanks, will be fixed.
3. Will be added.
4. I hate COM, if I ever get it working.

Posted on 2004-02-28 15:43:25 by KetilO
@John Kiro:
Your point 1: own structures, function calls, constants etc.
Maybe you've the same idea then me: be able to include userdefined files in .API format

I've created many static and dynamic lib's in the past, which wheren't default part of Masm or Windows (GFX-handling / Music / operating system / PE related....)

At the moment, i've four additional files for them which needs to become imported to .API files in order to use them.

Possible to realize such an idea?
Posted on 2004-02-28 16:31:29 by cu.Pegasus
Hi all,

just to sound off on user defined API files. I agree that they should be available. Maybe add files like userApiStruct.api/userApiConst.api etc.. in the same folder as the API files for each assembler and RadASM merges them into the API files when loading them. That would also have the advantage of offloading them from the INI file and let the INI files be updated a little easier.
Posted on 2004-02-28 20:25:12 by donkey
Hi again,
Yes, user-defined API (funs, structs,...) should be the most important part of something like a "programmer profile". (I forgot to request it above).
I discovered/forgot 2 other things:

5- Expanding a block would better, I see, keep its nested blocks collapsed. => I can navigate code level-by-level easier.
6- A problem with brackets [], but I see fixed in ver
Posted on 2004-02-29 03:13:31 by John Kiro