How to Create The Executable File In progress

S

skunal

Member
Hi,
I want to create an executable file in progress so that i can just run that project instead of opening an APP Builder then opening the .w file and pressing RUN. I want to create direct link to run the project .The executable files like we do in JAVA and C of that kind so that that particular project is run.And I am not using the APPServer. How can it be done.

Thanks,
 
Progress doesn't work that way.

The Progress 4GL is an interpreted language. You must always use the Progress run-time to execute it.
 
You can compile the program to create a .r, that will run if you have Progress installed without you having to load the appbuilder. But like has been mentioned, Progress doesn't work like C or Java.
 
Not to mention that one can create a shortcut to run the program with the required progress command and parameters including -p to specify the program to run.
 
As identified previously, Progress can not create executable files because it is an interpreted language. If on GUI, you have to use prowin to execute the source code. You can however create the illusion of an executable application once compiled. Simply by running from a shortcut to prowin 32, then supplying the appropriate parameters - eg - db databaseName.db -p procedureToExecute.p/.w . This will give the user the impression that your finished application is an executable.
Look into startup parameters.
Hope this helps.
 
Thanx for the replies..................it was helpful for me all your replies....But I want to let to know one thing may be its weird. As JAVA is also Compiled and Interepreted Language as Progress 4GL where .java files are compiled to .class Files and the JVM (Java Virtual Machine) interprets them same as ".p or .w " files are compiled to ".r " files and then Interpreted by AVM (ABL Virtual Machine). Why is it not possible in Progress 4GL as compared to JAVA to create the executable files .May be this question is weird..............but just wanted to know the reason
 
In theory it would, of course, be possible.

In practice Progress Software Corp has no particular incentive to do so and nobody else has invested the time.
 
IMO, Progress is not really at home in the GUI, Windows, icons, mice, double click, desktop world. Their strength is server-side database manipulation and business logic. The fact that their desktop client is not as refined as Java's is but one symptom of this. There are many more.
 
The fact that their desktop client is not as refined as Java's

Looked at any of the work done with the ABL GUI for .NET?
 
Too little, and moreso, WAY too late.

Hey, I love Progress as much as anyone here. I also love my Blackberry. But I don't use my Blackberry to write code. Nor do I don't carry a PC around with me in my pocket. The fact that there are really small Netbook PC's these days, or that the new BB keyboard is highly usable, does not change my mind about these things.

Right tool for the job, and for GUI, it's not Progress (unless you are stuck with a legacy code base and/or skill set).
 
Greg, I agree.

The ABL GUI for .NET is a nice playground, but IMHO if I would settle on .NET then I would go for a native .NET GUI and connect it to the OpenEdge AppServer - just my opinion.

To me it looks like Progress has real talent to bring cool features to their products, but just not at the right time. Plus, when they do, they have the tendency to tell everybody who is not hopping on immideately that thei're not doing the right thing :confused:

Regards,
RealHeavyDude.
 
I have no problem with .NET OpenClient or, better yet, an RIA client, but I no longer think it fair to suggest that one can't make a top quality GUI with ABL. I might not go there myself since I don't like fat clients (although WebClient is certainly an interesting option), but don't want to and can't are quite different things.
 
You absolutely CAN, we have one, I wrote a lot of it myself. But why would you want to, other than just to standardize on one language (which I no longer feel is a good enough reason)? I mean, you CAN write business logic in C, but hardly anyone would recommend it. (Be quiet, Steve!).

BTW, since you mentioned RIA, I'd like to take this opportunity to once again plug one of my favorite new findings, Ext-JS. If you think you can't make something that runs inside any browser with no plugins, yet looks as awesome as anything you get with Progress or .NET or Java... think again. Just look at their demos. Come on, I dare you!
 
In the past Progress did a good job of hiding the complexity of third party technology in 4GL statements. Nowadays one might have the impression that one could just jump from his V8-style GUI to the new ABL client for .NET. I don't think it's possible without learning how .NET works and not ending up in a world of grief. Knowing how .NET works using a language like C# instead of the ABL is just a matter of learning it's syntax. Therefore why not develop the GUI in .NET because I don't think it's so much easier doing it the OE Architect using ABL.

To me it was always important to understand how something works. If I don't know the syntax to a specific statement I can look it up in the manual. If I don't understand what is going on and the priciples on which it is based don't believe I can succeed.

To be honest, I never really liked the idea of being tied to a specific user interface with a fat GUI client, just like others, but that's another story.

Regards,
RealHeavyDude.
 
If you're going to write .NET GUIs you cannot avoid learning about the .NET libraries and the whole object tree.

But that has nothing to do with language syntax and advantages/disadvantages. C# (or VB or whatever) has no special advantage when dealing with the .NET GUI -- that's all external to the language itself.

The UI examples in C# are virtually the same as the code would be in Progress. You can easily convert an example given in C# to 4GL just by changing a few dots to colons and such. It's really pretty trivial.

The 4GL still shines when it comes to manipulating data (be it temp tables or prodatasets) and doing the other non-UI bits. Doing that stuff in C# et al just isn't very attractive. At least it isn't to me.
 
And, what seems to be important to a number of shops is that they aren't interested in developing specialist teams for specific tasks, i.e., .NET programmers for UI. To me, this kind of specialization makes sense, especially since ABL is too big now for anyone to be an expert on everything ... not to mention non-ABL issues like DB tuning ... but many shops seem to think there is a virtue in keeping everything in ABL. So be it. If they can now produce a UI which is as good as anything one could do writing in C#, why not?
 
You must log in or register to reply here.
Back
Top