On Friday, May 30, 2003, at 13:53 US/Pacific, D20 Books and More wrote:
>> Wouldn't that be clasified as a bug then?
>> I would assume that there is a common routine that is used farther
>> down the logic stream that could be overloaded to do the file
>> save...but since I don't code that heavily (some, but not THAT much),
>> I'm not sure.
> This is an inherent problem with Mac OS X. This is not necessarily an
> issue with
No, it's not an "inherent" problem with Mac OS X. It may be a problem
with JRE, but *native* apps -- Carbon or Cocoa -- all have the option
of reacting to a close or quit event and saving anything that needs to
be saved. The only time this isn't a case is if the process is
SIGKILLed from, say, the CL. In that case, it just dies. But if PCGen
behaves like it's received a SIGKILL when the user closes the app,
that's an application bug, not an OS bug.
>> I do understand that one is probably the window manager (the "Close"
>> method") and the other is the app...so maybe it's not possible.
> Apple-Q will kill the application without writing the option.ini
> because this is a
> system call outside of PCGen.
Er, nope. The system generates an event which the app developer has
the option of watching for or not. Now, since PCGen is running on top
of JRE, someone should probably look at the JRE docs to figure out how
to catch the exception that the runtime is almost certainly throwing
when it receives the quit event from the OS.
> Ctrl-Q is the call within the application and will close down PCGen
> properly and save
> all the data necessary to the INI files.
That's a poor design decision and violates all the UI guidelines I've
ever read on *any* platform. It's a really bad idea to have two quit
commands that do different things, and there is almost certainly a way
around it -- if someone is willing to invest the time to look for it.
Might I suggest starting with the ApplicationListener interface from
the com.apple.eawt package?