Author |
Message |
Tom Harmo #1 / 13
|
 sp2 vs MF Dialog System
Does anyone here have experience with both the Flexus sp2 and the Microfocus Dialog System for developing Window 3.1/95 applications? I am trying to decide between the two products and price alone is not a factor ($1,000 vs 1,500). I was wondering if the MF product "blended" in better with the animator, etc.. Do they have the same features available? Is one easier to use than the other? Any input would be appreciated. tia P.S. I have the MF Professional COBOL 3.2 as my development environment. --
Harmon's Consulting Services (715) 835-0360 3211 McElroy Street Eau Claire, WI 54701
|
Fri, 23 Oct 1998 03:00:00 GMT |
|
 |
Michael Dod #2 / 13
|
 sp2 vs MF Dialog System
Quote: >Does anyone here have experience with both the Flexus sp2 and the >Microfocus Dialog System for developing Window 3.1/95 applications? I am >trying to decide between the two products and price alone is not a >factor ($1,000 vs 1,500). I was wondering if the MF product "blended" in >better with the animator, etc.. Do they have the same features >available? Is one easier to use than the other? Any input would be >appreciated.
I can't speak for Dialog System, but I have used the SP/II product for some time. The Sp/II product is easy to use and is designed for Cobol. As I understand, Dialog System incorporates a scripting language. Although I do not particularly care what language the product is written in, I do care when a product forces me to learn a language outside of Cobol to use the product. The Sp/II product is activated from within a Cobol program using a simple Call Using . . . structure--no criptic scripts. Sp/II provides the ususal features (pull-down menus, pushbuttons, etc) and also provides .avi and .wav support. Flexus supports several platforms including Windows 3.1, DOS, OS/2 and Unix variants. I don't know if a WIN/95 version is available yet. As I recall, there are quite a few Micro Focus users of Sp/II. You might want to give Flexus a call and demo the product. You might also be able to get some customer referrals, too. I use the Sp/II with CA-Realia Cobol and have not experienced any de{*filter*} problems. Mike Dodas
|
Mon, 26 Oct 1998 03:00:00 GMT |
|
 |
Bob Wol #3 / 13
|
 sp2 vs MF Dialog System
Quote:
>>Does anyone here have experience with both the Flexus sp2 and the
[snip] Quote: >I can't speak for Dialog System, but I have used the SP/II product >for some time. The Sp/II product is easy to use and is designed >for Cobol. As I understand, Dialog System incorporates a scripting >language. Although I do not particularly care what language the >product is written in, I do care when a product forces me to learn a >language outside of Cobol to use the product. >The Sp/II product is activated from within a Cobol program using a >simple Call Using . . . structure--no criptic scripts. Sp/II provides >the ususal features (pull-down menus, pushbuttons, etc) and also >provides .avi and .wav support. Flexus supports several platforms >including Windows 3.1, DOS, OS/2 and Unix variants. I don't know if >a WIN/95 version is available yet.
Yes, we have a version which supports 32 bit development in both Windows 95 and Windows NT using the Micro Focus 32 bit compiler. Quote: >As I recall, there are quite a few Micro Focus users of Sp/II. You >might want to give Flexus a call and demo the product. You might also >be able to get some customer referrals, too. I use the Sp/II with >CA-Realia Cobol and have not experienced any de{*filter*} problems.
Bob Wolfe Flexus visit the flexus COBOL page at htpp://www.flexus.com
|
Tue, 27 Oct 1998 03:00:00 GMT |
|
 |
Davi #4 / 13
|
 sp2 vs MF Dialog System
On May 06, 1996 18:46:54 in article <sp2 vs MF Dialog System>, 'Tom Harmon Quote:
>Does anyone here have experience with both the Flexus sp2 and the >Microfocus Dialog System for developing Window 3.1/95 applications? I am >trying to decide between the two products and price alone is not a >factor ($1,000 vs 1,500). I was wondering if the MF product "blended" in >better with the animator, etc.. Do they have the same features >available? Is one easier to use than the other? Any input would be >appreciated. >tia >P.S. I have the MF Professional COBOL 3.2 as my development environment. >--
>Harmon's Consulting Services (715) 835-0360 >3211 McElroy Street >Eau Claire, WI 54701
Tom, Please clarify: by "developing Window 3.1/95 applications", do you mean applications which run under and coexist with Win, or do you mean "native" Win applications which achieve results by direct calls to the Win API? I have experimented on a limited basis with both the Flexus and MF Dialog products. My impression (somebody please correct me if I'm wrong) is that both of them are suitable for running under/with Windows, but neither of them is designed to generate Windows API calls (what, for ignorance of a better term, I'm calling a "native" Win application). In MF Professional COBOL (same thing I use) you already have as good a tool as any for developing "native" Win applications. I found this to be the most direct route to Windows programming. Only catch was I had to swallow my pride and learn a little C, just enough to figure out what the MS Windows SDK is talking about. David L. Webber
|
Wed, 28 Oct 1998 03:00:00 GMT |
|
 |
