By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,611 Members | 1,642 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,611 IT Pros & Developers. It's quick & easy.

Textbox, web browser control, and Unicode (got cutoff)

P: n/a
The last reply got sort of cutoff. So here again:
So for anyone interested, here's the simple regexp patterns for the
substitutions required.

The textbox control is being 'zoomed' in a popup which uses a web
browser control. As soon as any numeric entity gets put into the
browser control, it's lost. It will display properly. But it can't be
then read back out with document.body.innerHTML (or outerHTML). It's
just gone.

So just before the zoom popup is . . popped up, one modifies the text
in the textbox control, itself.

textbox control = fRegexp(textbox control, "&#([^;]*);",
"<A$1/>&#$1;", True)

where fRegexp is some code you place in a module as cover to the WSH
or whatever regexp function.

Public Function fRegExp(ByVal strFull As String, strPattern As String,
strReplace As String, boolGlobal As Boolean)
Dim regexp1 As New regexp

regexp1.Pattern = strPattern
regexp1.Global = boolGlobal
fRegExp = regexp1.replace(strFull, strReplace)

End Function
And when it comes time to close the popup, and save the final result,
after the zoom is closed and whatever saved TO the textbox, THEN the
textbox control again is written directly as:

textbox control = fRegexp(textbox control, "<A([^\?]*) />\?", "&#$1;",
True)
And that switches everything back again to numeric entities.

But, once again, the problem is that this keeps any Unicode editing
out of the zoom box. And it would seem to me it might be convenient to
cut n paste from some charmap-type app those Unicode values directly
into the zoom, rather than the underlying textbox after the zoom is
closed. I guess the fix, there, would be to add a button to the zoom
box button bar (assuming one uses such a custom bar), to insertHTML
for each Unicode value, with the dummy "<a . . />" elements and all,
so that these too would be included in the closing call to fRegexp.

But - that is - there must be a better way. Ideally, one could simply
turn the gobbling up of numeric entities by the activeX web browser,
off. So if it is "Ę" going in, then you can read the same
"Ę" in innerHTML when closing, assuming "Ę" itself wasn't
changed. The browser control is a cover or port to the underlying IE
API. If there were a way to disable this conversion, Microsoft might
know. But I haven't seen anything in the somewhat skimpy documentation
for the web browser control. Maybe I missed something. Maybe somebody
knows.

I was tempted to post with a title of - THE MOST BULLETPROOF PROGRAM
EVER DEVISED - or something of the sort, just to get the adversarial
types to attempt a putdown, on the assumption they might nevertheless
know something about this. I don't care if the adversary has the
answer. But there must be a better way than the above.

Nov 13 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.