Best IDE Features: Template Management Procedure/Macro Browser Potential Error Detection (IE Win2k Probs) Real-Time Error Detection While Coding Integrated Resource Editor COM and/or Unicode Support Excellent Integrated Help Talking Paperclip to help you with everything you in :D Be honest :p _Shawn
Posted on 2001-02-26 16:12:00 by _Shawn
Funny you put COM support in there for your ideal IDE. I've got COM support in Quick Editor. Unicode too for that matter. No kidding. :-)
Posted on 2001-02-26 23:01:00 by Ernie
last time that paperclip made me coffee :D it's the greatest invention since they invented DOS :P my stress feature would be Intellisense. That's the most important feature for me (more important then a form designer)
Posted on 2001-02-27 00:44:00 by Hiroshimator
What exactly does the realm of intellisense include? I'm not sure I'm quite on track with that... - Ben
Posted on 2001-02-27 00:49:00 by cyberben
Example: as soon as you type "invoke MessageBox", a small window pops up, showing what parms MessageBox takes. The parameter you're about to type (ie, at first HWND), is written in bold. Another thing intellisense allows you is to type in a partial function/variable/macro name and hit ctrl-space, and it completes the word - if there's multiple matches, these are shown in a window you can pick from. This means the IDE would have to parse the asm source file, and keep a symbol list, including types and so on. If you implement this, you shouldn't put the defines for common stuff (ie, MessageBox) directly in the executable. Either parse it from the include files (ick! Probably generate a "quickload" file that is only rebuilt when some of the files change, since parsing all include files on every project load could turn out a slow process), or you could have a text file with the definitions. I prefer the parse-include-files.
Posted on 2001-02-27 03:29:00 by f0dder
f0dder: Don't forget the structure members ;) Ben: In terms of implementation, Intellisense is difficult to implement. In short, you have to create namespaces for
  • Functions
  • Macros
  • Structures
  • with their parameters AND meanings of each parameter. You can't just parse the include files because functions/macros/structures can be defined in the current source file. You must also load the namespaces with their info into memory for quick reference: it won't do to parse every file whenever a user types a character into the editor.
    Posted on 2001-02-27 06:05:00 by Iczelion
    Ah yes, forget about structure members :). You *can* parse the include files (of course you also have to parse the main file). Hm. Should a namespace list be kept for each file, or for the project? Per-file is a bit overkill, imho. And of course you have to keep the list in memory :). My idea was that the namespace list should include a list of which files were used to gather the information from, including file timestamps. Whenever you load the project, and the already-parsed binary and easy and quick to load namespace list, all filestamps are checked with the "precompiled" list; if any difference, everything is re-hashed. Sure, intellisense might prove a "bit" hard to implement, but I believe it's worth it. Increases productivity, no matter what hutch thinks.
    Posted on 2001-02-27 06:40:00 by f0dder
    Having read the discussion on .NET and the future of MASM I think it might be wise you allow it to use any assembler it likes, I know it sounds obvious, but I like the "double-click the error to go to it" functionality of VC++ which I use to develop asm in now, and you'd have to be able to do that for all assemblers. (and I wanted to see if I could link messages together on the board!) umbongo
    Posted on 2001-02-27 07:18:00 by umbongo
    Given what you have to do with intelisense - color-highlighting seems trival. It could be done on the back end of the code for intelisense. As well as many types of error checking. bitRAKE
    Posted on 2001-02-27 09:02:00 by bitRAKE
    Well, Intellisense for assembly is a lot easier than implementing it for say, c++... here's how my IDE does it (er, will do it)... for the include files that more than one asm file share, it keeps a type of symbol table in a memory space that all (mdi) children can access, since potentially, they all may need them... then, there is another one that is relevent only the the includes of a particular asm file... then, if there are externs or resource files, those are also kept in the same list. It actually only takes about <1 second to parse over 200 inc files and do the list... then while typing, it's lightning quick. By the way, does MASM support enumerations? Or is it just TASM? How would I achieve it in MASM without seperately equ'ing each constant? _Shawn
    Posted on 2001-02-27 10:34:00 by _Shawn
    Shawn, I have had the same question reguarding enumeration in MASM. For those who don't know intellisense also allows you to select from a dropdown of enumerations for an item of a certain type. For me there are two types of enumeration. First, there are those like message types (ex, 0, 1, 2, 3, 4, 5, etc.) Then, there are those that are like bit masks (ex. 1, 2, 4, 8, 16, etc.) Intellisense should allow you to specify multiple ones of the second type added/ORed together, and even allow common names for multi-bit types (ex. see the window types). If MASM doesn't allow me to do this, I was thinking of making COM wrappers for API definition files. They would only be used for internal definitions of interface - which would have to be in sync with the includes and libs. They could also link to help (.hlp, .chm or web pages) I'm still taking notes :P bitRAKE This message was edited by bitRAKE, on 2/27/2001 2:24:59 PM
    Posted on 2001-02-27 11:04:00 by bitRAKE
    I am yet to see a better system than direct F1 connection to a help file. One of the suggestions I liked was made by The Svin where you allow a number of key combinations to bring up a range of different help files. Shift F1 Ctrl F1 Alt F1 So its easy enough to impliment a number of direct and fast help files while you are coding. It really depends on whether a programmer want all of the clutter while coding. Done in the form of Intellisense, you may need to produce API, Opcode, MASM syntax, algo design and a whole range of info that would almost cover the screen. The approach I have taken is to produce help files and have the capacity to place them on the help menu so that the programmer has a wide choice and fast access to the information that they require. Another approach is the small source browser that is set up to open a particular directory that the programmer can fill with their own choice of procedures and algos. Making libraries is yet another way to inprove the coding throughput. There is finally no substitute for having to learn a substantial body of information to code assembler, while it is both possible and viable to have large quantities of useful information available to the programmer, chasing after the current gimmick does not add to the improvement in knowledge required to code 32 bit assembler in Windows, rather it makes a newer user dependent on a particular IDE that has gimmicks of this type. Something that is forgotten by many is that comercial language IDEs is programmed by a large team of programmers over a long period and it is always for commercial interests like SELLING a new programming environment and creating dependence on a commercial product. I suggest what is needed for assembler programmers who want larger and more complex environments is a professional approach to IDE design that does not assume the incompetence of the programmer. Scalable architecture in assembler is necessary because of the range of sizes of asm programs. Some still code with all of their code and prototypes in one file, others write multi-file style programs in the way that MASM32 does, large scale architecture uses response files and libraries, some use the old NMAKE. The modern IDE concept usually restricts the programmer to one option so that they have to learn the IDE first, not how to program in assaembler. Much of the reaction to modern programming is based around the dislike by many programmers of being restricted to "method" and the notion of "one way" of doing things. Duplicating this in assembler is a formula for failure. Regards,
    Posted on 2001-02-27 19:32:00 by hutch--
    I don't know if providing many ways of doing the same thing is a formula for failure. The trick is to provide that without the user being aware of it - no matter what the skill level. Which in assembler is hard. Options like changing the RC or ASM file, and having the GUI builder and project files updated. Being able to see the code being assembled as each line is typed would be awesome as well. Total interactivity! Being able to see as much or as little information as your want - at least that is my dream :P Most programming languages in general are redundant to allow for everyone to create there own style - yet still be understood. This redundancy certainly should exist at the IDE level. Just $0.02 worth :P bitRAKE
    Posted on 2001-02-27 21:50:00 by bitRAKE
    I have to disagree with hutch, and I hate disagreeing with him because his work has been so damn useful to me. Anyway, as I make my code in quick editor, I find myself running off to other programs for 2 main things: API parameters and constants, and my own structure members. It is not ususual for me to have a seccond instance of QE open with the same file in it, but positioned to the .data area where my structures are defined (so I can copy member names correctly). And I ALWAYS have MSDN open (it's a .chm help file on my hard drive) to look up API's. I can't tell you how many times a compilation of mine has failed because I typed "GetWindowsLong" Most any implimentation of intellesense would fix the latter... even if it takes it a few secs to locate the command I'm working on (no loss of coding time, as this would happen on a seperate thread)... and would could pop up with the answer long before I've copied and pasted my API name into the INDEX edit box of MSDN. I'd sure love to see a list of params pop up (if I get it, I know I at least SPELT IT RIGHT), and most times a param name is all the hint I need. Browse files for my own structures (and whatever else people find essential to know) can be great time savers too. Basically, it's just a case of automating the information merge done while actively coding. The average CPU spends 99% of it's cycles basically executing NOPs anyway, let's put a few of them to better use.
    Posted on 2001-02-27 23:42:00 by Ernie
    I also vote for Intellisense. hutch: Even if I can switch to actual help files, the action itself interrupts the continuity of coding. For experienced coders, they are already familiar with the use of functions/structures and the meanings of their parameters: however, I doubt they can remember all the parameters of all the functions. Intellisense surely cannot replace help files but it is priceless as a quick reminder. Furthermore, it "brings" the help to the user, not the other way around: customer focus ;)
    Posted on 2001-02-28 01:34:00 by Iczelion
    Well, the best help system is the one where I can press F1 over an assembly keyword, and it will give me info about the mneumonic. An even better help system is the one where depending on whether .586 or .586p or something, it will bring me to even more specific information (if any) on the keyword. Even better than that, one that I can press Shift-F1 and it will bring me to a tutorial that directly involves some kind of context in which I'm trying to achieve in code at that point. Perhpas ctrl-F1 can slightly analyse my code block before it goes into help, and then decide if it can better be optimized (IE branch prediction and loop optimization) and take me to some help on that particular topic. Perhaps this is all just dreaming, but I'll tell ya, without adequate help, the value won't be as high as one with adequate help. Another thing to consider, is allowing for 3rd party help integration also, if someone writes their own library or asm files or whatever. Even yourself, so you can F1 your own functions... Just a thought _Shawn
    Posted on 2001-03-01 12:05:00 by _Shawn
    I cast my vote for "Excellent Integrated Help" as it makes sense to address the enormous body of information needed to code 32 bit windows and in assembler. As far as the talking paperclip and any other idea that adds to the gaggle of junk on the screen that gets in the road of coding quickly, if you really want to impliment some version of Intellisense, it will need to loaded in memory and available fast and this will need a tree lookup system to reduce the search time. As far as fast and easily available help, the small editor that is supplied with MASM32, qeditor can handle up to 500 menu entries in the configurable menus and this type of capacity needs to be available in any attempt to build a viable IDE. This technology can easily handle both Winhelp and CHM style help. What is needed is more help files, I supply what I can and they are very time consuming to make in a form that is useful, I prefer Winhelp format because it is a lot faster and can be easily set up to respond to keywords derived from within the editor. Any other toys that make more information available to the programmer is worth having but it must be done in a non-intrusive way or it becomes as annoying as the gaggle of junk present while coding Visual Basic. Mine is a personal choice but I code with a window set to full screen so I can see more of the code that I am working on. I do not like intrusive junk getting in the road while I am working on algos but I prefer to have as much information as possible available when I need it. Regards,
    Posted on 2001-03-01 18:07:00 by hutch--