THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700
rodwelch@pacbell.net


S U M M A R Y


DIARY: March 25, 2004 07:32 PM Thursday; Rod Welch

SDS fix scheduling a new task from a subject report.

1...Summary/Objective
2...Schedule New Task Restore Original Cursor Position in Schedule
3...Maintain File and Cursor Location in Schedule When Creating a Task
4...Schedule Maintain File and Cursor Location When Creating a New Task
5...Task Filenames in Schedule Periodically Changed to Sequential


..............
Click here to comment!

CONTACTS 

SUBJECTS
Start Command Method to Save Memory
Schedule New Task Fails Launched from SDS Record or from Diary Summa

0504 -
0504 -    ..
0505 - Summary/Objective
0506 -
050601 - Follow up ref SDS 1 0000.
050602 -
050603 - Changed SDS so that when a user creates a new task after calling a
050604 - subject report, which now occurs in a secondary memroy segment, then
050605 - the Schedule will be restored to the position same position when
050606 - control returns to the User in the primary memory segment.
050607 -
050608 -
050609 -
050610 -
050611 -
050612 -
050614 -  ..
0507 -
0508 -
0509 - Problem
0510 -
051001 - We have a problem with the function that schedules a new task from
051002 - within an SDS record, and from a Diary Summary report launched in a
051003 - second memory session, typically for subjects, but could also occur
051004 - for documents, files and contacts.  Problems seem to have started
051005 - after changing the design for assigning filenames for new tasks, which
051006 - was done on 040317. ref SDS 6 0001
051008 -  ..
051009 - The problem is manifested simply by failure of the Schedule screen to
051010 - restore the situation set by the User when the new task is created.
051012 -  ..
051013 - Since the new task is created and entered in the Schedule correctly,
051014 - this should be a fairly simple objective to accomplish by capturing
051015 - positional parameters in the Schedule where the new task is entered in
051016 - the 2nd memory segment, and transferring them back to the primary
051017 - memory segment where control is again returned to the User.
051019 -  ..
051020 - I think what should be occurring is that the new task is created in
051021 - the Schedule in the 2nd memory segment, and the positioning parameters
051022 - should be posted in the transfer file, so that when control is
051023 - restored in the primary memory segment, the User sees the condition
051024 - created in the 2nd memory segment.
051026 -  ..
051027 - Background
051028 -
051029 -    Virtual memory for Subject Index......... 030902, ref SDS 2 P15M
051030 -
051031 -    Virtual memory for Subject Report........ 030920, ref SDS 3 7S8I
051032 -
051033 -    Integration with virutal memory.......... 031014, ref SDS 4 0001
051034 -
051035 -        Create new macro file 0042
051036 -        to call 004 in a separate
051037 -        memory segment.
051039 -     ..
051040 -    Gary reported problem.................... 031022, ref SDS 5 0001
051041 -
051042 -        This record reports that work on 031014 should have solved the
051043 -        problem on 031022, so we should be able to work from 031014 as
051044 -        the lastest and greatest stuff on the issue.
051046 -     ..
051047 -    Modify filename assignments for
051048 -    creating a new task...................... 040317, ref SDS 6 0001
051049 -
051051 -  ..
051052 - The original orientation on this task was for the user to pre-position
051053 - the cursor in the Schedule before opening the Subject Index, and then
051054 - open the Subject Index and look up a subject and run a report.  When
051055 - the report is presented, then select a task to use as a template for a
051056 - new task in the Schedule.
051058 -  ..
051059 - This, however, is not a common scenario.
051061 -  ..
051062 - Typically, what occurs is that the User has done a subject report and
051063 - encountered a record which results in a decision to perform follow up
051064 - work.  Only then does the User recognize the need to position the
051065 - Schedule and the cursor to a location for scheduling a new task on a
051066 - particular date.
051067 -
051068 -
051070 -  ..
051071 - Line 720, ref OF 6 UD3I, -label anfisR in 035012 about 50 lines below
051072 -
051073 -    -if @1 = 36 -goto dsS
051074 -    -if @1 = 65 -goto rsant
051075 -    -if @1 = 78 -goto rsant
051076 -    -goto esc3
051077 -
051078 -        The problem is with the code in 035012 that manages transition
051079 -        between the primary and secondary memory, reported in the
051080 -        record on 031014. ref SDS 4 B33F
051081 -
051083 -  ..
051084 - Line 1150, ref OF 6 VY5N, -label rsant in 035012
051085 -
051086 -    Changed this design from the original idea of purging the Schedule
051087 -    file and opening it again, to instead, open the Schedule file, and
051088 -    if the profile flag is active, then this means the Schedule was
051089 -    already open, so enter macro 22 to save the initial position, then
051090 -    emtpy all but the top line, and then read in the content from disk
051091 -    beginning with line 2, since the top line is save, because this has
051092 -    proven to work better for applying marks, rather than removing all
051093 -    lines in a file.  With macro 22 called, the reset subroutine will
051094 -    work that calls macro 23 to restore the condition saved by macro
051095 -    22.  This solves the problem.
051096 -
051097 -
051098 -
051099 -
0511 -

