Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
174 user(s) are online (126 user(s) are browsing Forums)

Members: 3
Guests: 171

trixie, kas1e, imagodespira, more...

Support us!

Headlines

 
  Register To Post  

« 1 2 3 (4)
Re: Problems with 0.8 beta
Supreme Council
Supreme Council


See User information
@Hans

Quote:

Quote:

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.

Simon

Go to top
Re: Codebench: Problems with 0.8 beta
Supreme Council
Supreme Council


See User information
@Menthos

OK, I'm guessing this is tied in with the clipboard.device bug. I have a plan, so bear with me...

Simon

Go to top
Re: Problems with 0.8 beta
Just popping in
Just popping in


See User information
@Rigo

Quote:

As Pete has already stated, folding can be added to the gadget with relative ease.

I await the next version. Hopefully folding will be present.

Quote:

Quote:

Popup hints,
Autocomplete,
Integrated Help,
Popup Bookmarks,


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.

Go to top
Re: Problems with 0.8 beta
Just popping in
Just popping in


See User information
@Rigo

Quote:

Rigo wrote:
@madmonkey

Quote:

Macros,


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.

Go to top
Re: Problems with 0.8 beta
Not too shy to talk
Not too shy to talk


See User information
@madmonkey

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.

Go to top
Re: Problems with 0.8 beta
Supreme Council
Supreme Council


See User information
@xeron

Yes, it does define a different key binding file. This way you are not stuck with the same bindings for all applications.

The Preferences section does include an editor for this, which I may expand to allow multiple bindings for each action...

Simon

Go to top
Re: Problems with 0.8 beta
Just popping in
Just popping in


See User information
@xeron

Thanks for the info

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.

Go to top
Re: Problems with 0.8 beta
Home away from home
Home away from home


See User information
@Rigo

Quote:

Rigo wrote:
@Hans

Quote:

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.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work
Go to top
Re: Problems with 0.8 beta
Quite a regular
Quite a regular


See User information
@all

slightly OT

I have not had a chance to download the new SDK yet. It's a few days now, each time I have the opportunity to go online the site is down.

Still you can enter the username and password but mine are not recognized anymore. Someone at Hyperion Please? :)

Go to top
Re: Problems with 0.8 beta
Just popping in
Just popping in


See User information
@Amigo1

You are probably trying to access the web site, which has been down for quite some time.

The SDK is on the ftp site. Try ftp://hyperion-entertainment.biz/SDK

Go to top
Re: Problems with 0.8 beta
Quite a regular
Quite a regular


See User information
@madmonkey

thanks mate! :)

Go to top
Re: Problems with 0.8 beta
Supreme Council
Supreme Council


See User information
@Rigo

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.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Problems with 0.8 beta
Not too shy to talk
Not too shy to talk


See User information
@orgin

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.

Go to top
Re: Problems with 0.8 beta
Supreme Council
Supreme Council


See User information
@xeron

Okey. Hmm, another one:

- 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.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: Problems with 0.8 beta
Supreme Council
Supreme Council


See User information
@orgin

Quote:

Own screen or not, the prefs window opens below the editor window most of the times.


I don't understand why that happens, it doesn't here, but I'll add some code to ensure the prefs window is at the front.

Pete has already made some changes to the editor gadget, so I expect most oddities to be fixed with the next version.

Simon

Go to top
Re: Problems with 0.8 beta
Supreme Council
Supreme Council


See User information
@orgin

Quote:

- 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.


Yes, this is known about (at least by me), and is evident when the start of the marked block is not column 0.

I have been meaning to report this to Pete, so I hope he sees this :)

Simon

Go to top
Re: Problems with 0.8 beta
Not too shy to talk
Not too shy to talk


See User information
@orgin

Quote:

- 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.


Fixed :)

Go to top

  Register To Post
« 1 2 3 (4)

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project