Richard Plinst #5 / 13
|
 sp2 vs MF Dialog System
Quote: > Tom, > Please clarify: by "developing Window 3.1/95 applications", do you mean > applications which run under and coexist with Win, or do you mean "native" > Win applications which achieve results by direct calls to the Win API?
A 'native' Windows application must be taken to mean one that requires Windows and won't work under DOS alone. It is not necessary for the Cobol source code to have calls to the Windows API for this to be so, using a library that does the calls is also going to produce a 'native' application. For example taking a standard Cobol ADIS application and relinking it with QuickWin will result in a native Windows application even if it looks like the DOS application: the QuickWin library calls Windows API and the program will not work without Windows. Quote: > I have experimented on a limited basis with both the Flexus and MF Dialog > products. My impression (somebody please correct me if I'm wrong) is that > both of them are suitable for running under/with Windows, but neither of > them is designed to generate Windows API calls (what, for ignorance of a > better term, I'm calling a "native" Win application).
SP2 is available for DOS text mode, Windows and OS/2. The Windows version produces native Windows programs using actual Windows controls. The Cobol source does not need to call the Windows API, but the programs still operate as native Windows apps. Quote: > In MF Professional COBOL (same thing I use) you already have as good a > tool as any for developing "native" Win applications. I found this to be > the > most direct route to Windows programming. Only catch was I had to swallow > my pride and learn a little C, just enough to figure out what the MS > Windows > SDK is talking about.
If all that is required is dialog box like applications with pull down menus and no graphical work then SP2 and [presumably] Dialog is the 'most direct route' to Windows because it is not necessary to learn the SDK. I have written several Cobol programs directly to the SDK, including dialog box like apps, and would only recommend this route if graphics were required. My major app is a container ship planning system with the program drawing the ship, bays, stability curves, plan view, profiles, tank layout, ... all resizable for whatever vessel the data is provided for. Several megabytes of source code. The .EXE is around 1.3 meg and it uses a lot of .DLLs as well.
|
Thu, 29 Oct 1998 03:00:00 GMT |
|
 |
Michael Dod #6 / 13
|
 sp2 vs MF Dialog System
"> ">On May 06, 1996 18:46:54 in article <sp2 vs MF Dialog System>, 'Tom Harmon
"> "> ">>Does anyone here have experience with both the Flexus sp2 and the ">>Microfocus Dialog System for developing Window 3.1/95 applications? I am ">>trying to decide between the two products and price alone is not a ">>factor ($1,000 vs 1,500). I was wondering if the MF product "blended" in ">>better with the animator, etc.. Do they have the same features ">>available? Is one easier to use than the other? Any input would be ">>appreciated. ">>tia ">>P.S. I have the MF Professional COBOL 3.2 as my development environment. Quote: >>--
">>Harmon's Consulting Services (715) 835-0360 ">>3211 McElroy Street ">>Eau Claire, WI 54701 "> "> ">Tom, ">Please clarify: by "developing Window 3.1/95 applications", do you mean ">applications which run under and coexist with Win, or do you mean "native" ">Win applications which achieve results by direct calls to the Win API? "> ">I have experimented on a limited basis with both the Flexus and MF "Dialog ">products. My impression (somebody please correct me if I'm wrong) is "that ">both of them are suitable for running under/with Windows, but neither "of ">them is designed to generate Windows API calls (what, for ignorance of "a ">better term, I'm calling a "native" Win application). "> ">In MF Professional COBOL (same thing I use) you already have as good a ">tool as any for developing "native" Win applications. I found this to "be ">the ">most direct route to Windows programming. Only catch was I had to "swallow ">my pride and learn a little C, just enough to figure out what the MS ">Windows ">SDK is talking about. "> ">David L. Webber
Quote: >>>On May 06, 1996 18:46:54 in article <sp2 vs MF Dialog System>, 'Tom Harmon
>>>Does anyone here have experience with both the Flexus sp2 and the >>>Microfocus Dialog System for developing Window 3.1/95 applications? I am >>>trying to decide between the two products and price alone is not a >>factor ($1,000 vs 1,500). I was wondering if the MF product "blended" in >>>better with the animator, etc.. Do they have the same features >>>available? Is one easier to use than the other? Any input would be >>>appreciated. >>>tia >>>P.S. I have the MF Professional COBOL 3.2 as my development environment. >>>--
>>>Harmon's Consulting Services (715) 835-0360 >>>3211 McElroy Street >>>Eau Claire, WI 54701 >>>Tom, >>>Please clarify: by "developing Window 3.1/95 applications", do you mean >>>applications which run under and coexist with Win, or do you mean "native" >>>Win applications which achieve results by direct calls to the Win API? >>>I have experimented on a limited basis with both the Flexus and MF Dialog >>>products. My impression (somebody please correct me if I'm wrong) is that >>>both of them are suitable for running under/with Windows, but neither of >>>them is designed to generate Windows API calls (what, for ignorance of a >better term, I'm calling a "native" Win application). >>>In MF Professional COBOL (same thing I use) you already have as good a >>>tool as any for developing "native" Win applications. I found this to be >>>the >>>most direct route to Windows programming. Only catch was I had to swallow >>>my pride and learn a little C, just enough to figure out what the MS >>>Windows >>>SDK is talking about. >>>David L. Webber
The whole point of using tools is to aid the speed of development. The tools themselves are "native". Just because you incorporate a tool into your own applications to handle the difficult, mundane tasks such as handling the graphical API's, does not mean they merely "coexist". The Flexus and Micro Focus tools are not meant to generate native API calls. The whole point is to remove that distraction from development and let the developer concentrate on the business aspects of the system. One can mix "native" calls for functions not provided by the tools. Of course, you will probably have to buy the Windows (or other vendor's) appropriate SDK. My pride was not hurt having to translate C structures and calling conventions to Cobol--it was the time I had to spend doing it--time discracted from the task at hand that really did not contribute to what I was doing on the project. There is nothing wrong with using good tools to develop a project. I would suspect that many commercial products use tools to develop their products. Without them, they could not be timely and competitive in today's market doing everything literally from scratch. Mike Dodas
|
Fri, 30 Oct 1998 03:00:00 GMT |
|
 |
