If CodeBench thinks the buildscript is stale, then it will prompt you to remake it. Adding or removing files from the project will trigger this action. Once the buildscript is no longer stale, it shouldn't ask again. Can you give me some more detailed steps to try and recreate this, I may have missed something
I was clicking "no" instead of "ignore." This is due to the warning about losing project settings, so I erred on the safe side. It would be better if it didn't ask to rebuild the makescript when the user supplies their own custom one.
So, in that case, and files are added or removed from the project, how would you prefer the system continues? Should it just ignore it and let you get on with it on your own?
Quote:
Disabling that will disable confirmation when I do a "save as" as well. I was hoping to not get a requester when I save a file over its own original, but to still ask for a confirmation when overwriting a different file.
Well, I don't really know what to suggest with this, short of making the "Save As" function always confirm...
Quote:
BTW, I just found one other problem. I don't have my makefile in the base directory of the project (there's a reason for this), and so some project files are in a higher directory. Performing a "save as" on these leaves the "/" in front of the file-name, which of-course won't save. It's no big deal, since one can easily delete that character, but it would be better if it weren't there.
I think a touch more clarity in this would help me to understand what you are doing.
These are all something I intend to do, but I need to stabilise what I have first. This may very well come in an update, but not just yet.
Again nice to hear
Quote:
Quote:
Fully Redefinable Keyboard,
The gadget key bindings are user definable from the Prefs
Sorry bit lost here, how to i define multiple key combinations perform the same action - e.g. 'Ctrl' + 'X' cuts and 'Ramiga'' + 'X' cuts and just for the sake of it F1 cuts.
Quote:
Quote:
Printing,
Should be trivial
Well hopefully this will be in the next release then
Quote:
Quote:
Unicode Support,
Is there any real point in supporting charsets that extend the ASCII standard? Can those characters actually be used in C code?
In my opinion yes, as I need to be able to edit resource files, documentation etc.. I don't want to have to go to another computer to do this. I appreciate that this is not a high priority and how difficult it is to implement due to the complete lack of support for Unicode within the OS.
Quote:
Quote:
Version Control
There is already code in place for this, but until I get it working exactly as I want I'm not enabling it. I doubt it would go into the "free" version anyway.
Again nice to hear
Quote:
Quote:
and a GUI driven Debugger.
Well, writing a gui for GDB is one thing, but as we have already discussed, GDB is an outdated elephant. I plan to write my own ELF debugging system, but that certainly is not going to happen anytime soon.
Simon
Personally, I don't care whether a debugger sits on top of gdb or not, provided it works. I totally agree with you, gdb is an elephant, it's difficult to work with, arcane and i hate it too but hey it works. I'm glad that you are still planning a native debugger, it's sorely needed.
I can't really see the point in this. Perhaps in the future, this might have more value, but certainly not now.
This is very useful, users can then configure shortcuts for commands that aren't implemented natively by the editor - find matching braces, select between matching brackets, insert function description template etc. etc.
Personally I use a lot of macros to speed up my development work, Maybe that's just me.
I don't know if CodeBench overrides it, but by default richeditor uses:
env:classes/gadgets/richeditor/default.kbd
for keybindings. Its a straightforward XML file, and you can define multiple bindings to one action. If you change it, remember to copy it to envarc: to make it permanent.
But as I said, I don't know if CodeBench uses this file or overrides it with interal bindings.
I found the file that CodeBench is using and edited that instead
Sadly it didn't work - My new Ctrl Z is recognised as being the Undo command in the KeyBindings preferences but this doesn't work in the editor. RAmiga U still works but loses the focus.
I was clicking "no" instead of "ignore." This is due to the warning about losing project settings, so I erred on the safe side. It would be better if it didn't ask to rebuild the makescript when the user supplies their own custom one.
So, in that case, and files are added or removed from the project, how would you prefer the system continues? Should it just ignore it and let you get on with it on your own?
Yes, that's what I would prefer. Basically, if I'm using a custom makefile instead of a Codebench generated makefile, then I don't want Codebench to offer to rebuild it. I'll take care of that myself.
Quote:
Quote:
Disabling that will disable confirmation when I do a "save as" as well. I was hoping to not get a requester when I save a file over its own original, but to still ask for a confirmation when overwriting a different file.
Well, I don't really know what to suggest with this, short of making the "Save As" function always confirm...
That's what most programs seem to do. The other option would be to check if the file's path and the save as path match.
Quote:
Quote:
BTW, I just found one other problem. I don't have my makefile in the base directory of the project (there's a reason for this), and so some project files are in a higher directory. Performing a "save as" on these leaves the "/" in front of the file-name, which of-course won't save. It's no big deal, since one can easily delete that character, but it would be better if it weren't there.
I think a touch more clarity in this would help me to understand what you are doing.
I have my makefile in a sub-directory, not the main directory. This is often done when a project is cross-platform and you're using different directories for different platforms, e.g., project/AmigaOS/Project.cbp project/AmigaOS/makefile project/Linux/ project/main.c (or maybe the c files are in a sub-directory such as "project/src/")
I put the project file in the same directory as the makefile (the makefile expects the working directory to be the one that it's in, not the project base). Thus, I'm referencing files with relative paths, e.g., "/main.c" Right now, a save-as will list the file as "/main.c" instead of "main.c". With files in other directories it also puts the whole relative file path into the save as requester's filename box.
Own screen or not, the prefs window opens below the editor window most of the times.
Btw, when using its own screen in 8 and 16 bit screenmode the editor becomes creepingly slow, any idea what might cause this? (My WB is 32bit)
On my setup the editor sometimes scrolls everything one character to the left every time I type a letter, which is somewhat annoying. If I turn the line number off and on again the behavior disappears.
Hmm... the creeping slowness could be related to the fact that the editor currently refreshes the whole display, even if it just scrolls. The render function can render subsections of the display, though, so once the functionality of the editor stabilises and the bugs are squashed, the optimisation phase will kick in and i'll fix that.
I was going to suggest that the use of RPTAG_APenColor would cause the slowness on 8bit screens, but then i remembered it falls back to pens anyway
Edit: Oh, and i've already fixed the scrolling oddness.
- Mark some text spanning more than one line. - Press a non blank character. - Not all of the originally marked text disappears, a portion of it remains.