A Warning

So, instead of modifying any existing class, it is better to either create a copy of an existing class, or to create a new empty one and copy some methods over from the original one.
Then test & debug the new class for perfection.

Of course, when done, you should override the old class with the class "Class"-"Rename" function, and avoid code duplication.

This approach is especially suggested when you modify classes which are used by the system itself (for example: container- or UI-classes), since bugs in those may lead to subtile errors or even crashes.
(Just consider modifying ScrollBar to make it err somewhere; since the Debugger uses scrollBars too, it may have problems coming up. As a result, you might be forced to quit Smalltalk and restart your session, unless you are able to undo your change in the MiniDebugger).

We suggest that you save a snapshot image BEFORE starting to modify any critical system class - actually, its a good idea to do regular snapshots in any case. Then, you can resume from the last snapshot and examine and reapply individual changes using the ChangesBrowser.

Problems

Since the source information in a method is simply the filename+filePosition, this information is wrong after such a change.

A recompile (using stc) followed by a relink of the Smalltalk executable, should give you a version with correct (up-to-date) source information. (however, the demo version does not include stc - here you have to undo any outside world editing, and only change methods from within the SystemBrowser).

We recommend use of the sourceCode manager, which is able to access a classes sourcecode from the source repository, and does not need source files.
Here, the above problems are unlikely to occur (unless someone changes the classes version identification manually ...)

Copyright © 2000 eXept Software AG, all rights reserved