sp2 vs MF Dialog System 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 13 post ] 

 Relevant Pages 

1. MF Dialog System

2. MF Dialog System, how to use

3. MF Cobol & Dialog System VENDO

4. MF Cobol per Dos e Dialog System VENDO

5. MF Dialog System 2.5.64

6. HELP: MF Dialog System useless with new cobol v3.2

7. Vendo MF Object Cobol E Dialog System 32 Bit

8. MF Dialog System POST-USER-EVENT

9. AcuCobol, sp2, Dialog

10. 68K vs CFM68K vs Tk 8.0.3 vs AppearanceLib vs System 7

11. Fujitsu 4.0 vs MF NetExpress & MF Resolve

12. Fujitsu 4.0 vs MF NetExpress & MF Resolve

 

 
Powered by phpBB® Forum Software