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

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

968.0. "Problems with WP I Read option to Edit document WP,I,R,E" by GIDDAY::SETHI (Man from Downunder) Wed Jul 01 1992 09:46

    G'day,                                                
    
    A customer has just installed Version 3.0 from the CD-ROM and is having
    the following problem :-(
    
    1. $allin1/nocustomize
    2. Then does the following :
    
    	WP I 
    
    The index consists of the following documents
    
    1  FOLDER	DOC1
    2  FOLDER   DOC2
    3  FOLDER   DOC3
    4  FOLDER   DOC4
    etc
    
    Read's a document any document in no particular order and edit's it (R
    E), or she goes to the READ MENU and does an E for Edit.  Gold Files
    the document.
    
    Say it was document 2 for arguments sake.  Customer then goes to document 3
    and does a R and an E.  Gold files the document.  The index is updated
    incorrectly.  For example
    
    1  FOLDER	DOC1
    2  FOLDER   DOC2
    3  FOLDER   DOC2  <----- document 3 is now called DOC2
    4  FOLDER   DOC4
    etc
    
    If any subsequent documents are read and edited they to are called
    DOC2.  However the edit has updated the document.  If the customer goes
    back to the WP menu and does a RI (Recall index) she still get's the
    corrupted index.  In fact DOC2 on the index which is suppose to be DOC3
    is really DOC3 !
    
    Another problem we noticed on the system. If you select a number of
    documents for example
    
    x1  FOLDER	 DOC1
    x2  FOLDER   DOC2
     3  FOLDER   DOC3
     4  FOLDER   DOC4
     etc
    
    And do a XR after reading DOC2 you should be returned to the Index,
    this is not the case.  You have to enter the EXIT key otherwise the
    read function goes into a loop, going between document 1 and 2.
    
    Is this a know problem ?  Are there any work arounds ?
    
    Thanks for your help in advance
    
    Sunil

T.R	Title	User	Personal Name	Date	Lines
968.1	I can reproduce #1	IOSG::TALLETT	Arranging bits for a living...	`Wed Jul 01 1992 18:19`	17
	Well yes, I can reproduce your first problem on our production machine (IOSG). I'm amazed this slipped through all the testing! I could only make it do it from WP, EM was OK. This bug looks like a new one. Note that its only the index that displays wrongly, the documents are okay. However, if you delete one of the wrongly displayed documents, it deletes the wrong document and removes the other from the index! Stepping through with debug, it looks like WPEDIT is doing something wrong, but I'll defer to an expert... Your second problem works ok for me, I can't reproduce your loop. Regards, Paul
968.2	And I can get #2 !!	IOSG::MAURICE	Ceci n'est pas une note	`Wed Jul 01 1992 18:22`	9
	Hi Paul, You can get the loop if the after the edit the same document is on the index twice. If you select both occurances and XR it will read the document in a loop until you exit. Cheers Stuart
968.3	Confirmation of problem areas	GIDDAY::SETHI	Man from Downunder	`Thu Jul 02 1992 01:40`	16
	G'day, The problem only occurs from WP and not EM I should have put that into my note. Reading a document goes a loop as stated in .2, I looked at my log of my login session on the customers machine. The customer is testing every option available to the users before they upgrade to version 3.0 on their live machine. Any idea when a patch will be available for this and any other reported problems ? I know that you may not be in a position to give a date or timescale that's fine. A workaround would be great once you have found the problem area. Thanks for your help Sunil
968.4	Bug it please	IOSG::TALLETT	Arranging bits for a living...	`Thu Jul 02 1992 09:04`	17
	Hi there! It looks like you can only get #2 if you have already had #1 so you only have one bug, #2 is just a side-effect. It sounds to me that WPEDIT.SCP is in error, but just stepping through the code, the problem didn't jump out at me. What I am trying to say is you should be able to workaround the problem by modifying WPEDIT.SCP (ie the problem doesn't seem to be in code that you can't change). As for dates for a fix, well you HAVE to submit a bug report (mark it "customer reported") or it may never get fixed. Remember the notesfile is not a bug reporting tool. Regards, Paul
968.5	See note 10.* on how to submit a bug	IOSG::TALLETT	Arranging bits for a living...	`Thu Jul 02 1992 14:37`	1

968.6	We should have caught that one!	IOSG::CARLIN	Dick Carlin IOSG, Reading, England	`Thu Jul 02 1992 19:03`	43
	If you are desperate for a UI fix, then the following will do (though please do what Paul says as well): In WP$INDEX name data (Read option) change DECLARE_METER #METER_NO, OA$_WP_READ\\START_METER #METER_NO\\ DO WPLIST\\STOP_METER #METER_NO to GET #R_CURDOC = OA$CURDOC\\ DECLARE_METER #METER_NO, OA$_WP_READ\\START_METER #METER_NO\\ DO WPLIST\\STOP_METER #METER_NO\\ CAB CURRENT #R_CURDOC This is not an elegant solution and may well not be the one implemented in a pfp or pfr (it shows that I'm not sure about the reasons for pushing and popping anyway). Dick -------------------------------------------------- If you are interested, this is what is currently going wrong: The problem is in an interaction between WP$INDEX (read option) and OA$LIST$CAB$OPTIONS (edit option). The ingredients for the problem situation were as follows: The first Read Edit pair resulted in OA$CURMES being set up to DOC2. A MAIL PUSH and MAIL POP around the second Edit resulted in this being restored into OA$CURDOC following the edit. The OA$SCL_UPDATE at the end of the the second Read then uses this erroneous OA$CURDOC value and updates DOC2 rather than DOC3. You would get the same problem if the second Edit was an MCD or any other operation with a PUSH/POP round it in OA$LIST$CAB$OPTIONS. EM I results in the EM$INDEX$OPTIONS read option being used and doesn't suffer from the same problem, as you discovered.
968.7	Shame the fix was not in 3.0-1 !	TINNIE::SETHI	Ah (-: an upside down smile from Oz	`Fri Apr 23 1993 07:25`	1