Hi, here some wishes for the uVision environment: - The shortcut keys storage location should be shown somewhere (so that I can the shortcuts with me to my laptop easily). I think the most easy thing would be, if it would be displayed in the dialog "Edit"-"Configuration" on the page "Shortcut Keys" - (or in the Help file, if you press Help there). - Find-Replace (Search-Replace): The selection should NOT disappear, afer you did a replace in some selected lines (sometimes I want to change several texts in such a selection block, then it is VERY annoying, if I have to renew the selection every time). (Best would be, if also the search-replace window would keep open, until I close it explicitely, as in Visual C). - The status message "Passed the end of the file" should be accompanied with a beep (and it should disappear, if I do anything else than pressing F3 - now it just keeps standing there all the time, and I do not know, it it really passed end of file, or if this is due to some more previous search). - Precompiled headers: The possibility to group the source files into subfolders in the project-tree is very nice. Usually I now use the same subfolder names, which I also use in my source folder. BUT: Unfortunately Precompiled Headers do not work correctly with subfolders. (e. g. I have "#include stm32f4xx.h" at beginning of each source file, and then "pragma hdrstop". This works nicely, if all c files are in one folder. But if I organize them in different subfolders, it does not work any more).
Some more advanced wishes: - F4/ CTRL-F4: It would be VERY nice, if this would work like in Visual C: e. g. if I am in ModuleA.C and keep CTRL fixed and press 3 times F4 (3 is just some example), then for example I would reach ModuleX.C. If then I press CTRL-F4 ONCE, I come back to ModuleA.C. So every CTRL-F4 reorders the CTRL-F4 window list - and with CTRL-F4 once, I always come back to my last module. - It would be very nice, if function/procedure comments in Java style (/** .... */) would be supported, and would be shown in a yellow tooltip window, if I move over a function name. - Of course it would be very very very nice if structure parameter preview would work. If possible, not only after compilation/built (as I know it from some other microcontroller programming systems), but also if I change structures during a programming cycle, best of course also, if I define new structures (as in Visual C or Eclipse). - For precompiled header, it would be nice if there is a configuration possibility "create header through the file xxxx.h" - usually in any large multi-module project, I have one large header file which best should be handled by precompiled header functionality.
Keil does not monitor the user forum
Erik
One further point: - Indent size / tab size: It should be possible to select the indent size (e. g. block indent after { ...) independently from the tab size. I usually use Indent size 2, which I could configure only by setting tab size to 2. But this is quite annoying, if I transfer source code to other editors ... (which usually all have tab size 8). Now I helped by checking "Insert spaces for tabs" - but anyway sometimes I get problems if I transfer code to / from other editors.
... I just want the comments of other users too ... I hope if many enough gather, then they might risk a short look ....
" annoying, if I transfer source code to other editors"
That is precisely why you should never use TABs - always use spaces!
"(which usually all have tab size 8)"
Not true. The interpretation of TABs is entirely application dependent; usually also dependent on how the particular instance of the application happens to have been (mis)configured. It could be absolutely anything - you must never rely on any particular interpretation of TABs.
Again, never use TABs - always use spaces!
Although that's a very odd (but unfortunately quite typical) way of voicing an opinion, because that's really all it is, it is a though that I suggest you seriously bear in mind.
When disk space was a precious resource, using TABs made good sense because it could reduce the size of source files quite nicely. Now disk space is plentiful, there's little (if any) advantage in them being used.
If you choose to use them, then the most import thing to consider is consistency. It is advisable to make sure you, your projects and your co-workers all agree on using the same setting. If you don't then the source files can very quickly become a mess.
Problem with that is that if one project has tab size 4 and another have tab size 8 and a user switches from project 1 to project 2, he also have to change the settings.
Problem with that is that if the user has a general editor, that editor may have files open from different projects at the same time.
"When disk space was a precious resource, using TABs made good sense"
Indeed.
"Now disk space is plentiful, there's little (if any) advantage in them being used"
Indeed. And, as amply demonstrated here, there is very good reason not to use them.
"It is advisable to make sure you, your projects and your co-workers all agree on using the same setting"
Not just advisable - it is essential.
Again, it has been amply demonstrated that the chances of achieving this in practice are small - and the ensuing problems far outwiegh any advantage to using TABs.
"If you don't then the source files can very quickly become a mess"
Not just "can" - they will.
I think you'll find that there are very few cases (although, like this, they might be frequently-recurring cases) where I say, "never" - generally, I say things like "very rarely", "highly unlikely", "(almost) always", etc.
It is my opinion (yes!) that this is a case that warrants "never".
You may, of course, say to that, "rules are made to be broken"...
Note that there isn't even any reason to assume that TABs will be spaced at a fixed interval...
No. Highly advisable, but not essential.
No. It is highly likely that a mess will occur, but it is not inevitable. I have witnessed teams that have managed it before deciding that hard TABs were not best for them.
You might be right or wrong, but you are, like everyone else, entitled to an opinion.
and depend on (set) the editor to convert them to spaces :)
In case anyone doesn't realise, "not using TABs" does not mean "not using the 'Tab' key" !!
"using"
... among other that does not come to mind to
(be able to specify that) files with warnings would recompile.
when you (like me) have 100+ files in a build and spot 1 warning after a total build, it is a major scrolling excersice to find the file with the warning.
eRIK
I like that suggestion, having been troubled by the situation before. Maybe a pop-up or something to skip the good and only report the bad.