Resolved Error message when executing a structured procedure with the appbuilde


Recently I managed to add some include within a structured procedure. I need them because they can return some usefull data for my apps.

But when I execute this new procedure with the appbuilder, I get this error message:


I found nothing about it on the "internet". Do you have any idea ?

What is this _PROGES.exe doing ?

Best regards ,
Last edited:
_progres.exe is the Character/MS-DOS version of the GUI client and is used instead of prowin32.exe/prowin.exe when running TTY applications/mode.

The error message suggests that you have not got this installed or it is in a different directory to C:\DLC\BIN
The thing that I am afraid of is why, in very late 2018, anyone is adding include files. For any reason.

Or using "structured procedures".

None the less... the kb tells you exactly why: When the AppBuilder runs code it looks for a specific line of text in the source file to determine whether it runs the code as a GUI program or as a TTY program. A structured procedure does not have the line of code in it to tell the AppBuilder to run it as a GUI program.
Hi @TomBascom, hi @Rob Fitzpatrick ,

Yes I use structured procedure, for a simple thing. They have a project tree that is very usefull to used with the appbuilder. But maybe it's a bad habit of me that i can change.

So why is it "bad" to use "structured procedure" ?

And The include is for the thing I will explain now.

The "ERP" I'm working with was develop by one of our supplier and so I don't have the source. The includes I'm using in my structured procedure are a way to get the value of the "stecod" (company code that is runing the ERP) and the "uticod" (user code that is runing the app). With them I can get the value easily and also I get them the same way that I have them in a window application. So it was for me a way to standardize our developpement. But maybe it's also a wrong way to do it.

I'm open to every solution and help and critism of my work and way of code :)

Thank you for your support :)
Just my 2 cents:

While I prefer OO over procedural and I hate include files - whether you do OO or procedural does not dictate whether you produce clean code. While OO makes it somewhat easier it is not a matter of the approach - it is the human factor that matters most.

When you deal with legacy code you have do adapt and use what's there. But that does not necessarily mean that you are bound to procedures. I would try wrap the functionality in the include in a class and go from there.

When deciding whether to use OO or procedural - you have to start somewhere when you want to go OO. So why not right now - it will open a whole new world for an ABL developer.
@RealHeavyDude by OO you mean Object Oriented programming ?

I have some smal bases due to my history in vb .Net .

I will give it a try. I'm starting to read the class documentation of progress. But I'm not against some more advice and guideline for it :) Well why not some guide for the bases of OO :D

best regards everyone, and I'm not saying it enough but thank you for your help. I make some big jumb with you guys :D

Rob Fitzpatrick Sponsor
If you are looking for guidance I suggest you start with conference material. There is a lot out there and it will probably provide more direct guidance, dos and don'ts, etc., than the product documentation.

Start here:
PUG Challenge Americas

then here:
Progress Community

and here:
EMEA PUG Challenge 2018

As always, when viewing historic material, remember that the platform changes over time, so statements like "OE doesn't support X" that were true at the time may not be true now. That said, most of what you read/hear in these presentations will remain true today and on the whole it is a valuable resource.