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

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

On May 06, 1996 18:46:54 in article <sp2 vs MF Dialog System>, 'Tom Harmon

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

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.

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.

">
">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.

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

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/

[>]
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

On May 13, 1996 16:33:09 in article <Re: sp2 vs MF Dialog System>,

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

*>
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

*>  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

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

On May 21, 1996 20:26:33 in article <Re: sp2 vs MF Dialog System>,

David