Please don't use local attachments. Storage for the forum is limited and attachments get removed at random!
I am sorry, I was not aware of that fact. Maybe you better deactivate uploads if you prefer your users not to upload anything. (I mean it literally, ironic as it may sound - no misunderstandings again just because I use explicit instead of euphemistic language, please.) I have no intention of spamming your forum. As you can see I did not post full-sized screenshots but cut out the relevant parts and decreased the colour depth to 8 bit. The files are numerous, but really small.
It seems that I can reproduce your bug.
Cool, thank you. I will wait for the fix and then be happy to test it for you with my setup. :-)
Set the build command to 'xmessage -buttons "test" -center " tead" ' (build options->target->make commands->build project/target)
and then switching the log mode to something different than full log.
No change in behaviour: The command is only called for full log.
This is pretty strange, but calling it "quite buggy" is harsh, in fact this could be regarded as feature, because using anything that full log is asking for trouble. In fact I'll be ok/happy if we just remove the other two modes
I guess that is a matter of perspective. I wonder how anyone could regard it a feature that custom commands are not executed with the default log options, but are with another setting. Please do not be angry at me if I say that, but if your default mode - which I think is really nice and useful except for the fact that it does not work at the moment (but this can easily be fixed, no problem) - does not work and you think it calls for trouble, why does that mode (a) exist at all and why is it (b) the default? No, please do not remove something useful, just do not be annoyed if your users find bugs and try to help you spot and fix them. This is part of the normal software lifecycle. I was just wondering why I was the first user finding that bug because it is so obvious. I guess that 99% of your users do not use external makefiles, but the internal build system, which makes sense for self-developed software. But as I said, I just want to patch and debug a piece of standard software with a set of existing, complex makefiles which I have no intention of changing. I was just adding a new MC featue (ash/dash subshell support + two bugfixes for existing subshells) and thought it would be a nice test for C::B's debugging front-end to test MC in C::B. Actually, I have not gotten that far just yet because I am discussing this issue here with you, but I think it is well worth the time to improve a product which obviously many other users are satisfied with.
When I was calling C::B useless, I meant it was useless for my specific use case, not all in all and for many other use cases. My remark had a
context. So no, I will not accept answers like the one by MortenMacFly. There is no reason to feel insulted just because a user puts his finger into a wound, i.e. he reports bugs.
An IDE has three main use cases: edit code, build, debug. The second one was not working for me, so maybe you understand that in this context the program was useless for me. But now I know a workaround and am confident that the bug(s) will soon be fixed, so I will hang on and continue using C::B. Quality of software is one criterion for me to use software, quality of customer service another one. We had a bad start, but I guess now we are getting closer to finding a solution for the technical problems I detected in your product. This is fine with me.
Good to hear that calling sudo works, but what I wanted to say, is that it is not guaranteed to work in any cases.
Why should it not? It is a subprocess like any other, too. The GUI dialog is the only way to enter the password because your console is not a real tty. This is exactly what SUDO_ASKPASS was invented for and it works with each editor or IDE I know. As I said, it is independent from or orthogonal to C::B.
Alternatively you can use my repo (see my sig), if the bug is fixed and I uploaded a new version.
Thanks for your kind invitation, I am going to accept it. If you help me by fixing a bug, I will help you with testing and feedback. That's the deal. As we say in Germany: One hand washes the other one.
The counting of warnings and errors works here in all cases. (...) If you use localized versions of gcc, it might break the regexes, in this case you have to fix it yourself, because we can not provide regexes for each and any probable localization. Or switch to engish, while compiling ( I have set LC_ALL to en_US.UTF-8 in my environment variables inside C::B).
Yes, that must be it. I did not know that English was the only language supported by C::B, but on second thought, the menu is in English, so I could have concluded from that. I will just use LANG=C (I am on ISO-8859-15 here, not UTF-8, because I often develop for an embedded system with a cross-compiler, and the target system only supports latin1 character set). A quick test shows that the warning is interpreted correctly then.
Some ideas for improvement:
- If make returns with exit code 0 (zero), it would be smart to assume that there were warnings, but no errors, otherwise the exit code would be !=0.
- If you know that you only support the English version of make, maybe you could set the environment (LC_ALL or whatever is appropriate) as necessary by yourself , so you are in control of how you parse make's output. This is what my shell scripts with regexes do if I know they only work for English.
As for your suggestion to post bug reports at BerliOS, you can be sure I will do that next time. You are 100% right that if there is a ticket system, it should be used. When I was first posting here I was just not sure if as a newbie I should ring the alarm right away or first try to get some feedback in a user forum. I decided to do the latter and am sorry if this was the wrong place. I usually (not always) try first to ask experienced co-users before I consume precious developer time. But when I am sure that what I consider a bug really is one, I create tickets. If you like to have one for reference, I can do that anyway.
about the lower- and upper case-stuff: environment-variables and user-defined fields in global variables are totally different. The later are not case-sensitive.
Sorry to say that, but if a menu option is called "Global variables" and the dialogue title is "Global variable editor" and it even works to use a global variable as an environment variable (no matter if it is printed in lower-case when I re-open the dialogue), it is kind of counter-intuitive to assume there is a difference. I have to admit though, that if I had
RTFM I probably should have known. Mea culpa. So now that I know it, I will use "Build options" - "Custom variables" which hopefully is the right place. But as it is project-specific and I wanted to set the variable for all projects once and for all, I (falsely) figured that "Global variables" was the right place. BTW, is there a way to set my variable globally for C::B (other than doing it before calling C::B, I mean).