Compiler Error Display

If reporting a bug with the Zeus IDE please post the details here. Please do not post questions here.
Post Reply
pwdiener
Posts: 134
Joined: Wed Jul 11, 2007 3:45 pm

Compiler Error Display

Post by pwdiener »

Hi, Jussi,

I'm running in to an issue trying to display compiler errors. I'm writing a LUA script to handle the compile of a COBOL program on the AS400. The process is:
1) Submit a compile job to the AS400
2) Wait for it to complete
3) Download the compile listing via FTP
4) Analyze the listing to produce an error file
5) Open the error file in a compiler window to display the results of the compile.

This is all working, but there is a problem with the error display. When I set up a document COMPILE command to just TYPE the error file, everything works perfectly. However, when I use a script and just do a file_open_compiler(<error file>,"Compile",<source file name>), the error displays stop working properly. In this case, it will show the wrong error text at times, indicate that there are no more errors when there are, and some other erratic results. It also works correctly for chunks of the file, then gets off track.

I'm using the error display macros that I wrote, mapped to keys to step forward and backward, which could be the source of the problem. However, it appears to me that the problem is that error_message() is behaving differently when the error file is TYPEd vs. file_open_compiler.

To narrow this down, I wrote a macro that strips out all the other steps and just displays the error file. When I do this, displaying the current error shows an incorrect first error, and error_message() returns a line of --------------- (dashes). When TYPEd as a result of a configured compile command, things work as expected.

I can send you copies of the files, macros, etc. if that will help.

It appears that running the compile command does some setup stuff that allows error_message() to work correctly, where the file_open_compiler executed from a LUA script does not. I am NOT running any kind of compile command in this non-working scenario - just running macros.

Bill Diener
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

I'm using the error display macros that I wrote, mapped to keys to step forward and backward, which could be the source of the problem. However, it appears to me that the problem is that error_message() is behaving differently when the error file is TYPEd vs. file_open_compiler.
This will just be the symptom and not the cause and I suspect there is a bug in the file_open_compiler function.
I can send you copies of the files, macros, etc. if that will help.

That would be good :)

Also how are you calling the file_open_compiler function :?:
It appears that running the compile command does some setup stuff that allows error_message() to work correctly, where the file_open_compiler executed from a LUA script does not. I am NOT running any kind of compile command in this non-working scenario - just running macros.
That it pretty close to the mark. This will be failing because the error window is not being setup correctly by the file_open_compiler function.

Some background. Because different programming languages have different compilers and compiler outputs the compiler output window needs to be setup based on the programming language being used.

So the compiler output window is created using information found in the document type of the compiled document.

Somewhere in this process the file_open_compiler is not doing the correct setup :(

Cheers Jussi
pwdiener
Posts: 134
Joined: Wed Jul 11, 2007 3:45 pm

Post by pwdiener »

I'll send a copy of source, listing, and error files, as well as some saves of the .zerr files showing the (only slightly) different results from using "type" or the file_open_compiler functions.

I'll also include the macro that I'm using, so you can see precisely how I'm calling file_open_compiler, but I am passing the source file name in addition to the error file name.

Files will be zipped and sent to the support email address.

Bill
Post Reply