This is OPENSTEP-BUGS.txt in view mode; [Download] [Up]
//-----------------------------------------------------------------------------
// SokoSave OPENSTEP BUGS
// $Id: OPENSTEP-BUGS.txt,v 1.1 97/12/10 07:06:20 sunshine Exp $
//-----------------------------------------------------------------------------
BUGS:
----
FIXED:
-----
v10.1
- New "level" is not getting recorded when a level is completed.
- When the game is solved, the AppKit always throws an exception stating that
there is a non-positive window number. This happens after the event
handling the movement which caused the game to become solved, whether
it's done with -performSelector:afterDelay:, or with notifications.
Apparently this only happens if the score panel has not yet been
launched. [This is a bug in MCGHTableScroll, calling -lockFocus in
-drawRow: without first checking -canDraw. I originally worked around it
temporarily by making the window non-deferred. Ultimately I replaced
MCGHTableScroll with NSTableView.]
- "New Score" panel lets user resize in both dimensions, but it only makes
sense to resize horizontally. This is also a bug in the NEXTSTEP version.
- When opening a saved game with the window deferred, the NSSlider doesn't
get drawn. This is also a bug in the NEXTSTEP version. [SokoBoard was
incorrectly & unnecessarily calling -sizeToFit on the slider. For some
reason on deferred windows this has the side- effect of setting the
slider's frame-size to (0,0).]
- New and Open panels fail to restrict the allowed file types. This is also
a bug in the NEXTSTEP version. [Problem was that they were using the
inherited -setRequiredFileType: method which seems to be ineffectual in
OpenPanel. Now explicitly uses -runModalForDirectory:file:types:.]
- Under Rhapsody, SokoBoard fails to compile on account of the deprecated
-makeObjectsPerform:withObject:.
- Under Windows, the lazy loading of the first maze in
-applicationDidBecomeActive: never takes place since this message does
not get sent until there is a window on-screen. Must make special-case
for Windows so that a maze is launched in -applicationDidFinishLoading.
- Under Windows, failure to load default maze incorrectly leaves the
application dangling with no windows on-screen. If +nextMaze fails, it
should try to load first-maze. In the event that this fails, inform the
user with a warning panel and either die, or give the user a chance to
open a maze with the New or Open panels.
- Under Windows, PSadjustcursor() does nothing. (click-on-crate still works,
but the mouse simply stays in one place.) [Fixed by making native
Windows calls.]
- Under Windows, the Scores panel has an application menu.
- Under Windows, the application icon does not display on the Info panel.
[Fixed: Now uses "SokoSave" icon rather than "NSApplicationIcon".]
- Under Windows, creation of Library/SokoSave directory fails.
[Fixed: Documentation was incorrect about first object in array returned
by NSString's -pathComponents used by mkdirs().]
- Valid saved game reports corrupted number of moves/pushes when reopened.
To reproduce:
1) cmd-n start a game
2) cmd-S save the game (without making any moves)
3) cmd-w close the game
4) cmd-o open the game (get error message about corrupt moves/pushes)
This is also a bug in the NEXTSTEP version.
- When the history in a saved file has length 0, -[SokoBoard loadSaveFile]
incorrectly calls malloc(0). This is also a bug in the NEXTSTEP version.
- mkdirs() doesn't work for Windows Universal Naming Convention (UNC) paths.
Unfortunately, -pathComponents returns "\" as the first component, which
when passed to +pathWithComponents: results in a path which starts with
"\" rather than "\\", which is no longer a UNC path. [Fixed: Rewrote it
to visit directories bottom-up rather than top-down.]
- The preference panel needs to grab a new Level value each time it is
launched. Otherwise it might have an old value in it -- since the Level
can change just by playing the game.
- Opening a saved game can report "corrupt recorded values". To reproduce:
1) solve and save game
2) undo two or more times
3) make a move which is *not* in the history
4) save game
5) close game
6) re-open game (get error message about corrupt recorded values)
The problem is that at step 3, the history gets truncated. Yet the load
function asserts that the "recorded" moves & pushes are less than the
history-length, but after the truncation this assertion is not valid.
This is a bug in the NEXTSTEP version also.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.