Hello,

I'm trying to figure out why a single error is split across more than one message callback during build, as an example:

namespace Test
{
    class Main
    {
        t
    }
}

produces 4 message callbacks:

1: Expected method or property

2: Instead found 't'

3: Unexpected end of file

4: While parsing namespace

I'm storing the errors in a vector as they're coming in and placing them into a list control and its looking weird with 2 errors producing 4 items in the list.

Is there a way to prevent this behaviour or perhaps find a way to combine error messages that link to the same error?

Thanks,

Oh okay I see, no it doesn't really matter that much, I just thought I may have been doing something wrong that was causing it.

Thanks for the response Andreas!

How ive seen it done in most compilers, is showing the error as one and then have a foldout to show the individual problems. Because many times the first one is not very informative. Also like how vsc++ does it is they have the output window (which has all the information warnings bugs compiler messages, status messages etc) and then they have error list (with the errors and warnings which can be sorted in a variety of ways). This is how i would handle it.

chasester

How ive seen it done in most compilers, is showing the error as one and then have a foldout to show the individual problems. Because many times the first one is not very informative. Also like how vsc++ does it is they have the output window (which has all the information warnings bugs compiler messages, status messages etc) and then they have error list (with the errors and warnings which can be sorted in a variety of ways). This is how i would handle it.

Isn't that the IDE's responsibility? For example, GCC outputs multiple messages just like the example above, and QtCreator (the IDE) gets to decide how to display them. In your case, Microsoft's compiler (which has no GUI) outputs multiple messages and Microsoft's IDE (Visual Studio) is responsible for displaying it in a friendly manner.

AngelScript is the non-GUI compiler part (like GCC and Microsoft's compiler), and it's up to the caller to decide how to display that info (like QtCreator and Visual Studio). By providing more details (like different fragments of errors pointing at different lines) it gives more power and flexibility to the IDEs to decide what they want to display, and how they want to display it.

How ive seen it done in most compilers, is showing the error as one and then have a foldout to show the individual problems. Because many times the first one is not very informative. Also like how vsc++ does it is they have the output window (which has all the information warnings bugs compiler messages, status messages etc) and then they have error list (with the errors and warnings which can be sorted in a variety of ways). This is how i would handle it.

Isn't that the IDE's responsibility?

i just figured you where writing an IDE for your game/editor. How you handle call back response is really up to you. Saying you are releasing (what ever) soley as a game then there would be no need for an IDE (unless you really hate trying to figure out whats going on). But if you want to make it modible or you are releasing it as more of a game/engine, then I think a friendly IDE would definitely help with any kind of user made code. But of course its not a "requirement" my any standard.

chasester