home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / atari / st / tech / 5755 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  3.1 KB
  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!cs.utexas.edu!usc!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!unidui!rrz.uni-koeln.de!not-for-mail
  2. From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: GFA: Compiled program bombs at SWAP *x%,x$()
  5. Date: 22 Nov 1992 15:55:50 +0100
  6. Organization: Regional Computing Center, University of Cologne
  7. Lines: 60
  8. Message-ID: <1eo71mINN1889@rs1.rrz.Uni-Koeln.DE>
  9. Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
  10. NNTP-Posting-Host: rs1.rrz.uni-koeln.de
  11.  
  12. Hi tech folks,
  13.  
  14. I have run into an annoying problem  with  the  GFA  basic  3.6TT
  15. system.  The command mentioned in the subject causes the compiled
  16. program to exit with two bombs,  or  sometimes  to  exit  wit  an
  17. "Error  64"  alert  box.  However, in the interpreter the program
  18. runs without such a problem.
  19. This takes place on a TT, in TT med resolution, no matter whether
  20. the TT ram bits are set or not.
  21. I have tried to write a short program  that  reliably  reproduces
  22. the  error,  without  success. Therefore, I include an outline of
  23. what I do in the program that causes the trouble:
  24. The program is GEM-based and menu driven.  It  loads  stuff  from
  25. files into string arrays, and this stuff can then be displayed in
  26. windows. There can be several windows, which can all  be  redrawn
  27. by  the same routine. Therefore, I chose to store the the pointer
  28. to the array which is shown in a window in some  window-specific,
  29. MALLOC()'ed  chunk  of  memory.  When  it comes to redrawing, the
  30. redraw routine retrieves the  pointer,  called  p_st%,  from  the
  31. memory.  It  creates a dummy array, swaps the pointers, draws the
  32. window acessing the dummy array which is the real  array  because
  33. of  the  swapping. When redrawing is done, the arrays are swapped
  34. again and the dummy array is erased. In GFA code, that is:
  35.  
  36. PROCEDURE redraw(w_handle&,x&,y&,w&,h&)
  37.   LOCAL p_st%, ...
  38.   DIM d$(0)
  39.   a%=@w_adr(w_handle) !determine pointer to window-specific stuff
  40.   p_st%={a%+176}
  41.   ~FORM_ALERT(1,"[1]["+STR$(p_st%)+"|"+str$(*stb$())+"][ Ok ]")
  42.   SWAP *p_st%,d$()
  43.   .
  44.   .  (redraw the stuff)
  45.   .
  46.   SWAP *p_st%,d$()
  47.   ERASE d$()
  48. RETURN
  49.  
  50. The alert box reveals that p_st% and *stb$()  are  identical,  so
  51. the  problem  is not that GFA basic has shuffled the array around
  52. and the pointer once stored is no longer pointing to the  current
  53. location of the array descriptor.
  54. Unfortunately, it doesn't seem to be possible to write a function
  55. for  swapping  arrays manually. The problem is, swapping seems to
  56. swap the internal pointers to the array descriptors  rather  than
  57. the descriptors themselves. But maybe, I'll have to work on this.
  58. I'll post to the net if I can find the reasons for the problem or
  59. ways to work around it anyway.
  60.  
  61. BTW, a while ago someone mentioned he had a  list  of  known  GFA
  62. bugs. I'd appreciate if this could be mailed to me.
  63.  
  64. Thanx in advance
  65.  
  66. Greetinx, Jan
  67.  
  68.  +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
  69.  |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
  70.  |                                                                   |
  71.  *----=<  hierarchical systems are for files, not for humans  >=-----*
  72.