Frame Issue When Compiling In Batch Mode


New Member
When I compile a screen program in client session started by mpro. It works fine.

Where as if I compile from _progres -b or mbpro session it gives a warning and doesn't create .r.

** Warning: Cannot fit FILL-IN Applicant with AT within FRAME F1. (4027)
Warning: Ignoring position info for AT (2054)
**BROWSE B1_APP will not fit in FRAME F1_APP in PROGRAM /home/XXX.p. (4028)

Please advice. Also Why does progress has to check the frame and format when compiling. Shouldn't it be run time?


New Member
Agree that static objects will be resolved at compile time. From the perspective of Frames and display does it makes more sense to resolve at run time?

What if I compile a program in a non batch mode and use that .r to run in a batch mode. Vice versa is my scenario .
It doesn't really matter if we think that FRAME and DISPLAY "ought" to be dynamic. As far as the language is concerned they are NOT.

I must be getting old ;)

You /can/ write code with dynamic frames. For instance, ProTop's lib/dynscreen.p lays out all of the screen widgets dynamically.


Well-Known Member
Don't get me wrong. It does not help to think about whether it makes sense or not. It has been that way since the beginning of the ABL in the 1980. But, as Tom already mentioned, beginning with V9 Progress has added dynamic handle-based objects to the language that you can create at runtime - hence these are resolved at runtime and the compiler does not bother with them.

There are pros and cons to the static approach. One pro is that you don't need to manage the static objects - the AVM does that for you and that way you don't need to deal with potential memory leaks. Whereas, with dynamic handle-based objects it is up to you to manage them and you need to make sure that you are not generating memory leaks.

For your requirement it might make sense to use dynamic frames instead.


New Member
Application that I work on is old and the thousands of programs already have the static frames. For the tool need of compiling the programs in the background it doesn't make sense to change the application programs.

Is there are any other way in a batch session, we can compile the bunch programs using static frames ?



Well-Known Member
Doing the compilation of UI programs in a background session ( -b ) means that there is no UI ( or to be precise the only UI is an output stream - usually a file ). The root of your issue is that the UI widget definitions are per desing not suited for a stream output. I don't understand why you insist to run the compile of a UI in batch mode. If you run it without the batch option you will be fine.

Heavy Regards, RealHeavyDude.
Nightly batch compiles are a useful automation step.

I'm not in a position to test right now but I faintly recall setting TERM=vt100 in the compile script as my solution to this problem.


New Member
Nightly batch compiles are a useful automation step.

I'm not in a position to test right now but I faintly recall setting TERM=vt100 in the compile script as my solution to this problem.
Yes, I'm emphasizing on the batch compile for automation effort.
Unfortunately I have not been able to find the solution yet. I had exported TERM to vt100 and still didn't resolve the issue.

I came across one such scenario today. It happens on unnamed frames; it didn't throw error until x(78). If I provide anything more that that compiling the program as batch process (_progres -b or mbpro) throws error whereas mpro doesn't. Why? Below is a simple 2 liner program that would demonstrate this issue.

[sbalasub@xyz db]$ ./
**FILL-IN file-name will not fit in FRAME in PROGRAM /home/sbalasub/compile/test1.p. (4028)
where is;
exec /opt/dlc/bin/_progres -b -p /home/sbalasub/compile/test.p
where test1.p is;
UPDATE file-name.
I see similar coding on multiple nightly jobs where they get input from file on the fly. Currently we compile using 'mpro', so no issues but if in case we had to automate we may be facing similar errors as well.
Nice simple test case! Thanks.

That goaded my memory...

Subject to correction from deep inside Progress I /think/ what happens is that during batch compiles Progress *assumes* an 80 character wide screen. Is your interactive "mpro" a wide screen? (That would explain why it works.)

"100" blows up because it is more than 80 columns wide -- add "with width 102" to the update and the problem goes away (you need 2 spaces for the box drawn by default).

(In real code use the actual width of the target device...)

The TERM variable is apparently irrelevant. I must have been misremembering that.
Last edited:
Back to RealHeavyDude for a moment...

IMHO we should be able to specify the *target* compile environment and not be restricted to only compiling for the running UI. I should, for instance, be able to compile UNIX batch r-code from a Windows GUI session. And vice-versa. It's really annoying and inconvenient to have to maintain a rat's nest of systems in order to support multiple platforms :(

I'm not going to hold my breath waiting- but it sure would be nice.


New Member
Thanks Saravana for simple test case.

@Tom Instead changing individual programs for compile purpose, is there a way to change the progress assumption of 80 width screen for a batch mode?



New Member
Excellent Thanks Rob!! This is exactly I was looking for.

Only drawback that we have is, we don't have the solution for progress version prior to 11.6.


Rob Fitzpatrick Sponsor
If you're not already running 11.6 then you're on an ancient, obsolete and unsupported release and you ought to upgrade... ;)
Well, old releases are not technically unsupported... but you will definitely get better support the later a release you're on. And I agree with your other points. :)