Shaun C. Murr #7 / 13
|
 sp2 vs MF Dialog System
Quote: >My pride was not hurt having to translate C structures and calling >conventions to Cobol--it was the time I had to spend doing it--time >discracted from the task at hand that really did not contribute to >what I was doing on the project.
You're goinh to kick yourself when I tell you this but you get a tool called 'H2CPY' with Micro Focus COBOL for converting the Windows (or anything else) SDK .H include files to COBOL copy books. You don't have to do it by hand. Quote: >There is nothing wrong with using good tools to develop a project. I >would suspect that many commercial products use tools to develop their >products. Without them, they could not be timely and competitive in >today's market doing everything literally from scratch.
Writing native Windows API apps is very time consuming and difficult to debug which was only one of the reasons for Dialog System. The other being the need to seperate the display logic from the business logic allowing you to put different front ends on essentially the same application to suit your customers needs. Saying that, most of the Micro Focus tools are written using Panels 2 calls which provide a happy medium between Native API's and seperate display logic like Dialog. It also allows easier cross platform development. We also have a seperate application engine that puts up initial windows, toolbars, menus and handles all the events. You just plonk your application inside that framework using Panels2. Makes writing new stuff a doddle. --
Micro Focus Ltd, Newbury, UK. | www: http://www.mfltd.co.uk/~scm/
|
Sat, 31 Oct 1998 03:00:00 GMT |
|
 |
jan pai #8 / 13
|
 sp2 vs MF Dialog System
