Xinha Discussion Forum

Thanks. If you have a chance, please check out the code and let me know if you think it's easier to follow than the mainline Xinha code.

(post to http://www.formvista.com/forum.html ...)

thanks,

-- Yermo

If you have any questions, comments or patches about draglist please post them to the formvista forum at

http://www.formvista.com/forum.html

It'll make it alot easier on me to keep track of things.

Thanks!

-- Yermo

Ok. I've packaged what I have. It's now available for download at:

http://www.formvista.com/otherprojects/draglist.html

If you use it please let me know what you think and any suggestions on improvements. The code leaves a bit to be desired.

Something essentially free. Creative Commons Attribution sound good? The underlying dom-drag library uses that license which I think states that you just have to give me/my company some credit in the headers and you cant' claim you wrote it but otherwise are free to do with it what you want.

I'll package it up as a download once I get a chance. Maybe tomorrow.

I'm going to put up a sample of what it does so you can look at it. Am packaging it up right now.

You are a braver man than I.

Yea, I agree. But in order to be useful I need to have onENTER appear to the enduser as if it were just a linebreak as we had discussed. (using stylesheet entries). Without that my users will cry foul.

For it to work for me I'd have to recreate EnterParagraphs for MSIE to do the same thing. I'm afraid I don't have the time for it right now. I've already spent much longer coming up to speed on this codebase than I had planned for.

I'll have to tell my users to use FireFox, which in my case I can get away with for the moment. I will have to address this at some point before too long; primarily because my business partner really wants to control things from stylesheets (our paying users could care less.)

Enterparagraphs was such a painful piece of code to work through. At least I got it to the point where it's almost working. It should be easier for someone to pick up and run with the version of unified_backend than the trunk. I put alot of work in trying to make the code more understandable, at least for me.

I was looking at it cross-eyed. Disregard.

Gogo has identified a race condition in the code I put together. It works but right now it looks like there may be a potential problem.

I haven't seen any problems with it in all my testing over here but I agree there's an issue that will have to looked into. Right now it's not clear why the code is working as well as it is.

Hmm. If I read the mozilla bug report right then we have to have some contents in the iframe before being able to set designMode on but I may have misread that; something about a body tag being necessary.

I'll have to experiment with it to see.

Is there any reason why we can't move the iframe.src = ... down to after adding the event because you're right, it looks like a race condition.

For that matter how does the panel code work. Is that a race condition as well? Does the iframe.src get loaded "in the background"?

Hmmmm.

Hmm. By default the EnterParagraphs plugin is turned on which will mess things up pretty badly. Do a search for mozParaHandler and set to "built-in". You might notice less weird behavior. (Actually in my fork I've fallen back to making the default "built-in" which means the browser's internal handler will dictate the behavior on enter key press. Getting EnterParagraphs to work in all cases is going to be a ridiculous amount of work.

Aside from that the only thing I can think of is some mishandling in HTMLArea.getHTMLWrapper() which does do some search and replacing. 

I also haven't had too much luck with the stylist plugin but I haven't played with it much.

Yea, I built a set of discussion forum components for my framework and ended up making them plain text as well for the same reason.

However, with these recent fixes I'm probably going to try enabling the editor to see how it goes.

I should have an installable AreaEdit package put together before too long ... although allergy season here on the US east coast is making things go a bit slowly.

Already been working with Gogo on it.

http://xinha.gogo.co.nz/punbb/viewtopic … 1579#p1579

What other bugs are you seeing that you want addressed? (Other than EnterParagraphs stuff)?

Yes, for the debugging enabled version of AreaEdit (if the trace window is turned on) I'm hoping to make something like this happen. What complicates things is that you don't know what state the browser is in .. depending on the particular bug things can get tricky.

Actually I would prefer seeing the entire trace from the beginning when the editor was started ... so what I would probably want to do is give clients a way, as part of a customer support call, a way to turn on the "debugging version" which pops up the trace. Let them reproduce it that way and then send the report.

In our experience, when tracking down the weirdest of errors this kind of tracing tends to work best interactively. Having customer just send random traces with a few messages probably won't help much (at least for me). I also find that I am most successful in tracking these things down when I can walk a customer through the specifics of a test so I can get a good trace.

BTW, if I have my way there will be no more timing problems in this codebase. I'm in the process of getting rid of all the setTimeout() calls I can.

I think we're both thinking the same way. We both clearly have important customers that need to be supported and are running into the same problems.