RTE 3.0 b2 input/output to Access 2000
Printed From: Web Wiz Forums
Category: Web Wiz Web App Support Forums
Forum Name: Web Wiz Rich Text Editor (RTE)
Forum Description: Support forum for the Web Wiz Rich Text Editor (RTE).
URL: https://forums.webwiz.net/forum_posts.asp?TID=13777
Printed Date: 28 March 2026 at 9:23am
Software Version: Web Wiz Forums 12.08 - https://www.webwizforums.com
Topic: RTE 3.0 b2 input/output to Access 2000
Posted By: dj1811
Subject: RTE 3.0 b2 input/output to Access 2000
Date Posted: 11 February 2005 at 3:30pm
|
#1) I would like to have the RTE textarea input be taken from a database. For example: <textarea name="textarea" cols="80" rows="15" id="myTextarea">
<% rs.Fields("RTE_text") %>
</textarea>
<% rs.Fields("RTE_text")=Request.Form("textarea") %>
Is there anything special I need to know before attempting to do this? Are there any examples out there i can work from? Which page/s do I need to edit? How are the HTML tags stored: <b>Hello</b> or <b>Hello</b>?
Sorry for such "noobie" questions! Also: Thank you very much; this is a very cool program. I was going to write my own but it would have taken forever and the final product would not have been 1/2 as nice as this!
Mike
|
Replies:
Posted By: dj1811
Date Posted: 12 February 2005 at 2:23am
|
Got the first part working easy enough. Kind of embarrassed that I even asked now!
I think I'll be able to get the second part almost as easily. Very nicely documented.
|
Posted By: dj1811
Date Posted: 12 February 2005 at 3:22am
|
I got this working quite easily. If I notice any error/bugs I'll let you know. |
Posted By: dj1811
Date Posted: 12 February 2005 at 3:03pm
|
Here a couple of early impressions of the RTE_setup.asp in ver3 b2: #1) http://www.asphelp.com - <% Const blnFontStyle = false %> does not block the FontStyle dropdown from appearing on the RTE form.
Also a couple of observations about the editor in general:
#1) I wish it were not possible to drag the button imgs on the RTE toolbar into the textarea. Much of the work I do in web design is volunteer work for non-profit orgs.. and I can see already see that if I were to incorporate the RTE into a website the people I work with (older people, computer illiterate people, disabled people, etc) will be dragging the icons into the text area.
This really isn't crucial of course, but just a suggestion if it were easy to implement.
#2) Also would be nice if the if the RTE reused <SPAN> tags. Or deleted empty tags. After editing the same field multiple times in the RTE the HTML starts to look like <SPAN font.....></SPAN><SPAN font...>TEXT</SPAN><SPAN font....></SPAN> etc.
*******************
The only thing that is a serious issue is #3 above. The rest of the stuff is just a few suggestions; in the event you wanted some feedback.
Overall I'd say the RTE works extremely well, seems stable & relatively bug free. It's a very fun & cool little program & thanks very much!
|
Posted By: dj1811
Date Posted: 12 February 2005 at 3:08pm
|
UGH! again I post too soon! I apologize; #3) the const's not working... that was my own fault ...
Of course they don't work when you don't upload the setup file to the server...
Silly, me.
 |
Posted By: GerS
Date Posted: 12 February 2005 at 4:53pm
|
I was shocked about the constants not working...
 and tested it immeditately. Glad we now both know it's all all right! Another remark about your #1: drag the button imgs on the RTE toolbar into the textarea.
