Conference bulova::decw_jan-89_to_nov-90

> decent ...in Fortan?

Sounds like a distinct oxymoron to me, folks....

> I have a customer who refuses to learn C and insists on writing
> DECwindows application in Fortran.

That's what we get for providing even ONE example in a paleatological 
diatrab like FORTRAN!!! For pete's sake, if s/he MUST do higher mathematics,
can't they AT LEAST learn an up-to-date math-oriented language, like Pascal?

> They currently have me attempting to write Fortran versions of the example 
> programs...

What's the matter, don't THEY have programmers? Or are we in the business of 
writing applications for customer, gratis, now?

> I am pulling the hair out of my head! 

Perfectly understandable.If I (or any other professional programmer) had to 
convert perfectly good C code to FORTRAN, I would be, too.

Now that I've had my (admittedly sick) fun, I'm sorry to disappoint you, I don't
know ANYONE whose written FORTRAN for the DECWindows environment. For that 
matter, I don't know anyone whose written much FORTRAN (or would admit to it if
they had).

Cheers, 

Brian
8'{)

    There are a couple of fortran programming examples in the dw_examples
    conference, and there is an example in the DWT reference manual.
     The main thread through that (the VMS piece) is done in fortran.
    
    Re .Brian - FWIW, I use fortran above all others, and FWIW, fortran
    continues to be the singles highest volume layered product that
    DEC sells.  Here at the support center, Fortran calls outnumber
    the next highes volume (C) by all most 3 to 2, accounting for over
    35% of our 200 calls per day.  It remains a VERY powerful language,
    and, as you might tell, I am rather biased towards it.  ;-)  Anyway,
    all in good fun!
    
    Greg...

In the Pascal conference it was noted that Pascal sold more licenses last
year than C...

Chad

    Great attitude.  Learn a "modern" language or use someone else's
    windowing system.  I'm sure IBM (or HP, or Sun, or Apollo, or DG,
    or...) would be tickled pink to provide examples in whatever supported
    language the customer wanted to see.
    
    One of VMS' strengths has been it's multi-lingual environment.  It
    would be a real shame if we lost that in the race to meet the technical
    market's bias towards C.
    
    	- Barry

If Brian's attitude is typical of what is in the TP arena today, then
I'm afraid that we've lost any hope of taking part in that market. The
TP market place is primarily a COBOL one, never will be C, unlikely to 
be FORTRAN, and PASCAL and ADA are curious oddities. I certainly hope
that "learn a new language" tripe was just for show.

I can just imagine the reaction such a statement would get in some of 
the larger insurance or financial instutitions we are trying to get to
buy DECwindows. It's very predictable, they'd quietly say: "Well, I think 
this meeting is concluded, come back when you can listen to our problems..."

James
(speaking as a former SWS)

    Seriously!!!
    
    Replies like .1 really p.... me off. The question in .0 is a valid
    one and has a good point. Our entire DW documentation set is biased
    towards C. If our cutomers want to write their programmes in FORTRAN
    then who the h... are we to critisize? Oh sure FORTRAN has it serious
    shortcomings but so has C. I've been programming C and other languages,
    including FORTRAN, for a number of years. I do not happen to dislike
    C but I must admit that sometimes I have problems understanding
    the code I wrote 6 months ago. Readability is extremely poor and
    hence so is mainanability. However this is beside the point.
    
    .0 aked a straight question. Why not a straight answer ?? The arrogance
    in .1, I must admit, is the reason why sometimes I hesitate to seek
    information via questions in notesfiles.
    
    Flame Off.....
    
                                                     ToreO....

He posted an accurate title for his response.   It was supposed to be a joke.
If it's offensive, hit <NEXT UNSEEN>

My own preference is for C, but I have been a resident at this customer
site (Mobil R&D) for 3-1/2 years and have been working primarily with
Fortran (and a little Macro-11) for the duration.  I'm not going to
get involved in religious disputes regarding the suitability of 
C vs. Fortran vs. whatever -- the bottom line is that the customer
has a staff that is proficient in and comfortable with Fortran and they
are getting very pissed off at being forced toward C.

I realize the following was written tongue-in-cheek...

> What's the matter, don't THEY have programmers? Or are we in the business of 
> writing applications for customer, gratis, now?

...but for the record, Mobil is paying BIG BUCKS to have myself and other 
DEC people on site, the C-to-Fortran translation I am doing is NOT a freebie!!
It may cost me my sanity, however...

Where is the DW_EXAMPLES conference located?  (It does not seem to
be listed in our local copy of EASYNOTES.LIS.)

		Bob A.

    Bob, DW_EXAMPLES can be found in ELKTRA::DW_EXAMPLES.


    Mike Endsley
    SWS @ STO

Re: 556.8 <MCNALY::MILLER>

THANK YOU, SIR! Of course .1 was done entirely in jest! I always have fun poking
at FORTRAN paleatologists! I mean, what other (allegedly) third generation 
language can claim to have JUST RECENTLY discovered what a *file* or a 
*structure* is all about? Lo and behold, data is no longer nothing but a series
of streaming bytes! Welcom, FORTRAN, to the 1970's - you're only 20 years late! 
(FWIW, B4 you FORTRAN engineers FLAME ON again, the above was ALSO done tongue
and cheek - lighten up a little, will you?)

