| Re: Xinha (Htmlarea continuation) ¶ | |
| It's also kind of sad that the folks at Xinha don't say anywhere that Xinha is started from code 100% developed by Dynarch.com. People just don't get it, it's me who wrote it, not InteractiveTools—they only payed for it, or actually, for what was it 2 years ago. Well, perhaps this is the best example showing that brand does matter. :-(
OTOH, project Xinha looks nice. I have no doubt that they are good programmers and I wish them luck. Yes, I do plan to continue development. I didn't lie. As a matter of fact, I am continuing the development—I just don't have the power to deal with hundreds of people submitting bug reports and asking for help, which is why the development is being done “in house”. HTMLArea is dead, but the code isn't and even Xinha shows that.
| |
| last | Edited by mishoo on 2005/03/12 17:34 |
| HTMLarea Help ¶ | |
| Quick questions here I hope you can answer... I have htmlarea installed into a cms of mine and it works perfectly on my linux hosted site. The Windows-based hosting gives me some crazy error messages about some buttons not being defined, and after it loads up, all the regular buttons are visible but there are some extra blank buttons that are all called undefined floating around the toolbar... Are there any known windows issues for htmlarea that would do this? Thanks in advanced, and I hope you have good luck in the future with your new htmlarea-based project :) | |
| last |
| Re: HTMLarea Help ¶ | |
| Well looks like I found my problem on the old HTMLArea forums... basicly there must be some variable that is the same in the manu script I am using that messes up the htmlarea editing window... funny enough its really the only difference from the one that cries... so seeing as the editing wityh htmlarea part is done using a mod for this cms I am using, I added in a new header.pl file which is basicly thr header of the site called headerapage.pl and called that from a new print_top page on the pages where htmlarea would be called... now no menu visible when using htmlarea to edit files, which is fine as its not a public page... One problem I know exists is the popup windows in IE... for some reason they are just a little short and cut off the "save" / "Reset" buttons on the bottom of the popups... this doesnt happen in firefox... any clue on where I can edit the size of the popup windows as to add in some more space to allow these buttons visability? thanks in advanced!!! Mishoo da Man!!! | |
| last |
| HTMLArea Forums ¶ | |
| Looks like they put up the old forums in an archiveal fashion... so read only!!! check it out here: http://www.htmlarea.com/cgi-bin/forum/gforum.cgi?login_attempt=1&&first_login=1 It seems you do have to be logged in to see the forums for htmlarea 2 & 3 WooHoo!!! Also there is a mention on the site from some guy named Dave about how HTMLArea is "discontinued & Retired" and about how they dont know if you (mishoo) are going to be continuing development, and if you were they would list your project, So, how about coming up with a new name and getting yourself listed for the New htmlarea because for some reason they keep pointing everyone over to that whazoo or whatever its called script as the next htmlarea when we know there can only be one tru HTMLArea when its written by you... | |
| last |
| client side image resize ¶ | |
| I am using the base code of HTMLArea (very well done) to create a unique essay editing enviroment for an online educational program. A request is to disable the ability to click and resize images. Is this possible? | |
| last |
| Re: client side image resize ¶ | |
| To the best of my knowledge, not. That's one example of a browser “feature” that you can't get rid of... | |
| last |
| patch handling ¶ | |
| Mihai, Do you still want us to submit patches to sourceforge? Will you or someone else be handling these? I am glad that HTMLArea is remaining as a distinct project, I think it retains a strong body of users, some of whome, as you say, need support and fixes, and some who can contribute fixes. Do you still want patch files submitting? Sam | |
| last |
| Re: patch handling ¶ | |
| Well, I'm sorry to have to say this but I'm too busy to keep an eye on SourceForge. On top of that, I am using an in-house CVS for some time and for this reason InteractiveTools has excluded my sf.net user from the HTMLArea project admins, which means that I'm not able to commit there anymore. But, this also means that the version that I have is highly modified and external patches wouldn't probably apply anyway. | |
| last |
| The editor slowing down ¶ | |
| Okay, I know this is an topic brought up a lot. I've been wondering if anyone has interesting ideas to stop the editor from slowing down in IE after x reloads. In my situation, closing the browser window, is unfortunately absolutely not an option. So, I needto get rid of this slowness somehow. I thought of removing every HTML element in the iframe manually, and/or all the events, etc. But I doubt it will work. Then, there's also my other idea. I loaded the editor in an IFRAME, and when the editting was done/cancelled, I'd remove the IFRAME. No luck either. The memory is still being leaked. I can fix so many problems in all of my plugins, and stuff. But this is the only one that simply keeps crossing my path every now and then. Maybe someone else has a creative idea which might make the problem 'less worse'? | |
| last |
| Re: The editor slowing down ¶ | |
| Yes, use Firefox. The memory leaks should be fixed in Internet Explorer, not in our code. Fixing such a huge application like HTMLArea could take months and I just don't have the time to do it :-( I'm sorry about this. If I knew about the IE memory leaks from the start, I would have coded HTMLArea “accordingly” (meaning, the code would have been ~1.5 times bigger and more bloat, just to work around this stupid browser problem), but since I didn't and the code already got big, the solution is—use a better browser and tell your friends, family and customers about it. :D Waiting for a new IE isn't a solution because this memory leak is there since ancient times (IE4 or so). | |
| last |
| Xinha ¶ | |
| Hi, Firstly I would like to say thank you for HTMLarea. It is a great project and has served me well. From what I've read you could offer a lot to the future development but can't support it. Why not join forces with Xinha? From what I've seen they've taken the project forward and have set up a good infrastructure for support and regular updates. Best Regards, | |
| last |
| Default Font Size ¶ | |
| Hi Mihai, First of all thanks for your great application. Very nice ! Thanks for your reply Steve | |
| last |
| Same Origin Policy Problem across Subdomains ¶ | |
| Suppose I want to generate a page in PHP that contains a htmlarea editor. Easy enough. Now suppose i have a site that for performance reasons requires static content to be served from a separate server to the PHP content (the "static" server wont be running PHP, and the PHP server shouldn't serve any images/javascript or we'll loose the performance edge that we gained by splitting the content up.) It still seems relatively easy at this point just to shift htmlarea's folder over to the static content server, and point to it from the generated PHP page. So far so good. Except that when using anything in the editor that requires a popup window, it wont be able to access the original editor because of the Same Origin Policy within javascript. Now, Mozilla.org very kindly tells us how to get around this if the 2 servers are subdomains of the same domain name - you insert the line document.domain = "mydomain.com", and thus allow script from www1.mydomain.com and www2.mydomain.com to access each others properties. Problem is, with that line added in my page (the generated PHP page), the editor never finishes loading. I've tried relocating the document.domain line to just about every one of the JS files (and all at the same time), and various locations on the calling page, all to no avail. Has anyone else had this problem, or better still - a solution? thanks bill | |
| last |
| HTMLArea 2.03 Question concerning Image Links ¶ | |
| First of all, I must congratulate you on creating such a fine and practical product. I've made a couple of minor modifications to the javascript code that suppresses the display of the toolbar. Essentially I use htmlArea as a container for table listings and such. Very convenient when table listings are long and scroll bars automatically appear. Display unlimited information within a predefined space. The inserted tables contain link images that a user can click on and invoke some ofther function. If the links onclick event has simple stuff such as javascript:alert('hello there') then everything works fine. If I attempt to call a defined function, such as javascript:showModalDlg(), then nothing works. Ideally, I want to call the showModalDialog function with the second parameter passed as an array, but HTMLArea does not seem to like that. Am I running into an limitation issue with HTMLArea, or is this some sort of javascript issue that I'm encountering? Should I use some other technique to display unlimited infromation within a predefined space? Any clarification or assistance with this issue is greatly appreciated. Thanks in advance, Ian Renfrew The following is a sample display of what the HTMLArea information could look like:
The following is sample code used to display the above information: function showModalDlg() { html += '<tr align="left" valign="top" style="font-size:8pt;">'; var color = "silver"; html += '<tr align="left" valign="top" style="font-size:8pt;">'; htmlArea_setHTML('txtResults',html); | |
| last |
| Re: HTMLArea 2.03 Question concerning Image Links ¶ | |
| No need to respond. I've answered my own question. Essentially using HTMLArea is overkill. All I needed to do is utilize the contenteditable tag. <div id=oDiv contenteditable ALIGN=left STYLE="height:95%; width:100%; background-color:gray; overflow=auto;"> ... Ian | |
| last |
| Firewall issue ¶ | |
| I'm running htmlarea 3 in an app which works fine on local network but when I upload to a live site htmlarea refuses to load. What's more bizarre is my firewall seems to block access to the site for a few minutes. If I disable my firewall I can access htmlarea on an external site in the usual way. Any ideas? Regards Stew | |
| last |















