Error in FoldElems? 
Author Message
 Error in FoldElems?

I have just implemented a new Elem class, which seemed to work fine until
I tried putting some Folds in the document containing those elements.
Then I found my folded text disappearing, to be replaced by a number.
After much head scratching, I discovered the reason, which is to do with
how FoldElems transfers the text between the folds into its hidden buffer
(in PROCEDURE Switch). It first deletes the text, then calls Texts.Recall
to retrieve it again. However, by deleting the text, the display is of
course redrawn, and my elements happened to delete some text whilst they
displayed themselves.

The fix is to use Texts.Save to save the text into the buffer, before
doing the actual Texts.Delete.  However, this does slow it down, and the
delay is quite noticeable when switching from one state to another if there
are many elements in the folding text.

I thought I'd post this here in case anyone else is (or is thinking of)
programming elements that may change the state of the texts delete buffer
and runs into the same problem.

-William Thorpe



Tue, 27 May 1997 08:05:45 GMT  
 Error in FoldElems?

Quote:

>I have just implemented a new Elem class, which seemed to work fine until
>I tried putting some Folds in the document containing those elements.
>Then I found my folded text disappearing, to be replaced by a number.
>After much head scratching, I discovered the reason, which is to do with
>how FoldElems transfers the text between the folds into its hidden buffer
>(in PROCEDURE Switch). It first deletes the text, then calls Texts.Recall
>to retrieve it again. However, by deleting the text, the display is of
>course redrawn, and my elements happened to delete some text whilst they
>displayed themselves.

Without more information, I would say that your element is having a side
effect that is undesirable.  You mention that your element is deleting
text when it receives a display message?  This is probably a bad thing to
do, as it should cause recursive calls for the display to be updated.  
Each of the higher procedures in the recursion hierarchy will think the
screen is displaying more characters than it really is.

You seem to be piggybacking a function onto a message which was not meant
for that purpose.  While I don't know for sure offhand, I feel confident
in saying that the underlying Texts.Text should not change while the view
is being updated.

Taylor Hutt, wanting a new monitor.
Why does Windows say 'Unable to print' for me?   Arrrrrggggghhh.



Wed, 28 May 1997 23:12:15 GMT  
 Error in FoldElems?

Quote:




>: >
>: Without more information, I would say that your element is having a side
>: effect that is undesirable.  You mention that your element is deleting
>: text when it receives a display message?  This is probably a bad thing to
>: do, as it should cause recursive calls for the display to be updated.  
>: Each of the higher procedures in the recursion hierarchy will think the
>: screen is displaying more characters than it really is.

>No, it's not as bad as that.  My element happens to have a (hidden) text
>as part of its implementation.  Sometimes I need to delete characters from
>this text (yes, while displaying the element!).  OK, so I could change
>this behaviour, but my concern here is with the behaviour of the
>Texts.Delete and Texts.Recall procedures as used in FoldElems.  Because they
>use a hidden buffer that is global to all texts, it is not safe to use them
>from several different places at once.

I still say you are doing something that is bad.
When you call Texts.Delete, the notifier is called.  When you call
Texts.Delete from within a procedure called from within the notifier, you
are invalidating the information contained by the outmost call to the
notifier.  Bad things may happen.

Taylor Hutt, Fantasy Films
Gilligan's Island the Movie: Bill Gates as Gilligan & James Doohan as Skipper.



Sun, 01 Jun 1997 06:56:48 GMT  
 Error in FoldElems?


: >
: Without more information, I would say that your element is having a side
: effect that is undesirable.  You mention that your element is deleting
: text when it receives a display message?  This is probably a bad thing to
: do, as it should cause recursive calls for the display to be updated.  
: Each of the higher procedures in the recursion hierarchy will think the
: screen is displaying more characters than it really is.

No, it's not as bad as that.  My element happens to have a (hidden) text
as part of its implementation.  Sometimes I need to delete characters from
this text (yes, while displaying the element!).  OK, so I could change
this behaviour, but my concern here is with the behaviour of the
Texts.Delete and Texts.Recall procedures as used in FoldElems.  Because they
use a hidden buffer that is global to all texts, it is not safe to use them
from several different places at once.

-William Thorpe



Sun, 01 Jun 1997 00:03:12 GMT  
 Error in FoldElems?

: I still say you are doing something that is bad.
: When you call Texts.Delete, the notifier is called.  When you call
: Texts.Delete from within a procedure called from within the notifier, you
: are invalidating the information contained by the outmost call to the
: notifier.  Bad things may happen.

OK, I take your point that Texts are not re-entrant.  But I have my own
notifier on this particular text, so the bad things that may happen are
not due to that.  I'm curous though as to why the Text notifier cannot be
called recursively, even with a different Text?

-William Thorpe



Mon, 02 Jun 1997 06:25:00 GMT  
 Error in FoldElems?

Quote:


>: I still say you are doing something that is bad.
>: When you call Texts.Delete, the notifier is called.  When you call
>: Texts.Delete from within a procedure called from within the notifier, you
>: are invalidating the information contained by the outmost call to the
>: notifier.  Bad things may happen.

>OK, I take your point that Texts are not re-entrant.  But I have my own
>notifier on this particular text, so the bad things that may happen are
>not due to that.  I'm curous though as to why the Text notifier cannot be
>called recursively, even with a different Text?

One reason for this is that Texts.Recall could not be used (without added
semantic information) to cut and paste between viewers.

Since you mentioned that you have your own notifier (and possibly a
different text), your position now seems more lucid -- and justified.

One thing that you might attempt is to do a Texts.Replace on your text,
instead of deleting it.  Replace the stretch with a 0 length stretch.  
I've not looked, but I don't think replace will copy to the delete buffer.

Taylor Hutt, Star Wars fan
AT&T is laying ~23,000Km of undersea fiber between Japan and Great Britain



Mon, 02 Jun 1997 21:28:20 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Error BASE/2012 Create error: AC01.DBF (DOS Error 32)

2. Error DBFCDX/1011 Write Error DOS ERROR 6

3. Serial Error 0x4002 (Error 16386, character was lost by overwrite / serial port overrun error)

4. Shouldn't there be two kinds of FoldElems?

5. fatal error: internal error

6. Trial and error/mainly error [was]Handy way..

7. An error in this error

8. TCP/IP error 503 in CW5=ok in CW5.5b the error

9. Clarion 5.5RC2 ..error 513 - Internal Error 13

10. Get Strange error error.bmp [01/26]

11. Error (513) Internal error (13)

12. Error (513): Internal Error 13

 

 
Powered by phpBB® Forum Software