After playing with it for a while, everyone I've shown it to all agree that a consistent underline thickness for all font sizes and outputs, etc is best, so we'll just keep wpdrawfineunderlines enabled in all cases, i.e. the editor, previewing, printing and exporting to PDF.
For grins I tried the wpfAlwaysFormatWithScreenRes option and still had the issue at various zoom levels not seeing the underline. Again, wpdrawfineunderlines has no problems other than always being thin, which, if I think about it, might be OK when editing and for print preview, but then disable it when ready to print or output to PDF.should that be a concern there.
Understood and thought about making the page height huge when using wplayShowManualPageBreaks but users can flip between that and full layout which we would then have to reset it back to the real height they set up for that topic. I guess was hoping by setting it to wplayShowManualPageBreaks that you would do something like that internally since headers/footer are not used in that layout mode and therefore why concern yourself with soft page breaks at all in that mode.
However, if you always set up a virtual page, I guess it was just just wishful thinking on my part and I understand the complications. I'll look into toggling page height depending on layout mode.
Thanks for the tip on OnMeasurePageHeight !
We need WYSIWYG, so what I was trying to ask is why enabling wpdrawfineunderlines seems to work but with the downside being that they are always thin? I have not looked into your code to see what happens when that is enabled. Is it that the Pen.Width is always set to 1? If Windows is drawing a hairline when the Pen.Width is 0, then I would think that is truly the problem. A hairline drawn between screen pixels will not show up.
When using LayoutMode of wplayShowManualPageBreaks I would like the editor to fully pretend there is no soft page break. What happens is, if the user has an image close to a soft page break, it looks fine like there is no page break. However if they add a tab in front of the image, it does not indent the image but instead the tab gets added above the image since the image has been pushed to the next page in effect and knows the tab can fit on the previous page. This is also true if you add text in front of the image... however, in this case it adds the text to the left of the image as expected, but when you save and reload the WPRIchText the text is then above the image (again because the text will fit on the page but the image won't). So not only is the editor aware of the soft page break, it is treating tabs differently than text during editing.
I thought the wpfIgnoreSoftPageBreaks might be the answer, but I was sure wrong on that, lol. All text after the soft page break is fully ignored and not even shown. Also looked at the wpInfiniteTextArea, but that too did not do what I was hoping for. Maybe there is a different option I'm overlooking?
Basically what I'm looking for is a way to make the page length infinite so there are no soft page breaks at all, but only when using the wplayShowManualPageBreaks layout mode. or perhaps a new layout mode that has no soft page breaks but still shows and honors manual page breaks.
There seems to always be something more we need, right? ;)
P.S. The reason for this is that they are just editing a single topic, possibly one of many appended to each other. It is just one of many topics to be added during a mail merge, so a page break in the editor can be meaningless and can confuse the customer. We do have the option to edit in Full Layout mode if they desire to see page breaks in case they are only going to have one topic or that topic will be starting on a new page, etc.
When I use a font of 8pt, sometimes you can see the underline and sometimes you can't unless you zoom to something other than 100%. Like at 90%, and 120% you seem to be able to see all the underlines, but not at 100%. If I use the wpdrawfineunderlines option, it seems to work just fine at any zoom level or font size (editor or print preview). However, the line thickness in this case does not change at different zoom levels or font sizes... it is always thin.
Am I missing an option for drawing the underline at a *minimum* thickness so that it will draw the lines *at least* a certain thickness and still allow thicker underlines?
Tried the OSX demo briefly on my old MacBook Pro, and was pretty cool working with it live. I'll have more time later in the week to experiment. :)
We get so many questions asking if our app is available on a Mac or iPad and we have to steer them towards running Parallels on the Mac or use a Windows tablet, which is not an ideal solution for Apple users. Some of our competitors use Java to get the multi-platform solution, but with FMX version of WPTools coming into fruition, we can now look forward to providing these Apple and Android devices with a great solution, and faster than Java apps from what I understand since ours would be running natively.
They all love our inspection software but get disappointed that it is not available on mobile devices. We could dumb down the app and use a plain RTF or HTML editor, but it has been the feature set provided to us by WPTools really makes us stand out against our competitors. I don't know of any other editor that can match WPTools. So to have it available for FMX is fantastic. Looking forward to the next phase of our product on OSX, iOS and Android.
On many of the Embarcadero webinars in the past, there was usually someone asking for a cross platform editor other than plain text. There are a few basic ones available for RTF/HTML, but I think having WPTools available for FMX will be a game changer. At least I hope so!
I'm on v9 now, but luckily I found my v7 in my Recycle Bin. So if you are still using WPTools 7 and you added the define mentioned above, you do get compile errors as I mentioned a while back. You can add the following to WPTools 7 to fix the compile errors:
Line 2736, after the line:
procedure Click; override;
add this line:
in this procedure around line 11770:
Add a conditional around this line:
to make it look like this:
That should get v7 to compile I believe, and get you back the double/triple click.
When using a WPSymbolDlgEx control and UseOKButton is set to false, I'd like a double-click of the grid to use that char and close the dialog without having to click the OK button. EditBox is not set, and NotAttachedToEditBox is set to true.
I added the following to my copy of the dialog in the TWPSymbolDialogEx.CharacterGridDblClick event which satisfies my needs:
if not dlg.UseOKButton then ModalResult := mrOK;
IMHO, it seems like a desirable usage when UseOKButton is false, so thought I'd ask for this enhancement to be added so that I won't have to add similar code on every update.
Sorry, another WPT5 vs WPT8 difference I don't know how to fix.
Say I have a WPRichText with 3 lines of text with the cursor at the home position (or anywhere other than the end position). LayoutMode is wplayNormal.
With WPT5, if I click anywhere well below those 3 lines, the cursor is placed at the last position of the text, i.e. after last char on third line. Perfect.
With WPT8, it doesn't do that. I seem to have to click on one of those 3 lines in order to have the cursor move at all. Not my desired behavior.
I compared all the sets of EditOptions between the two and don't see any differences. Am I missing something or do you have a quick solution.
Yes, this is in a OnMailMergeGetText event.
I guess I don't know what I need, I just want to be sure I'm dealing with Unicode correctly with WPTools or if I even have to worry about it. I just want to make sure I'm loading and saving WPRichText correctly to/from a database. It seems the data being saved is single byte ANSI. It all seems to work but I'm questioning whether this might not be correct and should be saved into the database as Unicode.
When I changed
Contents.StringValue := WPRichText4.AsString;
Contents.StringValue := WPRichText4.AsAnsiString('WPTOOLS');
The warnings were eliminated and the formatting looked good. However, when I changed
Contents.StringValue := WPRichText4.AsAnsiString('WPTOOLS')
Contents.StringValue := WPRichText4.AsAnsiString('ANSI')
The result had the formatting all screwed up. What could that mean? Do I store the WPRichText data into the database as ANSI or as Unicode? Currently, I seem to be storing it into a Blob as ANSI even though I save the WPRichText into a string variable using WPRichText.AsString and subsequently write the string variable to a blob field. This might stem from the fact that this is data that came from an XML file containing WPRichText from WPT5 and imported into WPT8.
I just sent you a sample program illustrating the issue. Hopefully it is something simple.
No, I do not do anything with the result. I don't even assign the AppendAsSection's result. It is just very odd that it works if the first section is a single page with headers/footers and the 2nd section does not have headers/footers of its own, but fails if the first section is more than one page.
I may have to put together a simple example for you. At least to prove to myself that it is not something else in my code that is breaking it even though I am just adding additional lines to section one until it moves to two pages.
Didn't know that, thanks for the tip. I'll see where this takes me. :)
It previews fine and exports to PDF fine if not running in debug mode. It only errors in IDE when running in Debug mode and exporting to PDF. The same data (I say that loosely since it is using linked images and image streams from a database rather than files from disk and the rich text is now unicode vs ansi uner Delphi Rio) does not generate an error with WPT5 and wPDF3 in D2007.
I'm in the process of tracking down where it is occurring and why, just wanted to let you know about the untranslated error msg for now in case that was unintentional.
I am using the following to start new sections:
If the origninal WPRichText1 is a single page with headers/footers, the next AppendAsSection's WPRichText1 that does NOT have headers/footers correctly does not have headers/footers when appended.
However, if the original WPRichText1 flows into a second page, then the next AppendAsSection's WPRichText1 that has no headers/footers incorrectly carries over the current headers/footers to the new appended section that is not suppose to have a header/footer. If that 2nd WPRichtText1 had a header/footer, then it is fine. It seems to be an issue only if the 2nd one has no headers/footers of its own and the previous section was at least two pages.
This worked with WPT5, but not in WPT8. Am I missing some new setting?
I received the following error msg that I had to translate using Google Translate. Not sure if this is something overlooked that should have been shown in English for my environment:
Which Translates to:
In converting our old app from WPT5 with D2007 over to WPT8 with Delphi Rio 10.3.1, I'd like to resolve this warning during an assembly of multiple WPRichText data from a database into a single WPRIchText "report". Ignoring the warnings produces a good overall result, but just don't like warnings... too much noise in the build messages
W1057 Implicit string cast from 'AnsiString' to 'string'
when using statements like:
WPRichText1.SelectionAsString := WPRichText3.AsANSIString('WPTOOLS');
What is your best recommendation to avoid this warning? Do an explicit cast? I did try changing it to the following but it might not give me the same overall result (keep reading):
WPRichText_ASTopic.SelectionAsString := WPRichText3.AsString;
I also get the inverse warning of:
W1058 Implicit string cast with potential data loss from 'string' to 'AnsiString' when doing a mailmerge:
Contents.StringValue := WPRichText4.AsString;
and changing it to the following might not produce the same overall result (keep reading):
Contents.StringValue := WPRichText4.AsAnsiString;
gain, ignoring the warnings produces a good "report", but have not investigated what goes wrong doing the alternate assignments as mentioned above, it's just the end "report" is not built correctly. It might be one or perhaps both of the alternate assignments causing the bad result, have not yet narrowed it down.
So to save time I thought I'd just post to you and the community and ask for the best recommendations to avoid these warnings.