Beiträge von mbrickman

Is there any way to protect a TWPTextObj if a user deletes the surrounding text? Ideally I would like objects to only be deleted if the user explicitly chooses to do so (eg by selecting the object and pressing the delete key rather than by deleting the link in the containing paragraph). If the user deletes the containing paragraph, the object should automatically be moved to an adjacent paragraph.

2 years on and still no 64bit compiler or Linux support or OS/X support - just more promises. Perhaps lazarus is the way forward!

I am trying to persuade my customers to switch from Microsoft Word to a word processor embedded in my application which uses WPTools. The problem I am having is that they do not like the way pages are displayed on the screen.

Unless I am misunderstanding something, we have two choices: we can either display using screen resolution (wpfAlwaysFormatWithScreenRes) or we can display at printer resolution. Neither of these is good enough. With screen resolution, the text (and graphics) look good, but the page layout is wrong. Line breaks and page breaks are in the wrong places and do not represent the way the document will be printed. With printer resolution the line breaks and page breaks are in the correct places, but the text looks awful with irregular and strange placing of characters within the word. Moreover, photographs are distorted when they are re-scaled back to screen resolution using rather crude bitmap scaling rather than proper jpeg software.

The reason why printer resolution looks so bad is that the paint engine (in effect) tries to place each individual character as close as possible to its actual position on the page, but because the pixel matrix is not fine enough, some characters are shifted left and others are shifted right. These adjustments can result in letters which appear to crash into one another and spaces in the middle of words which appear as wide as the spaces between the words.

Both modes are imperfect and my customers are not prepared to compromise as MS Word does not suffer from these problems.

The reason why MS Word appears better is that it cheats. It does not attempt to display the page exactly as it will be printed, but rather shows an approximate layout with the correct page and line breaks, but without getting too accurate about exact word and character placement.

Please can we have a similar option within WPTools that combines the best of both options. This should works as follows: The printer resolution should be used to calculate where the line breaks and page brakes need to be. The screen resolution is then used to display the page. Where necessary pixels can be added or removed from the inter-word spaces and between paragraphs to balance the page.

WPTools is a fantastic product, but without these changes, it looks very crude when compared to MS Word.

Tank you,

I found this line is TWPCustomRtfEdit.InputCode not TWPCustomRtfEdit.InputMergeField.

ALSO this line does not exist in 24.3a so must have beein introduced in a later release

InputMergeField is not placed at the cursor position in this release. This bug is easily reproduced using the TextObjects demo as follows:

Type a new line with the word 'Hello'. Place the cursor at the end of the land and press the 'Insert Merge Field' button. The merge field will be inserted between the l and o NOT at the end of the line - eg:

hell<<Julian>>o

I am sure this will be fixed with your usual speed

PaintSinglePar has been broken somewhere between release 23.1 and release 24.3a. The most obvious manifestation of this bug is that ListBox1 of TWPStyleDlg is no longer populated with text and remains blank.

This also affects my own style dialog which is not based on TWPStyleDlg, but calls PaintSinglePar directly.

I am sure you will fix this with your usual promptness.

Is there any way of preventing TWPTextObj (wpobjImage) objects with wpobjRelativeToPage or wpobjRelativeToParagraph from being moved to a different paragraph/position if the image is dragged to a new position?

This is causing problems on my mail merge document as the TWPTextObj is being moved outside its containing wpobjMergeField object pair and is missing when I merge in the next data item. As I can not locate this object, I do not know where the new image should be positioned on the page.

If there isn't currently a way of doing this, can we have one as it is critical to my application.

Already tried that, but it does not seem to make any difference.

There is a small (but irritating) bug in the flashing cursor display when WPAT_SpaceBefore is set.

Try the following using the Demo WP. On the first line change the Paragraph Spacing Before to 0.10cm. You will see that the vertical position of the flashing cursor is incorrect on the first line. It is now too high. The new position seems to be aligned to the base line rather than the extent of descenders. ie aligns with the bottom of an 'a' rather than a 'g'. The position is correct on the other lines.

I have also seen the cursor raised above the base line when positioned at the end on the first line - although I can not reproduce this effect reliably.

In my application styles typically set WPAT_SpaceBefore to 6pt and it is surprisingly disorientating typing new paragraphs when the cursor is just a few pixels adrift.

I am sure that you will tackle this problem with your usual efficiency.

Is there any way to improve the default kerning in WPTools? My text looks scruffy compared to the same text rendered in MS Word. This gives my Word Processor a rather cheap look.

Type the phrase 'Historically however' into the demo WP on a new line, and set the font to arial 9pt. Now do the same in word and compare the results. You will see that the 's' in historically nearly touches the 't' and that the 'i' is rather crowded compared to MS Word. Similarly the 'w' in however appears to have crashed into the following 'e'. Curiously, the 'w' occasionally creashes into the preceding 'o' instead.

I hope that there is an easy fix to this one as I will need to pursuade my customers to move away from MS Word and this will not help.

Thank you for the prompt reply - excellent service!

I assume this fix will make it in to the next release

My Word Processor has a task pane similar to the one offered by MS Word (right hand side of screen). Like word, this can be used to display (and modify) the current style sheet. We use the ParStylePaint method to display the 'look' of each style - as you do with your TWPStyleDlg dialog.

Unfortunately unlike MS Word, ParStylePaint does not print the associated Number style - so no bullets and no sample numbers. This makes it quite difficult to identify the style types.

You have exactly the same issue with your WPMultiDemo word processor. If you create a bullet style, this is not reflected on the toolbar style combo box.