BTW, not only is the majority of the TP world programming in COBOL, but so do I.
I well recognize the realities of the TP/commercial world. COBOL _IS_ the 
standard language, LIKE IT OR NOT. I recognize COBOL's deficiencies, not the 
least of which is its verbosity, but I have learned to live with them. Further,
for the majority of applications, which involve primarily data transfer of one
sort (bad pun) or another, COBOL does the job admirably well. As well or better
than any other language could, because data transfer is what COBOL is all about!
I call FORTRAN routines (see there, I've admitted it!) to perform complicated
mathematical procedures, passing transitory data back and forth (which is what
FORTRAN likes to do, as opposed to reading data). I also call VMS RTL routines
to perform work that COBOL doesn't do especially well. I've even resorted to an
occassional MACRO or BLISS sub-routine to do some fairly radical environment
manipulations. Finally, I usually envelope the COBOL in an ACMS environment, so 
the COBOL doesn't have to worry about that which it does _NOT_ do at *ALL* well,
User Interface Services.

So no, I'm _NOT_ uni-linguistic or narrow-minded, or short-sighted. But I can't,
IMHO, see the benefit (especially long-term) of advising a customer (even by 
our silent non-protestation) to invest in a FORmula TRANslator is their COmmon
Business Oriented Language (get the picture?).

Trying to get serious without flaming,

Brian

For what it is worth I have not been silent at all, but have
for some time been reccomending to the customer that they
consider C for DECwindows application development (if for no 
other reason than that's where most of the support seems to be).
They won't go for it though, so I'm trying to ferret out
as much Fortran support as I can find.

		Bob A.

P.S.  Thanks for the pointer to DW_EXAMPLES, I found some
      useful items there.

I posted a FORTRAN version of HELLOWORLD to DW_EXAMPLES.  In my copious (hah!)
spare time, I'll work on converting some of the other examples to FORTRAN
(DECBURGER will probably be my next target - I had so much fun with the Ada
version!).  I'll also try to get these on the DECwindows kit.

FORTRAN is a perfectly viable language for writing DECwindows applications.
Ada is even better.

			Steve (VAX FORTRAN, and formerly of VAX Ada)

    
    >FORTRAN is a perfectly viable language for writing DECwindows
    >applications. Ada is even better.
    
    Only under VMS....

>    >FORTRAN is a perfectly viable language for writing DECwindows
>    >applications. Ada is even better.
>    
>    Only under VMS....

    I didn't expect to read such a criticism of Ultrix from you. How
    can you take seriously and operating system that doesn't support
    a language as important as FORTRAN as a perfectly viable language
    for writing DECwindows applications? (Only half joking)

    			Alfred

I think Bob was referring to Ada, and in that aspect, he is correct, as
Digital doesn't have an Ultrix Ada product, and the non-Digital Ada compilers
don't understand our packages.

However, FORTRAN is supported on Ultrix and should work ok.

			Steve

Well, I've been making progress but have run into a problem that I
can't seem to figure out.  The code I am converting is a simple
ATM program which is used as an example in the DECwindows self-paced
course. (Example 3-5 in the Toolkit section to be precise.)  The program
calls XT$INITIALIZE and creates several widgets, sets the "main widget
areas" with DWT$MAIN_SET_AREAS, and then bombs out on a null pointer 
when trying to create a caution box.  

The original C code looks like this:

        /**********************************************************
        * CREATE THE CAUTION BOX AS A CHILD OF THE FILE MENU USING
        * THE HIGH LEVEL ROUTINE.
        **********************************************************/
        caution = DwtCautionBox (
            file_menu,
            "Caution",                                /* widget name */
            FALSE, 75,175,                         /* use default position */
            DwtModal,                           /* lock out everyone else */
            DwtLatin1String("Do you really want to EXIT ?"), /* label */
            DwtLatin1String("Yes"),             /* labels for three */
            DwtLatin1String("No"),              /* exit pushbuttons */
            DwtLatin1String("Cancel"),          /* cancel pushbutton */
            DwtCancelButton,                        /* default pushbutton */
            caution_callback,                   /* exit callback */
            NULL);                              /* no help callback */

My Fortran translation looks like this (CSTRING[1-4] are INTEGER*4):

        CALL DWT$LATIN1_STRING('Do you really want to EXIT ?',CSTRING1)
        CALL DWT$LATIN1_STRING('Yes',CSTRING2)
        CALL DWT$LATIN1_STRING('No',CSTRING3)
        CALL DWT$LATIN1_STRING('Cancel',CSTRING4)

        CAUTION = DWT$CAUTION_BOX(
        1   FILE_MENU,
        1   'Caution',
        1   DWT$C_FALSE,75,175,
        1   DWT$C_MODAL,
        1   CSTRING1,
        1   CSTRING2,
        1   CSTRING3,
        1   CSTRING4,
        1   DWT$C_CANCEL_BUTTON,
        1   CAUTION_CALLBACK,
        1   NULL)

The original code works fine.  The Fortran code produces the following
result:

Access violation, reason mask=00, virtual address=00000000, PC=0000FB5A, PSL=03C00000
Symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           0000FB5A  0000FB5A
                                                           000C64CA  000C64CA
                                                           000C9092  000C9092
                                                           000C95B2  000C95B2
                                                           000C99AC  000C99AC
DECWDEMO        DECWDEMO                        14114      0000073B  00004F3B

The parent widget identifier (FILE_MENU) and the compound string
pointers (CSTRING[1-4]) contain what seem to be valid values. The
caution callback structure also seems to be OK.  I fill in the
callback routine address by declaring it as EXTERNAL and loading
it into the structure via %LOC(routine_name).

I am a novice at both DECwindows and VAX Fortran (my Fortran experience
up to this point has been on PDP-11), so please be gentle if I'm
doing something stupidly/obviously wrong!

		Bob A.

I think I found the problem...  since the CSTRING variables contain
pointers to the compound string structures, they need to be passed
to the toolkit routine using %VAL().  At least the DWT$CAUTION_BOX call
no longer blows up.  (Of course, now the program blows up further down
the line but it may be a similar type problem...)

Wishing I could talk these folks into using C,

Bob A.