anymore anyhow. The preferred method is to use javax.mail and deliver to
the local SMTP server over a socket.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1596 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Can be used to change the name of a column as well (I.e., the definition
is the same except you give it a new name.)
--This line, and those below, will be ignored--
M src/java/com/samskivert/jdbc/JDBCUtil.java
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1591 6335cc39-0255-0410-8fd6-9bcaacd3b74c
an invalid value. This was made extra hairy by the fact that the
FilterBypass installed on a Document implements replace() by simply
calling remove() and then insert(). That's fine and dandy and saves lots of
code, I'm sure, but the each of them fires an event, resulting in two events
when a replace() happens.
I Created a special Document that suppresses 'remove' events from firing.
Not a problem, because I've also structured the filter such that removes()
end up being implemented as a replace() (due to the filtering and
processing that we do to ensure that valid, properly formatted integers
are always displayed) so the 'insert' event will take care of all our needs.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1585 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Previously invalid values were allowed because the user could be on their
way to typing valid value. The field installed itself as a FocusListener
and checked the value when focus was lost. This wasn't ideal, as a user
could enter what they thought was a valid value and then click a button and
the action of them clicking the button would instantly change the displayed
value with no chance for them to see that it changed from they had last
entered.
Now it does clever highlighting to let you edit the field while always
keeping the value between the minimum and the maximum.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1583 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Also, realized that there was potential for a runaway task if two threads
called schedule() and cancel() simultaneously and the planets are aligned.
Cancel any de-fanged task in case it is a runaway.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1570 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the part about volatile variables, and that led me to this simpler
implementation.
Interval is no longer Runnable (good because it won't tempt people to post
the interval themselves), and I got rid of the less-than-sweet _fired
and _expired variables. The trade off? schedule() and cancel() are
synchronized, not a big deal, and the task needs to check if it is
being run on the dispatch thread, which shouldn't be a big deal.
The major plus is that the code is easier to understand.
The same amount of objects are created, and we don't do anything silly
like create a new object every time the interval fires.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1556 6335cc39-0255-0410-8fd6-9bcaacd3b74c
There may be chapter 17 issues, but I'm fairly certain that if there are we can iron those out without changing the API.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1554 6335cc39-0255-0410-8fd6-9bcaacd3b74c
RunQueue is now an interface that is very simple- it serially runs Runnables.
Removed Invoker.ResultReceiver, the invoker now takes a RunQueue.
The method to post a Runnable to RunQueue is called postRunnable(), rather
than the legacy postUnit(). postUnit() is the method name of the Invoker
to post Invoker.Unit objects, and I just figured it was better to keep those
distinct, since an Invoker.Unit is also a Runnable, it could be very easy
to post an Invoker.Unit to the wrong thing if not careful.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1553 6335cc39-0255-0410-8fd6-9bcaacd3b74c
entirely from old-and-busted crypt() to the new hotness MD5. This allows
us to interoperate cleanly with our soon-to-be new forum system which MD5
encodes a user's password before it ever leaves the web browser. Those
security conscious little devils.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@1551 6335cc39-0255-0410-8fd6-9bcaacd3b74c
andrzej