Hello,

is it possible to see the actual generated source after a script have been compiled ?



Nick LeWe


(still trying to found out actually what happens when the print.data command is fired)

Hello Nicklewe,

You can manually compile some source using the compiler bic6.X.

I've done this once many many years ago and don't recall the proper option.

Good Luck

I do not know of anyway you can look at the generated or compiled code. I have not seen or heard of any tools that would show you the code. You can use bic_info to get some info from the object, but I do not think it will show you what you are looking for.

Good Luck!

Mark

ok thanks guys

Nick

Nick,

You can try to explore more using the $BSE/bin/bic6.2 -?


>bic6.2 -?
bic6.2: illegal option ?
Baan International Compiler (c)

Usage: bic6.2 [-ilpstzEV] [-u[level] -f fn] [-w[level]] [-Idir[:dir ...] [-Dmac]

-i: Assembler output in <source>.i
-l: Object runs in debug mode
-p: Object runs in profiling mode(time analyse)
-pacc pack_comb: Use specified package combination
-s: Generate symbol table to stdout
-t: Print tokens after preprocessor pass
-u[l]: Create 'where used' list [for level l]
-f fn: File name for 'where used' output file.
-z: Ignore the BAAN_SCM_GRP
-E: Only preprocessor pass output to stdout
-w[l]: Suppress warnings of level <l>
-W[l]: Give warnings of level <l>
-d dll:Load dll[:dll ...] for search lib.functions
-Idir: Add dir[:dir ...] to searchpath #include <>
-Ddef: define a macro. Or with value -Ddef[=value]
-qo fn: Redirect standard output to file fn
-qe fn: Redirect error output to file fn
-6: Generate 6.1 object format
-7: Generate 7.2 object format
-V: Print release number
>


You can also use the bic_info or ttstpobjinfo, or ttstpbaandoc to look at the object info.

You can find some entries there like -


--------------------------------------------------------------------------------
DLL Prototypes
--------------------------------------------------------------------------------
function extern on.choice.print.data()

on.choice.print.data
rprt_open (Hint: Located in DLL: ottstp_stddll)
start.process
rprt_close (Hint: Located in DLL: ottstp_stddll)

As far as I know, you cannot see the standard program run, or the standard program source. So you can see some things when you compile your program in debugger, but not what the standard program is doing underneath.

However, when you compile the reports with debugger, this is a different matter. You can see the standard report script running through the debugger.

Not sure what you are trying to see, but that may be of interest.

Nick,

For a simple UI script: before it is compiled it is preprocessed by std_gen (std_gen6.1/std_gen6.2/std_gen). This preprocessor doesn't do a lot: it only converts the sections to functions.
For example:

choice.end.program:
before.choice:
code

field.xxxx:
before.zoom:
attr.zoomcode = x


is converted to :

function extern void before.choice.end.program()
{
code
}

function extern void before.zoom.xxxx()
{
attr.zoomcode = x
}


You see, this is not very interesting. Under certain conditions, you can see this preprocessed code when you compile a UI script in debug.

These functions are called by the 4GL-Engine. The 4GL-Engine is a DLL that is linked to all compiled UI-scripts. So you cannot see the code of it.

In old version (before Baan IV), there were no DLL's. These were the glory days of std_gen: it merged the sources of the 4GL-Engine (then known as 'standard program') with the UI script (then known as program script), before it was compiled.

The reports still work in a similar way: first a script is generated (this is done by repgen) from the report layouts, the input fields and the report script. And this generated script is compiled to an object. Here you can see the generated script if you compile it with debugger.

To give a short answer to your question: The generated code is not much different from the code you entered, so you're probably not interested. The real trick is in the code of the 4GL-Engine, which will not become visible by compiling it in debug: you only have the compiled object installed.

Regards,
Jaap Zwaan

one more hint to add:
If you are in the debugger (and you have a Unix server? - I am not sure what NT will do), you can press vi instead of c(ontinue) to start an editor instance (vi) where you can write the debugged code out to file (w!file.name). Do not forget to do the same for the includes when you enter them...

OmeLuuk,

i typed vi on the debugger and nothing happened. im in Unix. is there anything else i should do?

one more hint to add:
If you are in the debugger (and you have a Unix server? - I am not sure what NT will do), you can press vi instead of c(ontinue) to start an editor instance (vi) where you can write the debugged code out to file (w!file.name). Do not forget to do the same for the includes when you enter them...

Typing vi and hitting return started vi for me. Does vi work from a prompt for you? Just wondering if it is not in your path.

Mark, in the command prompt it did not start vi when i type it. Will this mean i should have a local vi in the client?

No - the only vi I have is on the server. It is in my path. All I did was type vi, hit enter and the script popped up.

mark, which path should i put the vi. would you mind showing me how your path looks like? muchas gracias.

See enclosed jpg.