[>] Please clarify: by "developing Window 3.1/95 applications", do you mean applications which run under and coexist with Win, or do you mean native" Win applications which achieve results by direct calls to the Win API? I have experimented on a limited basis with both the Flexus and MF Dialog products. My impression (somebody please correct me if I'm wrong) is that both of them are suitable for running under/with Windows, but neither of them is designed to generate Windows API calls (what, for ignorance of a >">better term, I'm calling a "native" Win application). In MF Professional COBOL (same thing I use) you already have as good a tool as any for developing "native" Win applications. I found this to be the most direct route to Windows programming. Only catch was I had to swallow my pride and learn a little C, just enough to figure out what the MS Windows SDK is talking about. David L. Webber [end->] I think we deal with a hardware guy here - I mean if using a native tool is not native enough then you need to build your own hardware to control it also on a hardware level to be sure you work on a 'native' level. I think it's very important to remember that what ever you like it, you are using C COBOL Assembler machinlevel code and more - EVERYDAY in a mixture, how would you else be able to run any computor? COBOL is one among many languages that fills its need very well so does the other languages to. Jan
|
Sat, 31 Oct 1998 03:00:00 GMT |
|
 |
David L. Webb #9 / 13
|
 sp2 vs MF Dialog System
On May 13, 1996 16:33:09 in article <Re: sp2 vs MF Dialog System>, Quote:
>less-than-relevant stuff deleted here< >The whole point of using tools is to aid the speed of development. The >tools themselves are "native". Just because you incorporate a tool into >your own applications to handle the difficult, mundane tasks such as >handling the graphical API's, does not mean they merely "coexist". >The Flexus and Micro Focus tools are not meant to generate >native API calls. The whole point is to remove that distraction from >development and let the developer concentrate on the business aspects >of the system. One can mix "native" calls for functions not provided >by the tools. Of course, you will probably have to buy the Windows >(or other vendor's) appropriate SDK. >My pride was not hurt having to translate C structures and calling >conventions to Cobol--it was the time I had to spend doing it--time >discracted from the task at hand that really did not contribute to >what I was doing on the project. >There is nothing wrong with using good tools to develop a project. I >would suspect that many commercial products use tools to develop their >products. Without them, they could not be timely and competitive in >today's market doing everything literally from scratch. >Mike Dodas
Thank you for rebuking me without flaming (not that I burn easily anyway)! I guess, because by now it's second nature to me, it didn't occur to me to reveal my bias. Which is, that when you get comfortable with API calls until they feel like an old shoe, the least time-consuming thing is to keep doing what you know and what works great. Learning the SDK consumes no time now, because I already know it, and learning a new tool, no matter how good, would consume some. However, having been continuosly in the COBOL business since 1972, I am well aware that sometimes one has to change, even to the extent of using code such as: MOVE FUNCTION NEWTRICKS TO OLDDOGS I'll get with the innovation program as soon as I can. But, in the meantime, I still feel more comfortable with the old stuff, such as: call WINAPI "MikeDodas" using by reference NewsGroup returning MildRebuke David
|
Mon, 02 Nov 1998 03:00:00 GMT |
|
 |
Michael Dod #10 / 13
|
 sp2 vs MF Dialog System
Quote: >You're goinh to kick yourself when I tell you this but you get a tool
*called *>'H2CPY' with Micro Focus COBOL for converting the Windows (or anything *else) *>SDK .H include files to COBOL copy books. You don't have to do it by *hand. *> H2CPY is fine if you're a Micro Focus User--I use CA-Realia. They have provided almost every SDK .h file in Cobol, so I didn't need a utility to convert the SDK headers. Even though you have Cobol equivalents, you still have to research the calls to the SDK, including undersanding definitions such as handles, double words, integers, passing by reference/content,etc.--in C-systle jargon, not to mention finding the SDK function you want to use. The SDK documentantion is gastly. It's poorly designed and badly cross-referenced in the manuals. If the documentation was really well-done, there would probably be 5 times the documentation--but that would have negative effects, too! *>> *>>There is nothing wrong with using good tools to develop a project. I *>>would suspect that many commercial products use tools to develop their *>>products. Without them, they could not be timely and competitive in *>>today's market doing everything literally from scratch.
*>Writing native Windows API apps is very time consuming and difficult to *debug *>which was only one of the reasons for Dialog System. The other being *the need *>to seperate the display logic from the business logic allowing you to *put *>different front ends on essentially the same application to suit your *>customers needs. *> *>Saying that, most of the Micro Focus tools are written using Panels 2 *calls *>which provide a happy medium between Native API's and seperate display *logic *>like Dialog. It also allows easier cross platform development. We also *have a *>seperate application engine that puts up initial windows, toolbars, *menus and *>handles all the events. You just plonk your application inside that *framework *>using Panels2. Makes writing new stuff a doddle. I agree with what you say here. As an Sp2 user, it sounds like Sp2 is easier to use. I merely have to make a simple call with two parameters (one for the function and one for the parms). I can modify properties, etc., and even create complete screens from withing Sp/2 on-the-fly without 'painting' first if desired--all with common Cobol syntax. The Cobol market has taken a long time to get here, but it is finally really moving! mike dodas
|
Mon, 02 Nov 1998 03:00:00 GMT |
|
 |
