Custom Query (431 matches)


Show under each result:

Results (91 - 93 of 431)

Ticket Resolution Summary Owner Reporter
#105 fixed DSI error when try to reopen YAM from its appicon (both YAM's and mailbox) Thore Böckelmann Phantom

This is not happening all the time, but quite often. When I run YAM to check my messages and iconify the program, when I try to reopen YAM to check for new arrived messages via the mailbox appicon or its appicon of YAM sometimes I got a DSI error, which is attached here. MUIMaster library problem?

#299 invalid DSI error when trying to load external MUI Classes in About requester Phantom


I got a DSI error everytime I tap to load the external MUI Classes in About requester.

#440 fixed Dangling directory locks when MUI first started Thore Böckelmann Mike Steed


When the first MUI application is started following bootup, it leaves dangling locks on its home directory when the application is later quit, which prevent the directory from being deleted. I don't know if this is a bug or just an aspect of MUI operation. If the latter, it's easily mistaken for a bug.

The scenario is that someone downloads an archive and unpacks it onto the RAM disk in order to evaluate the program. Whether they decide to keep it or not, they eventually will want to delete the drawer on the RAM disk. When they are unable to, it leaves a poor impression as to the quality of the program.

Steps to reproduce

  1. Start with a freshly-booted system, with no MUI applications running.
  1. Open the MUI drawer and drag the Demos drawer to the RAM Disk. Open

the Demos drawer on the RAM Disk.

  1. Run one of the demo programs. It doesn't seem to matter which one-

try Aboutbox. Immediately quit the program.

  1. Close the Demos drawer and try to delete it.

Expected results

The drawer should be deleted.

Actual results

DOS throws an "Object in use" error, and the drawer is not deleted (though all of its contents are).

Running Scout shows two locks remaining on the Demos drawer, which is what prevents it from being deleted.


The dangling locks only appear the first time a MUI application is run after booting. Running that demo or another afterwards does not add any additional locks.

If Scout — itself a MUI application — is run prior to running a demo program, then everything works fine- there are no dangling locks, and the Demos drawer can be deleted. Of course, Scout's home directory may then get the dangling locks, but there's no easy way to tell.

Some MUI applications seem to get dangling locks the first time they are run, even if other MUI applications have been run previously. My current project is one. YAM (the latest nightly build) seems to be another. Both programs use TextEditor.mcc, which makes me suspicious.

Indeed, running the TextEditor demo program, even after running one of the MUI demos, leaves two dangling locks on its home directory. So using TextEditor.mcc (perhaps any disk-based custom class?) the first time after booting seems to generate the dangling locks, too.

This issue has some similarities to ticket 200, and running FlushMUI does clear the locks and allow the drawer to be deleted. But why would MUI need to keep locks on the program's directory, and not any of its contents?

Note: See TracQuery for help on using queries.