Posts by ehimmer

    In WPTools5 all I needed to do was set the option [wpDontSetPageBreak] to prevent a page break on a new section. However, in WPTool9 it seems I have to set both of these options [wpDontSetPageBreak, WPRemovePageBreak] in order to prevent the page eject.


    This code in AppendAsSection is suspect since I don't know the full use of these options, but it seems to show that both have to be set to avoid the page break at all:

    Code
    1. if not(wpDontSetPageBreak in Options) or not(wpRemovePageBreak in Options)
    2. then
    3. include(npar.prop, paprNewPage)
    4. else if (wpRemovePageBreak in Options) then
    5. exclude(npar.prop, paprNewPage);


    Why not this (again, I'm basing this on a very narrow scope of the use of these options):

    Code
    1. if (wpDontSetPageBreak in Options) or (wpRemovePageBreak in Options)
    2. then
    3. exclude(npar.prop, paprNewPage)
    4. else
    5. include(npar.prop, paprNewPage);


    Or perhaps change the OR to an AND as it is currently.


    Eric

    When I split a table using WPRichText1.SplitTable, there is barely any space between the two tables, so it is hard to know they actually were split other than selecting rows/columns with the mouse. The FormatOptionsEx2.wpfAlwaysGenerateParBetweenTables option is set to true, but I do not get a par between the two tables on a split.


    After a split, the cursor is in the first cell of the 2nd table. Hitting enter does not add a paragraph spacing between the tables like it did with WPTools 5. For reference with WPTools 5 it was a bit more intuitive for adding spacing. Hitting enter right after splitting a table added a new paragraph between the two tables and moves the cursor to that new line. Somehow WP5 knew that if you hit enter in the first position of the first cell, and there is no paragraph between it and the previous table, it adds a paragraph and sets the cursor pos to that new par. Is there a new option that I can't find to make it behave like it did with WPtools 5?


    Strange cursor positioning issue with WP9 and table splitting: Create a 3 x 3 table in a WPRichText. Place the text cursor in the middle cell and split the table. The text cursor moves to the first cell of the 2nd table. Hit the cursor up key. The text cursor appears below both tables indented about an inch instead of between the two tables. Hitting the cursor up again, places the cursor in the 3rd column of the first table. Cursor down puts it once again below both tables. Hitting enter even when the cursor is below the two tables adds spacing between the two tables. If you do the same thing but first add maybe 10 lines before creating the table, hitting the cursor up key positions the text cursor on line 6, indented about an inch. No matter how many lines there are before the table, the cursor always goes to the same spot in the WPRichText.


    WPTools 9.1.016

    Delphi 10.3.2


    Eric

    No problem, really. I think this is the solution for our customer:

    http: //osxdaily.com/2017/09/29/change-iphone-camera-default-image-format-jpeg-heif/

    The article tells users how to either switch their iPhone to save jpg files instead of HEIC files, or have the iPhone convert them to JPG on transfer to PC.

    Any plans to support insertion of an image that is in the HEIC/HEIF image format? (being used by Apple) HEIC = High Efficiency Image Coding.


    We have a customer who takes pictures on an iPhone and wants to be able to insert them into a report built using WPTools, as well as being able to export to PDF of course without having to convert them first.


    I think there is a way to force the iPhone to save in JPG format rather than HEIC, so I will probably tell them to do that. Just curious if HEIC/HEIF is in your plans anytime soon.


    Eric

    I made a few minor changes to the WPSymbolDlgEx myself, like changed the Position property to pOwnerFormCenter which does the positioning "fix" (can you make that a control property?)


    I also changed the dialog border from 0 to 5, and resized Panel1 to fit within the dialog and centered it. This "fixes" the alignment stuff I mentioned. I can send you my changes if you want. I just hope I don't need to make the sames changes on each update. :)


    I did not spend a lot of time to find out how to cleanly fix the drawing of the grid. The RowCount is set to 1 in the Panel Resize event before the IDToUnicode is initialized. I temporarily fixed it by calling PanelResize after the cbxFontListChange(Sender) call in FormActivate. Probably not the best fix but it works. ;)


    Eric

    With the 9.1.016 update from 2019-10-25 (and maybe earlier versions since I don't know when this started but it used to work), the WPSymbolDlgEx dialog does not display properly until you resize the dialog. Only the first row appears, but then the whole grid shows up once you start resizing the dialog.


    FWIW, the dialog could use a slight tweak... the encapsulating border and Subset dropdown right side is right on the right edge, and the buttons are right on the bottom edge. Personal preference is to have some and equal spacing around the whole dialog. ;)


    Also, everything is "relatively" huge (perhaps that is due to my use of a 4K monitor at 100% scale and you are drawing the dialog based on screen size which would be good...so just checking if that was intended).


    One other question... is there a way to have the dialog centered based on the main form or better yet, the owner form? On a 4K monitor it throws the dialog way up to the left corner.


    Eric

    lol... nope. I forgot to install it. Sorry about that.


    Installed and now much better except for a couple of things:


    - For both numbered and non-numbered bullets, the indent is better but not consistent: 1/4 inch for the first increment and then 1/2 inch thereafter.

    - When I decement the indent to its beginning point (i.e. indent twice, then decrement twice), the bullet number or char goes away. It still says it is a bullet, but there is no number or bullet character once it is back to the original point.


    Non-bullet lines still increment too much for my taste... 1/2 inch instead of 1/4 inch. I think I recall there being a setting for this.. I'll try to find it.

    When I use the WPAIncIndent on a non-bullet line, the WPADecIndent correctly moves the paragraph back to the previous point. However, this is not true with numbered bullets. For example, if I have four numbered bulletted lines 1, 2, 3, 4, and I increment the indent for line 2 with the WPAIncIndent action, it indents and changes the numbered bullet to "a)" as expected (maybe 3/4 inch is a bit too much for my liking by default). If I then change my mind and click to decrement the indent using the WPADecIndent action, the numbering is reset correctly, but the indent is not (it moves back only 1/4 inch, not the full 3/4 inch amount).


    Bug? Setting?


    Note: I would like to set the indent to also be just 1/4 inch, not 3/4 inch. So I'm thinking maybe the initial indent value of 3/4 inch for numbered bullet lines is somehow wrong? Subsequent WPAIncIndent on numbered bullet lines only move 1/4 inch... only the first increment is 3/4 inch. For non-bullet lines, it always moves a consistent 1/2 inch (but would like 1/4 inch)


    Note: non-numbered bullet lines don't move at all with those actions, but would like it to.


    Eric

    Cool. I did find this in your help info that took care of hiding the lines in WPT9, which WPT5 did not show by default, when using wplayShowManualPageBreaks. Adding it as a new property is better! :)

    WPRichText1.Memo._DontShowSoftPageBreak := true;

    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? ;)


    Eric


    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?

    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:

    Code
    1. procedure DBlClick; override;


    in this procedure around line 11770:

    procedure TWPCustomRtfEdit.Click;

    Add a conditional around this line:

    vMsg: Windows.TMsg;

    to make it look like this:

    Code
    1. {$IFDEF DELPHIXE}vMsg: WinAPI.Windows.TMsg;
    2. {$ELSE}vMsg: Windows.TMsg; {$ENDIF}


    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.


    Thanks,

    Eric

    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.


    Thanks,

    Eric