clio katz

i don't know if you have run the examples included in the dist, but the bulk of the lf5 stuff is for logging to the lf5 gui console.

i don't think any of the lf5 packages is tailored to directly talk to misc swing component, but they do give you alternatives: you can pick up log messages from a socket, or from a database.

jswat is a good example - it can be configured for debugging using socket ipc

another option would be to write a wrapper to "tee" log messages to your app and also to log4j. [if you're familiar with the unix tee cmd...]

in unix, you have plenty of ipc options. but i must comment that this is potentially a very io-intensive task for a swing app, especially if you plan to handle it in a jtextfield - i think you'll prefer lf5 console once the swing q gets bottlenecked but

hth
[and happy holidays!]

i don't know of any way to get back the authentic html [perhaps a deep dump of the obj might reveal a secret cache], but - in theory - you should be able to reconstruct the meat of it by 'serializing' the Document obj. i'll explain.

as i understand it, java is able to do the rendering you are describing via model and view classes. the view is what gets rendered, the model is the nodal representation of the underlying html parse tree.

to make a long story short, i would try traversing "the structural portion of the subject that this view is mapped to" (ie. the document)

From the document root node (Element), you can traverse all the elements and attributes and 'serialize it' back to html.

there are classes to help with the serialization somewhere in javax.xml or org.xml .. you would use the relevant html dtd (or something simpler) for the schema.

i hope someone else can suggest a shorter way to do it...

hth

i'm not a print expert, but i *have* printed formatted pages using HTML doc kit. actually, i did some research and i came to a standstill with all other methods (unless you want to use pure graphics).

essentially, you have to consider that java printing just renders what you 'paint' onto a graphics device (e.g. printer) using the graphics canvas you give it, and the attributes that you assign the device [o, but don't try too hard to force any device characteristics... java is not very smart about detecting the true device capabilities...]

so if you choose to try this, the first step would be to get your text html-formatted [several jcomponent classes are capable]. you will have to find or write code to translate special chars like newline(<br> , and use java's fuddy old version of html...

perhaps that is what you meant to achieve with attributedstring? i think this is just for specially annotated text ...

hth

as a start, i would suggest looking at some articles on model-view-controller approaches. a strain of this approach was used in the design of JTable, and you can see the same pattern in other component designs like JList JTree etc.

to answer your question, you almost certainly don't want to expose public getters and setters for your data fields ... this is where a controller can save you some major nightmares.

lastly, you'll want to read some previous posts about the Swing Event Queue. if you're not familiar with the issues there, i'm afraid you soon will be :-T

hth

based on your code snippet, you are displaying your output on the console, not using swing.

if you decide to use swing, you can look into using jcomponents that support rich text (eg JLabel using HTML markup).

if you stick with the console display, you can only output colored characters if your operating system supports colored console chars, and if you know the OS control codes to trigger the color attributes ... not a recommended strategy but there have been those who've done it:-)

hth

You may have already discovered that - in addition to needing panels - you will need to arrange the components inside of other containers with particular layout managers ... I would suggest using gridbag layout ... You may want to research the Sun docs on this ... it will also explain how containers like JPanel are necessary for organizing other swing components in the frame. good luck!

if you're dealing with sql and java 1.4+, it will probably be helpful for you to review the java.sql and javax.sql API's right off

e.g.
java.sql.Date dtSql = new java.sql.Date(System.currentTimeMillis()); System.out.println("Date in JDBC escape format = " + dtSql.toString());

if you don't have these packages, you can use milliseconds or Calendar class to construct a SQL DATE in the desired format.

hth!

i'm curious too, because based upon your dump, it is actually sb.length() that is "at fault".

i would not be surprised by this, because we can't tell from anything we've seen so far that the charAt(sb.length()+{1...3}) is not being treated by java as '00' (null) ... especially if it's coming from reading a file.

... if you tried to access it [sb.length()+n], you'll undoubtedly get an indexoutofbounds exception

now i'm really curious

it would be instructive to see:

dump of ascii code of each char read by the pgm

final counter from read op (how many times was sb.append() called?)

reported sb.length()

sounds very much like a java bug, but that would depend on the details of this particular scenario ... control chars can be very confounding...

great work! accept my praise for your persistence and follow-through - rare qualities. you pulled together many complex/confusing bits into a working whole - you have yourself to thank.

you probably already solved your packaging issue, but since you asked my opinion: having them in separate pkg/class probably fits best w the reusability goal

at the rate you're going, next time i expect to be thanking _you_ for help:-)

it seems there are really only 2 possibilities:

sb.length() is being mis-reported [confused by dbl-newline], OR

System.out.print() manages to eat the post-dbl-newline chars

you can rule-out #1 by verifying the length is correct before you print:

System.out.println(sb.length());

you can rule-out #2 by printing the ascii code of the char along with or instead of the char - eg:

System.out.print("["+ ((int)sb.charAt(i)) +"-'"+sb.charAt(i)+"']");


can you try this? it's not clear to me whether or not print is being called after the double-newline is encountered...


MISC NOTE: if the file is expected to come from a different OS environment, it may contain different newline char(s) than the client's native OS ... the foreign newline char(s) may be handled differently on the client's out

have you tried setting alpha interpolation?
// alpha interpolation quality graphics2d.setRenderingHint(RenderingHints.KEY_ALPHA_INTERPOLATION, RenderingHints.VALUE_ALPHA_INTERPOLATION_QUALITY);

i've had similar probs, but i'm using 1.4.x. some probs were related to bizarre behavior following a load of window events

i don't know why the focus is lost - there have been several focus mods to awt and swing, and focus defaults are also influenced by platform (esp pre 1.4)...

have you tried

requestFocus (1.3)
requestFocusInWindow (1.4)

on the component(s) in question? (you would need to invoke requestFocus/requestFocusInWindow after the component is visible.)

however, this may not give you the granularity you want in focus retention...

worst case, you can try writing an intelligent windowListener to save/restore focus on windowActivated etc

good luck!

Hi Tom,
I think you're just nanoseconds away from working your way through - what i think of as - a pretty advanced programming task!

Don't be turned off by the event stuff - it's pretty quick to write once you assemble the pieces: event class, listener interface, listener.

you don't really need to think about using an event adapter until you have more than one event (an event adapter is just a programming convenience, so your eventlistener instances can pick and choose to override methods in the interface...)

on the design side, either Timer or Mail can start the checkMail thread. since you'll be firing an event at completion, you won't need to synchronize/join threads. when the task finishes, your listener will be notified of the event, and java implicitly zombie-fies the thread.

my pref would be to use one thread per distinct mail account. your Mail class can be the thread 'controller'. timer event just needs to trigger a Mail fetch ... Mail class can ignore the call if a thread is already running for the given mail acct

however you will want to use more than _isAlive() for checking thread 'state'...

why? java threads are a little dodgey when it comes to querying or managing state - i'm sure you've read about this. you will need to set and check your own state var(s) so that you can manage execution (stop, interrupt, 'isExecuting', etc). Thread.stop() is a no-no ... you basically have to write code to give the thread a poison pill (as needed)

on to your central question: your event listener uses the same mechanisms as the other java listeners (actionListener, windowListener etc). once you register the listener (eg _addActionListener), it's like registering a callback: java will load and run your listener-associated code whenever the so-named event (actionPerformed, windowClosing etc) is fired.

to try to clarify 'flow', i'll sketch out a skeletal design:

model
Classes

RootWin

Timer

Mail

MailUpdateEvent

Interfaces

MailEventListener

code fragments
(see above code for MailUpdateEvent class, MailEventListener interface)
// // to simplify, rootWin can be our eventListener // public class RootWin implements MailEventListener { // member vars JLabel lblMailCount; Mail mm; ... // methods public void setMailCount(int count){ // see prev post:-) ... } // MailEventListener "MailCounted" event handler // // ==HERE's where the Mail info gets to the GUI== public void mailCounted(MailUpdateEvent e){ //setMailCount( mm.getMailCount() ); // // or .. more like ... Mail mail = (Mail) e.getSource(); setMailCount( mail.getMailCount() ); } }

i know i'm forgetting things (like inner-workings of Mail class!), but i hope this helps to get you started ... let us know!
[ August 21, 2004: Message edited by: clio katz ]

Hi Tom,
I know my previous posts have been kind of dense, but I'll try to cut that out:-)

Basically, you will be able to design the mail thread in the way that best suits your needs. you can design it as

(1) a reusable component (operates same way each time, regardless), or

(2) a specialized class, with access to the caller's resources (i.e. it can directly or indirectly 'know' about and manipulate GUI view resources)


My first response was a strategy for case #1. This is considered a java/oo 'best practice', and it is the basis for the "bean" concept. a bean is just basically a reusable component.

in case #1, you would write an event class to represent the real-world "you've got mail!" event. (i called this the "MailCounted" event) Then your Mail thread would do "fireMailCounted()" when he's done. somewhere else you would have an eventlistener ready to 'do the right thing' when the event is fired..


... but there's nothing wrong w opting for strategy #2!

w strategy #2, your Mail thread will be designed to be a member/inner class of the invoking class. in this scenario, the Mail instance can get access to the caller's resources (such as class-accessible methods/variables).

For example, if the caller has a method

public void setMailCount(int count) { final String strCount = String.valueOf(count); SwingUtilities.invokeLater(new Runnable() { public void run() { lblMailCount.setText(strCount); } }); }

the Mail thread can invoke it...

that's just an example - the design options are open. but i'll stop right here before i get to blabbing on-n-on

hth:-)
p.s. thanks for your feedback! it's valuable to know if responses are helpful or not

bravo to you for your hard work and persistence, Celine! i myself learn better by example than by instruction, and so i have benefitted from the wealth of java examples on the web. i'm glad to give back when i can.

thank you for your feedback - 99% of the time i never hear anything so i don't know if i'm helping or harming ... it's nice to hear back, and nicer to have actually helped for a change:-)