I tested this in the online demo of V3 B2 and got runtime errors after putting an icon of the RTE toolbar in the form. (run time error, object expected, pointing to the html in the textarea).
Can anyone confirm this?? ------------- Ger |
Posted By: dj1811
Date Posted: 12 February 2005 at 6:40pm
Yeah I get the same.
It's the javascript effects on the toolbar buttons.
|
GerS wrote:Posted By: dj1811
Date Posted: 12 February 2005 at 7:43pm
|
A bug found in MSIE 6.0.28:
Step 1) Press "Reset Form" button once, and it works normally.
Step 2) Enter a line of text then hit the "Enter" key so there is a blank line following text.
Step 3) Press "Reset Form" button again.
Step 4) Enter a line of text then hit the "Enter" key so there is a blank line following text. BUG: Now the <P> tags are not being replaced by <BR>'s.
Step 5) Press "Reset Form" button one last time.
Step 6) Enter some text. SECOND BUG: Now the text has a white background. |
Posted By: dj1811
Date Posted: 12 February 2005 at 9:37pm
|
More on <P> bugs in MSIE 6.0.28 (have not tested other versions of MSIE): Step 1) Reset Form
Step 2) Type the letter "A". Switch to HTML view. HTML formating is simply "A".
Step 3) Switch back to the RTE and backspace over the letter "A". Then retype the letter "A". Now switch to HTML view again. HTML formating is something like "<P><FONT style="BACKGROUND-COLOR: #dadeda">A</FONT></P>" From this point on paragraphs start misbehaving. Rather than utilizing <BR> when the enter key is pressed -- (this works nicely in netscape) -- the RTE uses variably <P> or <DIV>; and also adds in background color to the text ... either #dadeda or #ffffff.
************
NETSCAPE 7.1 BUG: Cannot delete tables in Netscape (can in MSIE)
************
Also, a minor "bug" is that files edited in Netscape then opened in MSIE cannot be fully edited. While I didn't test this extensively, I notice that if alignment is centered in Netscape, then the file is saved and opened in MSIE the alignment is locked (because a different technique is used to perform the centering in each browser, presumably.)
|
Posted By: dj1811
Date Posted: 12 February 2005 at 10:03pm
|
I notice in RTE 2.0 & 3.0b2 there is a similarity in how the user pressing the ENTER key is handled. Netscape does this very neatly:
text<BR>
text<BR>
etc..
MSIE does not do so well:
text<BR>
<DIV>text</DIV>
OR alternatively I get:
<P>text</P>
(a blank line in the editor here)
<DIV>text</DIV>
I think it would be great if MSIE handled the ENTER key the way Netscape did.
I suppose it is possible to format the text using replace(), as a workaround, i.e.:
<%
'if msie then...
strEditorContent = Replace(strEditorContent,"<DIV>","")
strEditorContent = Replace(strEditorContent,"</DIV>","<BR>")
'etc..
%> |
Posted By: WebWiz-Bruce
Date Posted: 13 February 2005 at 4:00am
|
I'm afraid that most of these so called 'bugs' as you mention them are
just something you have to live with until the built in RTE features of
the various browsers are changed. The Web Wiz RTE, uses the built in Rich Text Editing (RTE) features built into the web browser. Mozilla and Microsoft have implemented RTE features in different ways in their respective browsers. The implementation of their RTE features are very different, sometimes quite buggy, and both lack allot of simple features. This makes it quite difficult witting an RTE editor, as it means that you have to try and get around the various quirks and bugs that are built into the browsers, and the biggest problem of all is what works in one browser doesn't often work in the other. Microsoft's implantation of RTE features in IE is very sketchy, and you will find, like most MS software (just look at Words HTML), that it does completely re-write allot of HTML putting in allot of completely unwanted and useless tags. This is just part of the browser and something that you just have to deal with. ------------- https://www.webwiz.net/web-wiz-forums/forum-hosting.htm" rel="nofollow - Web Wiz Forums Hosting https://www.webwiz.net/web-hosting/windows-web-hosting.htm" rel="nofollow - ASP.NET Web Hosting |
Posted By: WebWiz-Bruce
Date Posted: 13 February 2005 at 4:08am
|
To answer your question on IE handling the 'ENTER' key badly. YES IT DOES  This has been one of the biggest pains to over come. In Microsoft implementation of RTE features in their browser they for some stupid reason decided that if you hit the 'ENTER' key it will put in a <p> tag. This then leads to double line spacing , unless for some strange reason you hit 'SHIFT -> ENTER', then it will insert a <br>Many people have complained about this for years with IE, so from version 2 I wrote some code that uses the 'attachEvent' method so that when a key is pressed in the browser a function is run, if it finds that the key pressed is 'ENTER' it will override the normal <p> tag and instead put in <br> This prevents the <p> double line spacing when 'ENTER' is pressed, but like everything in IE, the 'attachEvent' doesn't always for some reason intercept the keypress event. Why does it do this? Who knows, but the sooner people realise what a naff browser IE is and move away for it, the sooner programming for developers will get easier. ------------- https://www.webwiz.net/web-wiz-forums/forum-hosting.htm" rel="nofollow - Web Wiz Forums Hosting https://www.webwiz.net/web-hosting/windows-web-hosting.htm" rel="nofollow - ASP.NET Web Hosting |
Posted By: WebWiz-Bruce
Date Posted: 13 February 2005 at 4:43am
Been looking at trying to find solution to this for about an hour now. It seems that in IE if you press 'RESET' and the cursor remains in the RTE area then the event listener to listen to key presses stops working so <p> are no-longer replaced. However, if you use the mouse and click onto the RTE area, any time after hitting reset, the event listener starts to work again. I have tried to find a solution to this, by trying to force the focus away from the RTE area, this way the user is forced to use the mouse to click back onto the RTE area, thus making the event listener work again, but so far this isn't working. ------------- https://www.webwiz.net/web-wiz-forums/forum-hosting.htm" rel="nofollow - Web Wiz Forums Hosting https://www.webwiz.net/web-hosting/windows-web-hosting.htm" rel="nofollow - ASP.NET Web Hosting |
Posted By: dj1811
Date Posted: 13 February 2005 at 7:19pm
|
For testing purposes, I added this before the textarea: <INPUT TYPE="text" NAME="bogus" SIZE='12'>
And then then modified the reset button to:
<INPUT TYPE="reset" NAME="reset" value="Reset Form" ONCLICK="document.myForm.bogus.focus();">
Essentially this takes the focus off the textarea when the form is reset and put's the focus in a "bogus" form field. This does alleviate some of the problem but not entirely. I still got white background text 1 time while testing (although I could not replicate it).
I'll see if I can find a fluid way of implementing this, but javascript is not my thing.
*********
Also, I notice this undesirable behavior in MSIE:
1) start with a blank form
2) type a letter
3) press ENTER -- the RTE uses <DIV> tags for the new line
3) backspace until the form is blank again
4) type a letter
5) press ENTER -- now the RTE uses ugly <P> tags for the new line
Are you using some script to replace <P> with <DIV>? Or is this an MSIE bug? I guess what I am wondering is .. what is the "normal" behavior for MSIE when ENTER is pressed?
Do you think it is possible to replace the ENTER key with <BR> instead of <P> or <DIV> in MSIE --- to duplicate the nice way that it works in netscape? My javascript is weak, and I've never used attachEvent. However, is it possible to do something like:
//if msie
function checkEnterKey(){
if(event.keyCode == 13) { //something here to write </br> .. my js stinks..
event.keyCode == 0
event.cancelBubble = true;
} And then use onkeypress in the textarea? Sorry for the terrible javascript, but you probably get the idea of what i'm trying to say.
Sorry for the bold .. but I just realized that I typed a lot of stuff .. and this really is the main question I have.
I thought about using replace() to reformat the MSIE text, but on looking at it further, this is no easy task in itself.
|
Posted By: dj1811
Date Posted: 13 February 2005 at 8:47pm
|
Hrm..
I just looked at the RTE_javascript.asp and I see that the textarea is actually being replaced by an inline frame. All in all the whole mechanism is more complex than I imagined -- although I have a little better understanding now of how the editor works.
I see in your comments:
'If this is IE then detect if enter key is prssed then replace <p> with <br>
Then a few lines lower:
//Insert <div> instead of <p>
Like you changed your mind at some point in how to work with ENTER in MSIE.
I wonder -- keep in mind i am no js expert -- is it possible to capture and block keyCode(13) and instead run a function to simply write "<BR>" & vbCrLf ? Rather than replacing the P tags? Thanks for your time borg --- I'll stop pestering you now. I really do appreciate all the work you've done and I can see where this program might come in handy!
|
Posted By: dj1811
Date Posted: 13 February 2005 at 9:28pm
<INPUT TYPE="reset" NAME="reset" value="Reset Form" ONCLICK="self.focus();">
|
Posted By: dj1811
Date Posted: 14 February 2005 at 1:34am
|
also if there was some javascript in the editor to prevent right clicks and possibly "ctrl+v" --- to prevent people from pasting manually -- this would be a neat feature perhaps. Maybe as an option off/on in the setup file? |
Posted By: WebWiz-Bruce
Date Posted: 14 February 2005 at 4:25am
|
You are right in IE <p> is changed with <div> instead of <br> now when hitting return. The default for IE is <p> which courses double line spacing, this was a problem for allot of users, so I tried capturing the 'ENTER' key and replacing <p> with <br> when pressed, I then discovered loads of problems like within tables, ordered lists etc. if <br> was used, so instead <div> is used, this creates the same effect as <br> but doesn't course any of the problems <br> does. Maybe an idea would be an option to disable the single line spacing for IE from the setup file, so that it runs as standard. An iframe is used to replace the textarea otherwise the whole document would become editable. Placing the onclick event on the reset button could be a problem when people intergarte the RTE into their own form. CTRL+V could be detected easily in Mozilla, but in IE it's difficult, if not almost impossible, to detect of CTRL is pressed with the V key, as I spent many hours on just that type of thing. I did look at detecting Right Clicks and replacing them with my own menu, again I spent around 25 hours working on this, in IE no problem, but in Mozilla as soon as you enable an frame to be editable you can no longer suppress the Right Click Context Menu from appearing, so I eventually abandon this. ------------- https://www.webwiz.net/web-wiz-forums/forum-hosting.htm" rel="nofollow - Web Wiz Forums Hosting https://www.webwiz.net/web-hosting/windows-web-hosting.htm" rel="nofollow - ASP.NET Web Hosting |
Posted By: dj1811
Date Posted: 14 February 2005 at 5:06pm
|
The most troublesome part about how the ENTER key is implemented in IE, is that it is not consistent. While it usually replaces the <P> tags with <DIV> it does not always do so.
What about using CSS to correct the ugly <P> tags in IE, and then not replacing the <P> with <DIV>? For example (from RTE_javascript.asp):
iframeContent += '<style>\n';
iframeContent += 'html,body{border: 0px;}\n'; iframeContent += 'p{margin:0px 0px 0px 0px;}\n'; iframeContent += '</style>\n'; Obviously the display would have to use the same paragraph style.... so perhaps this is not such a great idea?
Alternatives in the setup file for handling ENTER in IE would be beneficial I would think.
Truth be told I would greatly prefer <BR> if it were at all feasible...
What about this (also from RTE_javascript.asp):
//resetting the form
textArea.form.onreset = function(){ if (window.confirm('WARNING! This will erase any changes you have made.')){ editor.body.innerHTML = textArea.value; self.focus(); return true; } return false; } Note: I also made a couple of changes with this function so that it would perform more like a standard reset button.
This has improved some of the peculiarities in IE for me. I don't know if this is really advantageous over using the OnClick event on the reset button, however.
****************************
I still experience a very annoying "bug" (in MSIE of course), where if I:
#1) start with an empty editor
#2) type text
#3) BACKSPACE over the text so the editor is again empty
#4) type text
1 or 2 odd things will happen:
1: the textarea will begin with <P> <P> --- the <P> tags occur without pressing ENTER .. which is why they are not being captured and replaced.
2: I occasionally get text with a white background .. or less frequently a gray background.
|