SUBJECTS
New Task Schedule Restore Original Cursor Positioning Maintain User
New Task Schedule Fails Restore Original Cursor Positioning Causes L

0804 -
080501 -  ..
080502 - Schedule New Task Restore Original Cursor Position in Schedule
080503 -
080504 -
080505 - We have another problem with creating a new task with this procedure.
080506 -
080507 -    We need to capture the file and cursor positioning for the
080508 -    Schedule as a separate set of params when the Subject Index is
080509 -    launched, so that when a new task is created in the Schedule, the
080510 -    user can control the location of the new task.
080512 -     ..
080513 -    The code now enters all new tasks at the top of the Schedule when
080514 -    created in a separate memory segment that is used by the Subject
080515 -    Index.
080517 -     ..
080518 -    If a new task is created from a Diary Summary created with F3, the
080519 -    user can pre-position the cursor and the Schedule file to control
080520 -    where the new task is created.  But if a new task is created from a
080521 -    Subject report, then the new task is always created at the top of
080522 -    the Schedule where the user must then move the new task to a
080523 -    desired location.  This is a little awkward and more importantly is
080524 -    different.  We want consistent operations between common tasks.
080526 -  ..
080527 - Solution....
080528 -
080529 -    There are three (3) use cases to handle...
080530 -
080531 -    1.  The user is in an SDS record and decides to create a new task.
080532 -
080533 -        The user can switch to the Schedule, and position the cursor
080534 -        where the new task should be created.
080536 -         ..
080537 -        The user can then open the menu and open the Subject Index.
080539 -         ..
080540 -    2.  User switches back to the SDS record and use the Control Field
080541 -        to open the Schedule to a particular location in the organic
080542 -        structure of the Subject Index.
080544 -         ..
080545 -        The current code in 035012 captures the screen and file
080546 -        condition and passes this to the 2nd memory session where it is
080547 -        used to open the Schedule with Ctrl F6, when the Subject Index
080548 -        is opened from the Schedule.
080550 -         ..
080551 -    3.  The user is in the Schedule and decides to create a new task.
080552 -
080553 -        The user opens the menu and opens the Subject Index.
080555 -         ..
080556 -        The current code in 035012 captures the screen and file
080557 -        condition and passes this to the 2nd memory session where it is
080558 -        used to open the Schedule with Ctrl F6, when the Subject Index
080559 -        is opened from the Schedule.
080561 -         ..
080562 -    4.  User is in SDS record and opens Subject Index.  While in the
080563 -        SI, the user runs a subject report and opens an SDS record,
080564 -        and this leads to a decision to schedule a follow up task.
080566 -         ..
080567 -        The Use can switch to the SDS record from the Subject Report
080568 -        processor Q1 using Ctrl F6, and then use the Diary menu to open
080569 -        the Schedule and postition the file and cursor for the location
080570 -        (date) where the new task should occur in the Schedule.
080572 -         ..
080573 -        This requires a new menu function to open the Schedule, rather
080574 -        than use ecur 96, because when the Subject Index is opened, the
080575 -        operation is occurring in a second memory segment where ecur is
080576 -        not effective because the Schedule is not memory.
080577 -
080578 -
080579 -
080580 -
080581 -
0806 -

SUBJECTS
New Task Schedule Restore Original Cursor Positioning Maintain User

