Menu

#10 RB not updated properly after dyn. ren.

open-postponed
2
2005-01-20
2004-09-10
No

When dyn. renaming, the old selector disappears from
the RB, but the new selector doesnt show before
(de)selecting something.

Discussion

  • Adriaan van Os

    Adriaan van Os - 2004-09-10
    • priority: 5 --> 2
     
  • Niall Ross

    Niall Ross - 2005-01-20
    • labels: 520047 --> Refactoring Browser
    • assigned_to: nobody --> niallross
    • status: open --> open-postponed
     
  • Niall Ross

    Niall Ross - 2005-01-20

    Logged In: YES
    user_id=753646

    Since the deletion makes the code of the deleted method red
    in the browser, the user knows they need to click to update
    this browser. Hence, as Adriaan has noted, this is not too
    serious; we should find an elegant solution or live with it.

    It can be fixed by changing the #handleError: method's
    behaviour in the case where a proceedable warning has a
    parameter and the user returns a nil response to the
    confirmer.

    - The simpler fix is always to refresh the display of the
    receiver of #handleError: in that case. The argument would
    be that when the user choose to proceed via the third
    response, a refresh after they have completed will always be
    legitimate and often needed.

    - The alternative is to make the #handleError: receiver the
    parameter of the third option's block. I would like to leave
    such a change until we discover a more explicit need for it

    (The AddMethodChange can be given a reference to the
    controller but this updates the code window, not the
    navigator - see e.g the final lines of
    BrowserTextTool>>compileMethodText:from:.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.