I have tried to follow the code (through PaintSinglePar) to see if there is a 'quick fix', but don't have enough understanding to see where the issue arises.

For us, this is an urgent issue.

Actually my implementation is no good as I need to know the destination data block. So please consider the following solution which works for me - Modify WPRTEPaint as follows (new or modified lines marked with {*}):

1) add new data type for the event

...type  TWPRTFEnginePaint = class;  TWPLeaveRTFDataBlockEvent = procedure(Sender: TWPRTFEnginePaint;    FromBlock, ToBlock: TWPRTFDataBlock; var Allowed: Boolean) of object; {*}

2) Create the event property

TWPRTFEnginePaint = class(TWPRTFEngineBasis)...    FOverridePageCount, FOverridePageOffset: Integer;    FBeforeLeaveRTFDataBlock: TWPLeaveRTFDataBlockEvent; {*}    procedure SetUseANSITextAttr(x: Boolean);...    property OnGetPageGapText: TWPOnGetPageGapText read _OnGetPageGapText write _OnGetPageGapText;    property BeforeLeaveRTFDataBlock: TWPLeaveRTFDataBlockEvent read FBeforeLeaveRTFDataBlock write FBeforeLeaveRTFDataBlock; {*}  end;

3) Now implement in MoveCursor function

function TWPRTFEnginePaint.MoveCursor(PaintPageNr: Integer; X, Y: Integer; DontLeaveDataBlock: Boolean = FALSE): Boolean;
var aRTFData, newblock: TWPRTFDataBlock;
...
  Allowed: Boolean; {*}
begin
...
      RepaintIt := (par.RTFData <> Cursor.RTFData);


      Allowed := TRUE; {*}
      if RepaintIt then
        if assigned(FBeforeLeaveRTFDataBlock) then {*}
          FBeforeLeaveRTFDataBlock(self, Cursor.RTFData, par.RTFData, Allowed);  {*}


      if not Allowed or (DontLeaveDataBlock and RepaintIt and (Cursor.RTFData <> nil)) then exit; {*}
...

I hope you will be able to include these changes in your next release.

Of course we will also need a published property

Can we have a new BeforeLeaveRTFDataBlock event in TWPCustomRtfEdit. This would be implemented as follows:

TWPAllowEvent = procedure(Sender: TWPCustomRtfEdit;
  var Allow: Boolean) of object;


FBeforeLeaveRTFDataBlock: TWPAllowEvent;


function TWPCustomRtfEdit.DontAllowLeaveRTFDataBlock: Boolean;
var allow: Boolean;
begin
  allow := TRUE;
  if assigned(FBeforeLeaveRTFDataBlock) then
    FBeforeLeaveRTFDataBlock(Self, allow)
  if allow = FALSE then
  begin
    Result := TRUE;
    exit;
  end;
  if (wpDisableEditOfNonBodyDataBlocks in EditOptionsEx)
    or (LayoutMode = wplayLayout) then
    with FMemo.Cursor do
    begin
      if (RTFData = nil) or (RTFData.Kind <> wpIsBody) then
        Result := FALSE
      else Result := TRUE;
    end else Result := FALSE;
end;

This will allow us to lock users into data blocks under program control. In particular, our application will have two distinct edit modes - Body Mode and Header/Footer Mode. Currently we can lock the user into the body using the wpDisableEditOfNonBodyDataBlocks option, but there is no way of locking them out of the body when they are in our Header/Footer Mode. Introducing our proposed event will be much more flexible than creating another EditOptionsEx value such as wpDisableEditOfBodyDataBlocks

I have verified the following bug with both my own application and the sample word processor in the demo system.

If you create a simple document with a couple of styles that use the "Next Style" feature and save in .wpt format, the "Next Style" value gets ignored when the document is loaded.

The TWPTOOLSReader.Parse procedure does see the next style and in the lines:

s := aTag.NormalizedParamString('next', ''); //V5.20.1
if s<>'' then //V5.20.1
TextStyleEle.NextStyleName := s; //V5.20.1

the value of NextStyleName is corectly assigned. However if you then try to check the styles with the style dialog, the Next Style is missing.

I hope you can provide a quick fix as I really need this to work.

Mike

Just exporting to RFT within word for now which is OK for testing purposes but a bit labour intensive and possibly not 100% accurate. I have had a quick play with the WPWordConv unit, but with not much success.

Will probably write some stuff to batch export existing documents to RTF and then import them into WPTools + patch up as we go. This still leaves the problem of customers wanting to import word documents from 3rd parties hmm. I must admit, I rather assumed that WPTools would do this anyway.

I have just purchased WPTools to replace Word in our application. We need a solution that is much more tightly bound into our system than we can achieve with Word. Also controlling word through COM is somewhat restrictive.

To help our users adjust, we want to make our solution as 'Word Like' as possible. We have used the excellent TMS Component Pack to create Office 2003 style toolbars and have now achieved a good match at the GUI level. We are now working through each of the functions to ensure that they work in a similar way to Word.

Our first problem is that the Font and FontSize combo boxes do not function as expected. If nothing is selected they show the specific attributes of the character immediately to the right of the cursor. This is OK if the character has a typeface and size attribute. However if no specific attributes have been set (ie the character defaults to the paragraph’s style values) then the boxes are left blank. This is different to the way Word works and a little quirky from a user’s perspective. We would like the combo boxes to always show the implied attributes for the character rather than the set attributes – ie the actual font and size which will be used to render the character.

Is this possible?