[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

2158.0. "Bad .BAS DECwindows header files?" by POBOX::CHALTAS (Fetchez la vache!) Mon Jan 29 1990 08:54

    Which (if any) version of VMS contains 'fixed' .BAS DECwindows 
    header files?
    
    A customer (currently running VMS 5.1 on his workstation) has found
    that the .BAS header files in 5.1 for DECwindows are so buggy as
    to be useless (his assesment).  He can't get his code to compile
    when using them.  He's made the reasonable assumption that things
    should be better in 5.2 or 5.3, but doesn't want to take the time
    for the upgrade (he only has a 5.2 kit at present) only to find
    out that they aren't.  So -- have any fixes been made to the .BAS
    header files?  If not, I suppose I should have him file an SPR,
    but I don't want to do this unnecessarily.
    
    	George
T.RTitleUserPersonal
Name
DateLines
2158.1DECWIN::JACKIEJackie FergusonWed Jan 31 1990 16:317
Some things have changed, the version of SDL changed, so that could effect
the output.  The Xlib file conditionally defined the quadword and friends
definitions at the beginning, so if he is using the toolkit and xlib files,
put the toolkit one first.  I don't think the toolkit people changed this.
The Xlib definition files all at least compile, there haven't been many
basic specific Xlib bugs, don't know about toolkit.  If he has a list handy,
a QAR/SPR is probably the best thing to do.
2158.2STAR::ORGOVANVince OrgovanMon Feb 05 1990 18:343
    The .BAS files distributed with DECwindows didn't change much (if any)
    between VMS V5.1 and V5.2. Your customer should probably go for V5.3
    and QAR any problems that remain.
2158.3...similar problem on 5.3-1... more detailSELECT::BOGATYDan.Wed May 16 1990 08:2749
	  I just inherited some BASIC routines which show
	similar problems when compiled.  This happens on 
	VMS V5.3-1. (Unfortunately, the author is not available.)


	  The routine contains the following "includes":

		%NOLIST
		%INCLUDE "SYS$LIBRARY:DECW$DWTSTRUCT"
		%INCLUDE "SYS$LIBRARY:DECW$XLIBDEF"
		%LIST

	  On compilation, I get the following error:
	"illegal multiple definition of name BASIC$F_FLOATING_COMPLEX"
    	(Changing the order of %includes as suggested in 2158.1 -> no
        effect.)

	  I extracted what seems to be the problem from the files below.
	Notice that decw$dwtdef.bas checks BASIC$F_FLOATING_COMPLEX_DECL
	to see if the 'record' has been created, while decw$xlibdef.bas
	checks   "..._DECLA" (There's an extra "A" at the end.)

	  So one included file takes the action and sets ONE symbol
	to indicate it's been done, and then the other file checks
	a DIFFERENT symbol to see if it's been done.. and does it again.

	  Am I using 'old' included files? Has anyone else encountered
	this on VMS V5.3-1?  Any clues? Any workarounds?


   decw$dwtdef.bas - (created by sdl 29-sep-1989)
   --------------------------------------------

      %IF %DECLARED(%BASIC$F_FLOATING_COMPLEX_DECL) = 0 %THEN
        record BASIC$F_FLOATING_COMPLEX       ^^^^
	   .
	   .
	   .

   decw$xlibdef.bas - (created by sdl 29-sep-1989)
   ---------------------------------------------

    %IF %DECLARED(%BASIC$F_FLOATING_COMPLEX_DECLA) = 0 %THEN
      record BASIC$F_FLOATING_COMPLEX       ^^^^^
	   .
	   .
	   .
     
2158.4Comment the offending definitions.SCAM::DIALWed May 16 1990 11:515
    I am running 5.3 and Basic 3.4 and have encountered your problem with
    the include files.  The fix I used was to comment the offending
    definitions.
    
    Barry
2158.5...may have toSELECT::BOGATYDan.Thu May 17 1990 09:1910
    I may end up having to do that... It's a cluster-wide version, so I'd
    have to make sure I'm not somehow screwing up someone else who may not
    need both...   maybe the best sol'n is to edit the file(s) so they all
    use the SAME variable... THAT shouldn't hurt anyone. (famous last
    words)
    
    Anyway, thanks for the reply, I feel a little less nuts, at least.
    
    	Dan.