Urgent Needs - 1/20/87



Card needs 	2
Link needs	3
NoteFile needs	5
Structure needs	6
Interface needs	7
Server needs	13
NCP (ProgInt) needs	16
Compactor needs	17
Text Card needs	18
TableTop card needs	19
TEdit needs	21
Card needs - Urgent
! 320. Tang: Card and NoteFile protected operations need rethinking and fixing
Date: 20 Nov 86 10:34 PST
From: Tang.pa
Subject: NoteCards 1.3k: Uncertainty about NC blocking
To: NoteCardsSupport.pa
cc: Tang.pa

NoteCards 1.3k System Date: 14-Nov-86 22:33:44
Lisp System Date: 11-May-86 15:19:08
Machine: Dove (204#110#)
Microcode version: 26,32
Memory size: 13400
Frequency: Intermittent
Impact: Minor

I don't have a good formulation of this problem, but:

With the new capability of having several NF open, there is a great temptation to do several different notefile operations at once, and I have occasionally noticed that breaks can result.  For instance, I might Compact one NF while I'm closing another, or once I was Copying one NF while doing some work in another's browser, and I got a break "end of file something not copied".

Another example, is that if you choose Close Cards off of the session icon menu and you select a list of cards to close, and while those cards are in the process of closing, you mouse a card icon to open a card, it lets you do that and opens the card, but halts the close card operation, and you have to go kill OLDMOUSE through the PSW and use Close Cards again to select the remaining unclosed cards.  This used to work ok in 1.2, but doesn't in 1.3.

These experiences have taught me simply not to try to do too many things at once.  This is probably some tedious programming for this stage of the game, so you might just warn users NOT to simultaneously execute notecards operations.

~jt
End of message
Link needs - Urgent
! 201. Kelley: Link Image Objects should wrap if title too long
! 247. Dixon: Links may not be keeping correct order after copy of a group
Date: 26 Sep 86 20:32 PDT
From: Trigg.pa
Subject: [MikeDixon.pa: notecards browsers]
To: Notecardssupport
cc: Trigg.pa

FYI:

     ----- Begin Forwarded Messages -----

Date: 25 Sep 86 14:49 PDT
From: MikeDixon.pa
Subject: notecards browsers
To: trigg
cc: snewman

when laying out a browser, notecards seems to call LAYOUTGRAPH with REVERSE/DAUGHTERS, which makes all the linked nodes come out in reverse order.  how come?
                                                  .mike.

Subject: Re: notecards browsers
In-reply-to: MikeDixon.pa's message of 25 Sep 86 14:49 PDT
To: MikeDixon.pa
cc: snewman.pa

Probably cause it knows that they came were computed in reverse order.  In any case, the order in the browser should match the order in the card.  (E.g. browser constructed from a filebox should have children appearing in correct order.)

		- Randy

     ----- End Forwarded Messages -----

Note:  Check to see if copy of a group of links preserves the ordering consistency (show links list should always be in same order as in substance).


! 345. Trigg: Cross-file Links weirdness
Date: 19 Dec 86 15:27 PST
From: Trigg.pa
Subject: NoteCards 1.3k: Cross-file links weirdness
To: NoteCardsSupport.pa, Tang
cc: Trigg.pa

NoteCards 1.3k System Date: 15-Dec-86 19:09:04
Lisp System Date: 11-May-86 15:19:08
Machine: Dorado (MONK)
Microcode version: 26,32
Memory size: 40000
Frequency: Always
Impact: Moderate

This came up out of discussions with John Tang:  suppose card A lives in one notefile, while filebox B lives in another notefile.  Then, say you file A in box B.  Because this is a cross-file link, a cross-file link card A1 is created in A's notefile with a FiledCard link pointing to A.  (There's also a cross-filelink card in B's notefile, but that's irrelevant to this story.)

Now, it turns out that if you close A without filing it anywhere else, NC won't object, because A has a filing link to it from within the notefile (from the crossfilelink card A1).  Worse yet, if you delete the filing link from B to A, NC STILL won't object.  This is because A1 still exists in A's notefile.

