• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • RichTextEdit not word wrapping despite that being set

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (4)

Resolved RichTextEdit not word wrapping despite that being set

  1. Issue
0
Votes
Undo
  1. Daniel Vivier
    Daniel Vivier
  2. PowerBuilder
  3. Monday, 24 May 2021 15:00 PM UTC

We have a small RTE in one of our applications, used only by our staff. It is using the Built-In TX Text Control.

It is set to WordWrap, and if I right-click in it when I'm running the compiled program and pick Properties from the popup menu, it shows that WordWrap is on. The control doesn't have a horizontal scrollbar, since it shouldn't be needed if word wrapping is working.

Until a few days ago, that always worked properly for me, but one of my colleagues has been reporting for a long time that it was not word wrapping for him - lines he typed, or previously saved lines being retrieved into the control, would just extend to the right and need to be scrolled to see all of them. So he would use Enter to put in hard breaks to make everything visible.

Then a few days ago this stopped working for me too: I'm seeing the same problem, where word wrapping is not happening despite appearing to be on. Turning it off and then on again does nothing.

The only thing I can think of that I did recently that might have changed something on my computer is changing the regional language for number display from English to French and then later back again. I'm not sure whether or not that coincided with this problem appearing.

Is this a known problem? Any solutions? (I was actually thinking of putting the RTE into our programs that we sell to users for an important use soon, but couldn't do so if some of them would have this problem!)

Compile and deploy PowerClient projects without ID...
Get coordinates and size of an individual tab?
Responses (4)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 25 May 2021 04:26 AM UTC
  2. PowerBuilder
  3. # 1

Hi Dan, it's 5:23 am here, so I'm going to get some sleep first (our source control and db is stopped anyway).
Later, I'll have a look at our own richtext edit control, as I've overcome these problems and achieved proper wordwrap (thanks to some other fine people on this Q&A). It's based upon the u_rte from the pfc classes.

Are you using PFC ?
Back in 2 or 3 hours.

Comment
Load more comments
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 25 May 2021 11:21 AM UTC
Is your window resizable?
  1. Helpful
Daniel Vivier
  1. Daniel Vivier
  2. Tuesday, 25 May 2021 12:29 PM UTC
Yes my window is resizable. I just skimmed all of the code in pfc_u_rte and there's nothing at all in there about word wrap.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 25 May 2021 12:43 PM UTC
well the zipped sample app has a resizable mdi sheet, so that should solve your problems.

Only be aware of that once your window has been opened (from an event posted from the open event), you have to call the rte_1,event resize(0, ...rte_1.width, ...rte_1.height) once to make sure the pagewidth initially is correct, not only once the user has resized the window.

(just search on "miguel" and you'll find it).

You could also choose NOT to use the u_userobject, and use the u_rte object directly on your window, but I thought in most common situations, you'd have some kind of common user object on which you place the rte.

Good luck!
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 25 May 2021 12:25 PM UTC
  2. PowerBuilder
  3. # 2

There you go Dan,

Please see the attached zip file. (with thanks to Arthur Hefti and Ren'e Ullrich also, who amongst others helped me out on the correct resize and calculation of the RTE).

Made with PB 2019 R3 - build 2703

Just do a search on // Miguel: and you should find the important scripts.

any questions, glad to assist.

regards.

 

Attachments (1)
richtext-pagewidth-resize.zip
Comment
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 25 May 2021 12:59 PM UTC
NOTE: I've tested this with windows dpi scaling set to 100%. It might not work correctly with different text scaling in windows. Also, if the user does a right mouse click and changes metrics between inches and cm it might fail.
  1. Helpful
Daniel Vivier
  1. Daniel Vivier
  2. Tuesday, 25 May 2021 13:05 PM UTC
Wow, thank you, that almost worked for, and did work with a few adjustments. In your line:



this.paperwidth = (UnitsToPixels( newwidth, XUnitstoPixels! ) / li_PixelPerInchX * 2.54 * 1000) - 650



I had to remove the multiplication by 2.54, because my units on the RTE are thousands of an inch, not centimeter, and I had to change from subtracting 650 to subtracting 265 (which is 650 / 2.54) for the same reason.



I was hoping I could adjust the code to take account of what the units are, but I don't see anything in the PB RTE API that allows me to determine the units.



It also appears, from the Help on the PaperWidth property, that it will also apply to printing, so I think we would have to reset it to 8000 or so letter size, portrait, before any printing.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 25 May 2021 13:46 PM UTC
Yw, yes, the real problem is that if you have the contextual menu enabled, your user might just change the metrics, so even if you would be able to find out the metrics, there's no way (that I know of) to detect the user changes those settings.

Funny thing is that paperHeight doesn't seem to work also. Something I've reported in the past.

regards

  1. Helpful
There are no comments made yet.
Daniel Vivier
Daniel Vivier Accepted Answer Pending Moderation
  1. Tuesday, 25 May 2021 13:34 PM UTC
  2. PowerBuilder
  3. # 3

OK so here's the simplest version of the code I extracted from Michael Leeuwe's scripts (that are apparently based on code from Arthur Hefti) that makes this work in resizable windows:

Add this to the Local External Functions of your window (if not already defined globally, obviously):

Function ulong GetDeviceCaps( ulong hdc, ulong index) Library "GDI32"
Function ulong DeleteDC( ulong hdc ) Library "GDI32"
Function ulong CreateDC( string a, string b, string c, string dummy ) Library "GDI32" Alias for "CreateDCW"

Create a new event called resize on the RTE (it doesn't normally have such an event), with this code:

// From Miguel Leeuwe: add the pbm_size event and put in this code:

// Arthur Hefti's code:
integer li_PixelPerInchX
long LOGPIXELSX = 88
string ls_Null
ulong lul_HDC

SetNull( ls_Null)
lul_HDC = CreateDC("DISPLAY", "", ls_Null, ls_Null)
li_PixelPerInchX = GetDeviceCaps(lul_HDC, LOGPIXELSX)
DeleteDC(lul_HDC)

// "-650", because we show a V-Scrollbar, if not that wouldn't be necessary:
this.PaperWidth = (UnitsToPixels( this.width, XUnitstoPixels! ) / li_PixelPerInchX * 2.54 * 1000) - 650

However, that last line is only correct if the units in your RTE are 1000's of a Centimeter. I'm not entirely sure how that is initially determined (it can be changed with the right-click menu and picking Properties in the RTE) but if it's 1000's of an Inch (which was the case in my code) you don't multiply by 2.54, and you have to divide the final adjustment of 650 by dividing it by 2.54, and you get:

this.PaperWidth = (UnitsToPixels( this.width, XUnitstoPixels! ) / li_PixelPerInchX * 1000) - 256

There doesn't seem to be anything in the RTE API to determine the units used, or to react if the units are changed, so that's a problem. Also, according to the Help on the PaperWidth property, it will also affect printing, so it would have to be changed before printing, then changed back after printing, if your RTE allows printing!

And finally, in the resize event of the window, you have to call this new resize event on the RTE, after any resizing of it has been done, like:

rte_1.Event resize()

 

Comment
Daniel Vivier
  1. Daniel Vivier
  2. Tuesday, 25 May 2021 13:57 PM UTC
OK, I found a bit of an improvement on that code. The units of measure seem to initially be based on the control panel regional settings (US or Metric), and can be read from the registry. So at least for Windows 10, the following works. In the RTE resize function, add the following before the last line:



string lsMeasure

double centimeterMultiplier = 2.54

if RegistryGet("HKEY_CURRENT_USER\Control Panel\International", "iMeasure", REF lsMeasure) = 1 then

if lsMeasure = "1" /* US, so inches */ then centimeterMultiplier = 1

end if



Then change the last line to:



this.PaperWidth = (UnitsToPixels( this.width, XUnitstoPixels! ) / li_PixelPerInchX * centimeterMultiplier * 1000) - &

(256 * centimeterMultiplier)



Of course, that still doesn't help if the user changes the units in the RTE at runtime with a right-click and Properties.

  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 25 May 2021 14:28 PM UTC
That's a great resume of it, thank you Dan!
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 25 May 2021 14:32 PM UTC
To be honest: I'm so fed up with the RTE control that I'm secretly working on trying to replace it with TinyMCE. Since you are about to implement it, I'd recommend you also to have a look at:

https://community.appeon.com/index.php/qna/q-a/pb-2019-r3-web-browser-control-event-handling#reply-27432

It's not perfect yet, but it might make us independent of all the quirks of the RTE control and its never ending list of bugs.

regards.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 25 May 2021 14:33 PM UTC
  2. PowerBuilder
  3. # 4

Please see also my last comment made on using

https://community.appeon.com/index.php/qna/q-a/pb-2019-r3-web-browser-control-event-handling#reply-27432

as a possible alternative solution for RTE.

Comment
Daniel Vivier
  1. Daniel Vivier
  2. Tuesday, 25 May 2021 14:49 PM UTC
Thanks Miguel. We're actually using the MS WebBrowser control in design mode for a mail-merge editor now (extending the TopWiz Software example), but it's just a bit underpowered, unless you supplement its editing functionality by external editing, either hand-editing HTMl in Notepad or with some Wyswyg HTML editor. So that's why I'm thinking about testing using the RTE instead. For starters it will depend on how close the appearance of our users' existing HTML templates loaded into the RTE is to the HTML version's appearance in the WebBrowser control - if they are very different, having the user convert would be a problem for them.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 25 May 2021 21:48 PM UTC
yw, the TinyMCE editor is very similar to the editor that you have on this page to give an answer (maybe it's even the same thing).

regards.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.