0903 -
090401 -  ..
090402 - Maintain File and Cursor Location in Schedule When Creating a Task
090403 - Schedule Maintain File and Cursor Location When Creating a New Task
090404 -
090405 - Line 140, ref OF 2 663M, -label start in 0042
090406 -
090407 -    On 031014 macro file 0042 was created to launch the process of
090408 -    creating a new task in the Schedule by setting up a call to 004 in
090409 -    a separate memory section. ref SDS 4 019I
090410 -
090411 -
090413 -  ..
090414 - Line 350, ref OF 2 F56I, -label sfao in 0042 about 100 lines below
090415 -
090416 -    getgbl 256 256
090417 -    -if @256 != 7296 -goto s1fem
090418 -    macro 22
090419 -    setcura 66 0
090420 -    addcnt 66 1
090421 -    addcnt 67 1
090422 -    setgbl 65 @65
090423 -    setgbl 66 @66
090424 -    setgbl 67 @67
090425 -
090426 -        getgble 256 256 and -if @256 != 7296 tests for when scheduling
090427 -        a new task occurs from within a subject report, because in that
090428 -        case the operation occurs in a secondary memory segment.
090430 -         ..
090431 -        Added new code to capture the file position and cursor
090432 -        position, using comparable code for opening the Subject Index
090433 -        that is accomplished with macro file 035012
090434 -
090436 -  ..
090437 - Line 370, ref OF 2 GE8M, -label sfao in 0042 about 130 lines below
090438 -
090439 -    macro 231
090440 -    top
090441 -    of 3
090442 -    loc_cur 3 70
090443 -    getgbl 65 65
090444 -    getgbl 66 66
090445 -    getgbl 67 67
090446 -    inscnt 65 0
090447 -    rel_cur 0 2
090448 -    inscnt 67 0
090449 -    rel_cur 0 2
090450 -    inscnt 66 0
090451 -    of 0
090452 -
090453 -        macro 231 opens the transfer file and it is offset to enter the
090454 -        file and cursor positioning for the Schedule where the new task
090455 -        is created.  These params are read by macro file 035012 to
090456 -        position the Schedule created by the User for creating a new
090457 -        task in the primary memory segment, after the Schedule has been
090458 -        swapped out for the file on the disk, per below. ref SDS 0 F56F
090459 -
090460 -
090461 -
090463 -  ..
090464 - Line 650, ref OF 6 5O5L, -label npfilu in 035012 about 50 lines below
090465 -
090466 -    -label npfilu
090467 -    --
090468 -    --
090469 -    e c:\sd\03\035012
090470 -    -gosub o00s
090471 -    -if @47 != 50 macro 941
090472 -    -gosub gsfcp
090473 -    ecur 15
090474 -    loc_cur 3 72
090475 -    -gosub fcprms
090476 -
090477 -        Open 035012 processor and call subroutine that opens the
090478 -        Schedule; if the Schedule is not already open with the cursor
090479 -        positioned where the User might want to schedule a new task
090480 -        then call macro 941 to set the profile, and the cursor will be
090481 -        placed at the default location, and that is where any new task
090482 -        will be entered.  This is currently the only positioning
090483 -        supported by the code for scheduling a new task from a Subject
090484 -        Report op in a 2nd memory segment.
090485 -
090487 -  ..
090488 - Line 1180, ref OF 6 VY5N, -label rsant in 035012
090489 -
090490 -    -label rsant
090491 -
090492 -        Decided to build some subroutines for opening the Schedule,
090493 -        since this occurs now at several locations.
090494 -
090496 -  ..
090497 - Line 2540, ref OF 6 1S5M, -label ntisrd in 035012
090498 -
090499 -    -label ntisrd
090500 -    setcnt 110 11
090501 -    ecur 15
090502 -    of 72
090503 -    loc_cur 3 1
090504 -    strcnt 65 3
090505 -    aw
090506 -    strcnt 66 2
090507 -    aw
090508 -    strcnt 67 2
090510 -         ..
090511 -        Code has determined that the op is returning from a Subject
090512 -        Index op that created a new task in the Schedule using a diary
090513 -        for a prior date from a subject report.  The code now has to
090514 -        restore the position of the Schedule set by the User in the 2nd
090515 -        memory segment by getting the params from the transfer file
090516 -        created by the code in 0042, per above. ref SDS 0 F44L
090517 -
090518 -
090519 -
090521 -  ..
090522 - Line 30, ref OF 3 H56M, 00507
090523 -
090524 -    markcur 73
090525 -    e c:\sd\03\00507
090526 -    line                                                       && *%fi
090527 -    loc_cur 4 12
090528 -    macro 856
090529 -    macro 841
090530 -    *%fi
090531 -    e d:\sd\08\uuuuu\00\00
090532 -    -if @47 = 50 -goto open
090533 -    macro 941
090534 -    setcnt 246 9481
090535 -    -label open
090536 -    *%sd
090537 -    *%sd
090538 -    purge c:\sd\03\00507
090539 -
090541 -  ..
090542 - Line 270, ref OF 7 SE7M, -label diary
090543 -
090544 -    ins_text "º Schedule                                  º"
090545 -    loc_cur 0 80
090546 -      ins_text " macro 94   "
090547 -      ins_text " ecur 96  "
090548 -    ins_text " @c:\sd\03\00507  "
090549 -
090550 -        Changed call from ecur 96 to the new macro file 00507, created
090551 -        today, per above. ref SDS 0 RM4I
090552 -
090553 -
090554 -
090555 -
090556 -
090557 -
0906 -

SUBJECTS
Schedule Task Numbers being Renumbered from 0001 Causing a Big Mess

1303 -
130401 -  ..
130402 - Task Filenames in Schedule Periodically Changed to Sequential
130403 -
130404 - Follow up ref SDS 6 056N.
130405 -
130406 - There is another problem that has been occurring from time to time
130407 - seemingly at random, because so far have not been able to replicate
130408 - for investigation and correction.
130410 -  ..
130411 - Somehow the filenames listed in the schedule, which are assigned by
130412 - macro 95, are overwritten by an unknown process to sequential increase
130413 - from 0001, so if there are 10 tasks in the Schedule they are named
130414 - 0001 - 0010.  Since these filenames don't actually, exist, and since
130415 - the actual filenames on the disk are no longer listed in the Schedule
130416 - 00 file, the files on the disk are deleted.
130418 -  ..
130419 - The launch process that backs up the 00 directory in total, makes
130420 - recovery certain and fairly fast, but this is a bit nusiance.
130422 -     ..
130423 -    On 040329 have been monitoring this for a few days, and so far the
130424 -    problem has not been duplicated.  Think we have been using all of
130425 -    the SDS capabilities.
130426 -
130427 -        [On 040330 Gary Johnson reported similar problem. ref SDS 7
130428 -        00V8
130429 -
130430 -
130431 -
130432 -
130433 -
130434 -
130435 -
130436 -
130437 -
130438 -
130439 -
130440 -
1305 -