We could check that filing links not be from crossfilelink cards before pronouncing the card properly filed.  Other ideas?

		- Randy
End of message
NoteFile needs - Urgent
! 147.ml Kelley: NoteFile CopyCards should check index size before doing copy
Print a message: Reset NewNoteFileInitialSize to larger than x.  Do Compact.  Reset NewNoteFileInitialSize.  Re-do Copy Cards.
! 148.lm Kelley: NoteFile CopyCards should expand destination index if necessary
! 320. Tang: Card and NoteFile protected operations need rethinking and fixing
Date: 20 Nov 86 10:34 PST
From: Tang.pa
Subject: NoteCards 1.3k: Uncertainty about NC blocking
To: NoteCardsSupport.pa
cc: Tang.pa

NoteCards 1.3k System Date: 14-Nov-86 22:33:44
Lisp System Date: 11-May-86 15:19:08
Machine: Dove (204#110#)
Microcode version: 26,32
Memory size: 13400
Frequency: Intermittent
Impact: Minor

I don't have a good formulation of this problem, but:

With the new capability of having several NF open, there is a great temptation to do several different notefile operations at once, and I have occasionally noticed that breaks can result.  For instance, I might Compact one NF while I'm closing another, or once I was Copying one NF while doing some work in another's browser, and I got a break "end of file something not copied".

Another example, is that if you choose Close Cards off of the session icon menu and you select a list of cards to close, and while those cards are in the process of closing, you mouse a card icon to open a card, it lets you do that and opens the card, but halts the close card operation, and you have to go kill OLDMOUSE through the PSW and use Close Cards again to select the remaining unclosed cards.  This used to work ok in 1.2, but doesn't in 1.3.

These experiences have taught me simply not to try to do too many things at once.  This is probably some tedious programming for this stage of the game, so you might just warn users NOT to simultaneously execute notecards operations.

~jt
End of message
Structure needs - Urgent
! 185.hl Halasz: Structure Copy (NC.CopyCards) should assign a writelock when put down
Date: 10 Sep 86 15:41 PDT
From: Halasz.pa
Subject: NoteCards 1.3k: Copy structure does not work in NEXT>
To: NoteCardsSupport.pa
cc: Halasz.pa

Due to fact that copied cards do not own write locks when they are being put down.

-- Frank

End of message
Interface needs - Urgent
! 259. Gobbel: Interface shift-selecting something and then deleting it before finishing the shift-selection causes breaks.
Date: 20 Oct 86 21:54 PDT
From: Gobbel.pa
Subject: Notecards 1.3k: dangling thingies
To: NotecardsSupport.pa
cc: Gobbel.pa

It looks like there may be a rather pervasive problem with dangling references in the shift-select scheme for designating fileboxes, link destinations, etc.  I tried selecting a filebox which I deleted before finishing the filing operation, and sure enough, it dies.  Haven't tried other cases, but I'd be surprised if they weren't broken too.

-Randy

End of message
! 282. Tang: Interface problems with windows being pushed incorrectly in the horizontal direction
Date:  5 Nov 86 12:30 PST
From: Tang.pa
Subject: NoteCards 1.3k: More detail comments on user interface
To: NoteCardsSupport.pa
cc: Tang.pa

Lisp System Date: 11-May-86 15:19:08
Machine: Dove (204#110#)
Microcode version: 26,32
Memory size: 13400
Frequency: Always
Impact: Annoying

More discoveries about the session icon.  I tend to want to put it at the top of the screen roughly in the middle.  I've noticed that when I do operations like Copy, with long file names, it not only pushes the icon down from the top (as I mentioned earlier), but also pushes it horizontally to the right (because Copy has 2 file names involved in the prompt window, it is a rather long prompt window message--longer than 1/2 the screen).  Again, this tends to push the session icon underneath an active window, making it hard to find.  Again, I could get used to it, and I learned that Randy avoids it by keeping the icon near the top and hugging the right side of the screen, and maybe I'm just too used to the 1.2 way when THE Prompt Window was used, but you asked for naive reactions to 1.3k.

~jt

Date: 30 Jun 86 23:56 PDT
From: Trigg.pa
Subject: Re: NoteCards 1.3k: Session icon getting shoved down
In-reply-to: Halasz.pa's message of 30 Jun 86 23:22 PDT
To: Halasz.pa
cc: Trigg.pa, NoteCardsSupport.pa

My vote would be to change the code uniformly for all NC.  It would push the session icon (or card or notefile icon) down after remembering the old position.  Then, when the prompt window interaction is over, the window is moved back to its old position.

		- Randy
End of message

Date:  4 Sep 86 09:25 PDT
From: Newman.pasa
Subject: NoteCards 1.3k: message window moves main menu window
To: NoteCardsSupport.pa

NoteCards 1.3k System Date: 15-Jul-86 12:56:24
Lisp System Date: 11-May-86 15:19:08
Machine: Dandelion (207#276#)
Microcode version: 26,32
Memory size: 15777
Frequency: Once
Impact: Minor

While copying a notefile using the main menu copy notefile item,  a prompt window was created that was so long,  it could not fit on top of the menu window justified left or right without running off the screen.  What happened was, the prompt window opened with its left edge at the left edge of the screen, and it moved the main menu window to attach to the prompt window's lower right corner.  When the prompt window closed, the menu window stayed where it was.

A minor problem, but somewhat disconcerting.

>>Dave
End of message

Date: 31 Oct 86 17:44 PST
From: Tang.pa
Subject: NoteCards 1.3k: Naive reactions to 1.3k
To: NoteCardsSupport.pa

Lisp System Date: 29-Oct-86 22:35:30
Machine: Dorado (LeParc)
Microcode version: 26,32
Memory size: 40000
Frequency: Always
Impact: Annoying

Randy asked for my initial reactions to 1.3k.  One thing I noticed is that it's rather easy for me to lose the NoteCards main menu.  I typically put the NC main menu at the very top of my screen, so I don't cover it up with any other windows or notecards.  But, because the auxiliary message window gets occasionally attached to the NC main menu, it pushes the main menu down an arbitrary distance from the top of the screen.  The way I use NC, it inevitably pushes it underneath a window, then I can't get at it later.  It's harder for me to avoid overlaying the main menu when it's a couple inches from the top of the screen rather than at the very top.  Perhaps the auxiliary message window could attach to the bottom or side of the menu instead of the top.

Nit picky detail comments:

I kinda miss having Close Cards (being a frequently used operation) that you could just click on the main menu (instead of now having to make a selection off the main menu, then drag over to make an additional selection)

I rather dislike having to hold down a key to make the multiple card selections (like in Close Cards), but I guess it provides functionality that I haven't learned to appreciate yet.

~jt
End of message

! 249. Jordan: Interface of NC main menu is wrong
Date: 29 Sep 86 17:12 PDT
From: jordan.pa
Subject: Interface comment on NC main menu
To: notecardssupport, moran
cc: jordan.pa, shrager,card

	So I think the 1.3 main menu in NoteCards, which toggles between menu items and a picture depending on whether the cursor is inside or out of it, is certainly novel and even cute, but is unfortunately the wrong thing to have as far as interface issues go.  There are at least 2 reasons: 

	1.  When I am working elsewhere on the screen and my cursor is not in the menu (99.99% of the time), I can't remember what the items are.  I can no longer just glance at the menu to decide if I really want to go there:  I must now go there first!   Also, the menu items are a nice, well-structured 4-part categorization of NC ops that helps me organize the multitude of NC ops I must keep in my head; unfortunately you hide these items from me when I could most use them, i.e., when I am deciding what to do next.  

	2.  Fitts Law says you definitely lose.  To zero in on my target I must now do it in 2 steps:  first move to the menu and then, when the items appear, move to the one I want.  This is, again, because I can't remember what the items are, much less WHERE they are.  Result:  it takes me longer to get to the item I want, and it's now a 2-step process.

	In short, it requires either extra cognitive processing (remembering the items) or motor movement (uncovering the items) or both. 

	I see this as a general interface issue about a menu design that hasn't been tried before.  I find these reasons compelling enough to strongly suggest removing the toggle from the menu completely.  It's cute, but I think it's not what you want.  

Dan


	 
End of message
! 173.mm Briggs: Interface SelectCards typing at bombsight should blink
TTY exit and entry fn must turn on and off line buffering (^T & ^NIL)
! 234.hl Halasz: Interface select cards should just look for mouse up instead of both up.
Date: 12 Sep 86 10:47 PDT
From: Newman.pasa
Subject: NoteCards 1.3k: When asked to select a file box (filing a card), pushing "SHIFT" too early causes problems
To: NoteCardsSupport.pa
cc: Newman.pasa

NoteCards 1.3k System Date: 15-Jul-86 12:56:24
Lisp System Date: 11-May-86 15:19:08
Machine: Dove (207#53#)
Microcode version: 26,32
Memory size: 16400
Frequency: Always
Impact: Annoying

If you are filing a card, and are to the point where you are asked to select the file box, push the shift key down, left-click in the body of a filebox to bring its title to the top, then left-click in the title bar just brought to the top in order to push that file box into the prompt window.  The selection will not go into the box, and one must release the shift key, put it down again, and then select the title bar.

The only real problem that I have with this is that it is natural to expect that it will work given the way that similar actions work when shift-selecting from one TEdit window to another.  I guess this is just another consistency-of-interfaces issue.

>>Dave
End of message

Date: 19 Sep 86 23:03 PDT
From: Kelley.pa
Subject: Re: NoteCards 1.3k: When asked to select a file box (filing a card), pushing "SHIFT" too early causes problems
In-reply-to: Newman.pasa's message of 12 Sep 86 10:47 PDT
To: Newman.pasa
cc: NoteCardsSupport.pa

Yes this is a problem.  In fact, attempting to continue to select in the title or down in the body with the SHIFT key down will cause NC.CopyButtonEventFn to break "TRYING to \SETUPGETCH BEYOND END OF TEXT".  

Simple cross-TEdit shift selects do seem to work correctly (i.e. without having to let up on the SHIFT key after bringing the card totop).

 -- kirk
End of message
! 333. Gobbel: Interface Rename NoteFile should inform menu
Date: 15 Dec 86 13:59 PST
From: Gobbel.pa
Subject: NoteCards 1.3k: Rename should inform menu
To: NoteCardsSupport.pa
cc: Gobbel.pa

NoteCards 1.3k System Date: 11-Dec-86 19:23:11
Lisp System Date: 11-Dec-86 19:37:41
Machine: Dorado (Ventus)
Microcode version: 26,50
Memory size: 40000
Frequency: Always
Impact: Annoying

If you close a notefile, do a Rename NoteFile on it from the menu, then try to open it from the menu, it tries to open a file with the old name.  I think it should track the new name.
End of message
! 326. PIrish: Interface Closing a Notefile opened Read-only does not remove the "RO:" from the title
Date:  4 Dec 86 13:47 PST
From: PIrish.pa
Subject: NoteCards 1.3k: Closing a Notefile opened Read-only does not remove the "RO:" from the title
To: NoteCardsSupport.pa
cc: PIrish.pa

NoteCards 1.3k System Date:  9-Nov-86 22:08:17
Lisp System Date: 11-May-86 15:19:08
Machine: Dove (Leprechaun)
Microcode version: 26,32
Memory size: 13400
Frequency: Always
Impact: Minor

It seems like the icon menu title of a closed NoteFile should just be the filename, without the "RO:" left over from when the NoteFile was open.

-Peggy

End of message
Server needs - Urgent
! 349. Trigg: Server - Need abort of card closing if filebox is write-protected by another client
Date:  6 Jan 87 10:34 PST
From: Trigg.pa
Subject: NoteCards 1.3k: Need abort of card closing if filebox is write-protected by another client
To: NoteCardsSupport.pa
cc: Trigg.pa

NoteCards 1.3k System Date: 15-Dec-86 19:09:04
Lisp System Date: 11-May-86 15:19:08
Machine: Dorado (MONK)
Microcode version: 26,32
Memory size: 40000
Frequency: Always
Impact: Moderate

Say you're using the server and try to close a card, letting it be filed in the ToBeFiled box.  Then, if some other client of the notefile has the ToBeFiled box open, then a message prints in your prompt window, but the card goes ahead and closes without being filed.

This could be hard to fix - I'm not sure.  NC.CardSaveFn may not be able to abort the Quit.

		- Randy 
End of message
! 353. Trigg: Server - Need to be able to open cards read-only
Date:  6 Jan 87 10:41 PST
From: Trigg.pa
Subject: NoteCards 1.3k: Need to be able to open cards read-only
To: NoteCardsSupport.pa
cc: Trigg.pa

NoteCards 1.3k System Date: 15-Dec-86 19:09:04
Lisp System Date: 11-May-86 15:19:08
Machine: Dorado (MONK)
Microcode version: 26,32
Memory size: 40000

Cards should be able to be opened read-only.  (This should be the default when you're using the server.)  That way, I can have the TableOfContents box open and not prevent you from accessing the notefile.

This is probably easy in case of Text cards (just a flag in call to TEDIT), but perhaps hard for Sketch cards?

		- Randy
End of message
! 356. Gobbel: Server - SPP connections should go away after close
Date:  6 Jan 87 11:05 PST
From: Gobbel.pa
Subject: NoteCards 1.3k: SPP connections should go away after close
To: NoteCardsSupport.pa
cc: Gobbel.pa

NoteCards 1.3k System Date: 15-Dec-86 19:09:04
Lisp System Date: 11-May-86 15:19:08
Machine: Dorado (Ventus)
Microcode version: 26,50
Memory size: 40000

The SPP connection to the server should go away after the client closes its last server-based notefile.  Currently, the connection stays around forever.
End of message
! 357. Gobbel: Server - Server death causes uncloseable notefile
Date:  6 Jan 87 11:08 PST
From: Gobbel.pa
Subject: NoteCards 1.3k: Server death causes uncloseable notefile
To: NoteCardsSupport.pa
cc: Gobbel.pa

NoteCards 1.3k System Date: 15-Dec-86 19:09:04
Lisp System Date: 11-May-86 15:19:08
Machine: Dorado (Ventus)
Microcode version: 26,50
Memory size: 40000

If the server dies, the client is unable to close any server-based notefiles it has.  This makes it impossible for the user to log out, etc.  There should be a way to abort if the server has gone away.  Not entirely clear what we should do here, since the user may have lots of work that would be lost if we simply throw away the notefile.
End of message
! 358. Gobbel: Server - Client death causes dangling cache subscription
Date:  6 Jan 87 11:10 PST
From: Gobbel.pa
Subject: NoteCards 1.3k: Client death causes dangling cache subscription
To: NoteCardsSupport.pa
cc: Gobbel.pa

NoteCards 1.3k System Date: 15-Dec-86 19:09:04
Lisp System Date: 11-May-86 15:19:08
Machine: Dorado (Ventus)
Microcode version: 26,50
Memory size: 40000

This is the other side of the can't-close-if-server-dies problem.  If the client dies, the server is left with a cache subscription that will never go away.  There should be some provision for a timeout.
End of message
! 362. Gobbel: Server - protocol needs checkpoint operation
Date:  6 Jan 87 15:01 PST
From: Gobbel.pa
Subject: NoteCards 1.3k: Server protocol needs checkpoint operation
To: NoteCardsSupport.pa
cc: Gobbel.pa

Currently, NCMultiRemote.CheckpointNoteFile is a no-op, but we want to make it do a FORCEOUTPUT on the server.  This requires an addition to the protocol.
End of message

Checkpoint/commit process:

Two options: manual commit & automatic commit.  Manual commits only at explicit user request (abort likewise).  Could be options for various degrees of completeness of the commit (everything, just what was already saved, etc.).  Auto-commit means the "neighborhood" of a card is written to the server whenever the card is saved.  Need new protocol pieces to allow the entire operation to be performed atomically at the server.
! 386. Gobbel: Server - add readonly open to protocol
NCP (ProgInt) needs - Urgent
! 364. PIrish: NCP.GetLinks breaks with too many arguments to NCONC when collecting over 100 links
Date:  6 Jan 87 16:03 PST
From: Gobbel.pa
Subject: NoteCards 1.3k: NCP.GetLinks breaks with too many arguments to NCONC when collecting over 100 links
To: NoteCardsSupport.pa
cc: Gobbel.pa

NoteCards 1.3k System Date: 15-Dec-86 19:09:04
Lisp System Date: 11-May-86 15:19:08
Machine: Dandelion (DandeLisp)
Microcode version: 26,32
Memory size: 13777
Frequency: Always
Impact: Moderate

When using NCP.GetLinks in a way that will generate more than (about) 100 links, you get a break in NCONC - too many arguments.  Experimentation shows that the fault lies with NCONC.

-Peggy
End of message
Compactor needs - Urgent
! 272. Trigg: Compactor should open source notefile readonly when compacting to target
Date:  3 Nov 86 11:06 PST
From: Trigg.pa
Subject: NoteCards 1.3k: Compact to target should open source notefile readonly
To: NoteCardsSupport.pa
cc: Trigg.pa, Kahn

NoteCards 1.3k System Date: 31-Oct-86 17:50:18
Lisp System Date: 11-May-86 15:19:08
Machine: Dorado (MONK)
Microcode version: 26,32
Memory size: 40000

		- Randy T & Peggy
Text Card needs - Urgent
! 175.hm Everyone: Text cards should not cause stack overflow when too many.
TableTop card needs - Urgent
! 392. Dixon: Convert TableTop to 1.3 for use with Rooms
Date: 13 Jan 87 21:08 PST
From: MikeDixon.pa
Subject: notecards vs. logout
To: NoteCardsSupport

how about removing the restriction that i close my notefile before logging out?  there really doesn't seem to be any need for this, and it means that i have to lay out all my cards when i log back in again...  if you're worried about me losing my work, it seems like it would be enough to just insist that i checkpoint before i logout.
                                                  .mike.
End of message

Date: 14 Jan 87 10:56 PST
From: Trigg.pa
Subject: Re: notecards vs. logout
In-reply-to: MikeDixon.pa's message of 13 Jan 87 21:08 PST
To: MikeDixon.pa
cc: NoteCardsSupport.pa

Well, I'd at least want the following scenario taken care of.  Suppose you logout leaving the notefile open with card C open on the screen.  Now someone else (or you on a different machine or partition) opens the notefile and deletes C.  When you come back to the original partition, intelligent things need to happen.

For starters, the system should effectively reopen the notefile (that is, read the index back into core from the file and recompute the hash array).  Then it should check all open windows and make sure their cards, contents, links, etc. are still valid.  This feels at least as hard as just reopening to me.

What we used to talk about was the "tabletop" idea, where the notefile is closed for you at logout time, but open cards are remembered.  Then when you come back in, it gets reopened and the cards (those not deleted) are put back up on the screen.  Wouldn't that make more sense in the context of Rooms?

Comments?

		- Randy
End of message

Date: 14 Jan 87 11:47 PST
From: Gobbel.pa
Subject: Re: notecards vs. logout
In-reply-to: Trigg.pa's message of 14 Jan 87 10:56 PST
To: Trigg.pa
cc: MikeDixon.pa, NoteCardsSupport.pa

Also, let's not forget the NoteCards server.  It is BAD to leave files open on the server when you log out.

-Randy

End of message

Date: 14 Jan 87 13:37 PST
From: MikeDixon.pa
Subject: Re: notecards vs. logout
In-reply-to: Trigg.pa's message of 14 Jan 87 10:56 PST
To: Trigg.pa
cc: NoteCardsSupport.pa

if i understand it, i think your tabletop model is what i had in mind -- that the only information trusted about a card is its UID (if the contents in the notefile are different from those in the "window" (i.e. TEdit stream)) the notefile will be believed.  two other models are imaginable:

the lafite model:  if the file has been changed since you logged out, don't reopen it & throw away any information you had

the tedit model:  like the tabletop model, but the info in the TEdit streams will be believed -- if you close the notefile it will write out those cards over top of anyone else's change.  this might be difficult to implement, since you have to figure out whether the card needs saving (or maybe you don't, but that seems like it would just get more confusing).  even if you can implement it, it's not clear you'd want it.
                                                  .mike.
End of message

Date: 14 Jan 87 13:41 PST
From: MikeDixon.pa
Subject: Re: notecards vs. logout
In-reply-to: Gobbel.pa's message of 14 Jan 87 11:47 PST
To: Gobbel.pa
cc: Trigg.pa, NoteCardsSupport.pa

you wouldn't really be leaving the notefile open (any more than you leave your lafite folder open when you logout, or your tedit document).  conceptually all you're doing is saving your working state, rather than having to put everything away.
                                                  .mike.
End of message
TEdit needs - Urgent
! 277. Kelley: Cards changed titles not always updated in link icons
Date: 16 Oct 86 17:03 PDT
From: kelley.pa
Subject: NoteCards 1.3k: Changed titles not updated
Date: 16 Oct 86 17:03 PDT
From: kelley.pa
Subject: NoteCards 1.3k: Changed titles not updated
To: NoteCardsSupport.pa
cc: kelley.pa

Lisp System Date: 22-Aug-86 10:48:08
Machine: Dandelion (222#146#)
Microcode version: 26,32
Memory size: 15777
Frequency: >> Always, Intermittent, Once <<
Impact: Annoying

Link middle button menu item Change Card Title does not update title text in other links to the same card.

To test, create two links (on different lines) from the same card1 to the same card2 and change the title of card2 using one of the links.

 -- kirk
End of messageDate:  3 Nov 86 17:42 PST
From: kelley.pa
Subject: Re: [kelley.pa: NoteCards 1.3k: Changed titles not updated]
In-reply-to: Trigg.pa's message of 1 Nov 86 14:45 PST
To: Trigg.pa
cc: Kelley.pa, Notecardssupport.pa

This happens to me reliably in the latest Koto sysout.  Be sure the other link has no other means of becoming updated (such as being the last object in the card).

To test, create two links (on different lines) from the same card1 to the same card2 and change the title of card2 using one of the links.


 -- kirk
End of message(LIST ((PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC  ) STARTINGPAGE# 1) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY TIMESROMAN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT BOLD INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC  )) (162 36 288 36) NIL) (TEXT NIL NIL (72 72 468 648) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC  )) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY TIMESROMAN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT BOLD INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC  )) (162 36 288 36) NIL) (TEXT NIL NIL (72 72 468 648) NIL))) (PAGE NIL (PAPERSIZE Letter FOLIOINFO (ARABIC  )) (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (SUPERSCRIPT 0 INVISIBLE OFF SELECTPOINT OFF PROTECTED OFF SIZE 10 FAMILY TIMESROMAN OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF EXPANSION REGULAR SLOPE REGULAR WEIGHT BOLD INVERTED OFF USERINFO NIL STYLE NIL) FORMATINFO (ARABIC  )) (162 36 288 36) NIL) (TEXT NIL NIL (72 72 468 648) NIL))))).$$


˜)
T((
(

TIMESROMAN
TIMESROMAN


TIMESROMAN
TIMESROMAN
TIMESROMAN
	











































N
7
/%
6

|

Å
ê


?
J
,


*


ž9
 ;
î


(
•

(
4

/%

|

5
{



M
P
N
7
/%
6

|

Å
ê


V
?
S
	


{
+

X


a
@
%


>8"
ÿ



?
/%

Ð
-


1
%
ù

Ý
·

1
+

!


_
„
ø



G
FY
t
/%

¦
ü

x:
Ò
‹
	
;
3
/%
¸
e
f
/%
‘



a
d

/%


\

>
A

/%
Í
o


B
D
/%
™
@
B
/%

T
G
I
/%
Ì
;
D
›


ª
5

b
m
/%
·


V
P
/%

L

8


P9
";

?

4

/




"7
&
l


"7


#
{

¦9
"8"
ô9

D
44
%,
k
‹
	E6
#
£
‹

	gÚ°zº