Michael Dod #11 / 13
|
 sp2 vs MF Dialog System
*> Thank you for rebuking me without flaming (not that I burn easily *>anyway)! *> I guess, because by now it's second nature to me, it didn't occur to *me *>to reveal my bias. Which is, that when you get comfortable with API *calls *>until they feel like an old shoe, the least time-consuming thing is to *keep *> *>doing what you know and what works great. Learning the SDK consumes *>no time now, because I already know it, and learning a new tool, no *matter *>how good, would consume some. *> However, having been continuosly in the COBOL business since 1972, *>I am well aware that sometimes one has to change, even to the extent of *>using code such as: *> MOVE FUNCTION NEWTRICKS TO OLDDOGS *> I'll get with the innovation program as soon as I can. But, in the *>meantime, *>I still feel more comfortable with the old stuff, such as: *> call WINAPI "MikeDodas" using *> by reference NewsGroup *> returning MildRebuke *> *>David Flame--Never! As a matter of fact, I do relate to the "comfort zone" syndrome. I remember when they took my punch cards away. By the way, is the return value of MildRebuke a signed, positive value or pointer to the next topic! mike
|
Fri, 06 Nov 1998 03:00:00 GMT |
|
 |
Andy Morr #12 / 13
|
 sp2 vs MF Dialog System
Quote:
>> I was wondering if the MF product "blended" in >>better with the animator, etc.. >I have experimented on a limited basis... >My impression (...) is that >... neither of >them is designed to generate Windows API calls ...
You are correct as far as you go for Dialog System (I've never used the other product). Like most 4GL GUI systems it is designed to make calls to the Windows API but to totally hide that from the user - the aim after all, is to make the developer as productive as possible in as little time as possible. One further point to mention is that DS is a layered technology which means that you can rapidly create the basic GUI with the painter and if you then wish to augment the screens with something special, you can make PANELS2 or Windows API calls from within the supporting COBOL programs. Hope this helps Andy Morris Sales Consultant, Micro Focus
|
Sat, 07 Nov 1998 03:00:00 GMT |
|
 |
alca.. #13 / 13
|
 sp2 vs MF Dialog System
On May 21, 1996 20:26:33 in article <Re: sp2 vs MF Dialog System>, Quote:
>stuff< >You are correct as far as you go for Dialog System (I've never used >the other product). Like most 4GL GUI systems it is designed to make >calls to the Windows API but to totally hide that from the user - the >aim after all, is to make the developer as productive as possible in >as little time as possible. >more stuff<
Back when I was studying which way to go, MF (or, for that matter, Flexus) might easily have sold me one of those products, had they told me what you're telling me now. But, for whatever reason, this was not disclosed, so I decided to get "on a first-name basis" with the API. At the time I thought that was the only way to actually be able to see and control the COBOL code which was doing the job. And by now I am familiar enough with the API calls that learning another product would, at least temporarily, slow me down more than it would help. BTW, several members of this group called my attention to the fact that it isn't strictly correct to refer to a COBOL program which calls the API directly as a ' "native" Windows program'. Without consciously intending to imply that there is anything superior about my approach, I was fumbling for a term which would describe a program which works that way, to differentiate it from one which uses an intermediary such as sp2 or MF Dialog, and/or from one which runs under Windows but doesn't use the API calls at all. Alas, I fear that the group may have underestimated my ignorance, because no one has told me what term I *should* have used for that! Somebody please tell me what the correct jargon is. David
|
Sun, 08 Nov 1998 03:00:00 GMT |
|
|
|