Beiträge von support

    Hi,

    >> Is there any way of telling where the mouse is in terms of the >> pagerect regardless what text is on the page.

    No, there is no way. But a new page always has at least one line of text - at least an empty line of text.

    >> Unfortunately, the code is dependent on there being text beneath the >> point that the mouse is over.

    Thats not 100% correct. It is ok if there is text above the the position or to the right or left side.

    Julian

    PS.: If you reply to a post it will be automatically moved to the top of the list.

    >>I need to be able to calculate the precise position, in twips from the left and top of the page rect, of the mouse cursor as it moves across the wprichtext. I also need to know what page it is over. <<

    <pre>procedure TForm1.WPRichText1MouseMove(Sender: TObject;
    Shift: TShiftState; X, Y: Integer);
    var XOfPage, YOfPage, aY, aX, PageNo,cp :Integer;
    par : PTParagraph;
    lin : PTLine;
    begin
    // First we need to find the page which is 'under' the mouse
    WPRichText1.GetLineFromXY(x,y,par,lin,cp);
    // If there is a page:
    if lin<>nil then
    begin
    PageNo := lin^.pagenum;
    // Find first line with this page
    par := WPRichText1.FirstPar;
    while par<>nil do
    begin
    lin := par^.line;
    par := par^.next;
    while lin<>nil do
    begin
    if lin^.pagenum = PageNo then
    begin
    par := nil;
    Break;
    end;
    lin := lin^.next;
    end;
    end;
    if lin<>nil then
    begin
    YOfPage := lin^.y_start - lin^.t_xtra - lin^.line_top- WPRichText1.TopOffset;
    aY := MulDiv( WPRichText1.Memo.ScreenToTwip(y ) - YOfPage
    , 1440, WPRichText1.Header.FFontYPixelsPerInch)- WPRichText1.YOffSet;
    aX := MulDiv( WPRichText1.Memo.ScreenToTwip(X - WPRichText1.XOffSet) - WPRichText1.Memo.left_offset
    , 1440, WPRichText1.Header.FFontXPixelsPerInch);

    <b>// Do anything with aX and aY <--------- !!!</b>


    end;
    end;
    end;</pre>

    >> I use the WPMMDataprovider to exchange fields on printout with their real content. That works fine, but it seems fields in the header are not exchanged.<<

    You need to enum all header and footer texts and execute mergetext:

    Thanks for your suggestion. Esspecially for the table support there already exists a modern concept which will allow to access the tables and cells as collections. Please note the 'object oriented' way the header/footer texts and RTFVariables are already handled.

    Julian

    Although V4.x will be supported with at least 1 more releases the work on WPTools V5 has begun.

    WPTools 5 is designed to work with the latest compilers. To make this possible some changes to the RTF Engine will be necessary, most of the pointer arithmetic has to be replaced. The modified concept introduces new options which are unthinkable with the current concept so WPTools 5 should be the base for another 7 successful word processing years :-)

    We try to make the changes in a way that your code should run as it used to. Code which access pointers (WPRichText.FirstPar, CPAttr ...) will require changes. Sometimes only the ^sign has to be removed, in case the code lists the lines of a paragraph (lin := par.line; while lin<>nil do ... and of course pc and pa arithmetic) this code must be changed. But also here, the changes shall be marginal and be rewared by an easier to understand and extremely stable code. Undocumented procedures and variables of the 'RTFEngine' (WPRichText.Memo) will be changed or replaced to keep WPTools up to date and improve the performace. The way paragraph border attributes are stored will be changed, too.

    Some components will not be included in future. This are the almost never used components TWPWallPaper, WPTAltStatusBar and TWPContainer + TWPResLabel.
    The new version will alway use the Action classes so the components TWPComboBox, TWPToolButton and TWPToolControl which were mainly created to create GUI without the availability of action classes will also have to go.

    WPTools 5 will support Delphi 5 or higher and C++Builder 5 & 6.
    It should be ready in the first half of 2004. (Delphi 4 does not provide the necessary compiler features.)

    ...comments are welcome...

    Julian Ziersch
    wpCubed GmbH

    What do the properties ParKeep and ParKeepNext do and what's the difference between both?

    ParKeep means that a paragraph cannot be devided by a page break. Ok, if it is longer that a page it will be divided anyway.

    ParKeepNext means that this paragraph and the following "next" may not be devided.

    Please also not the properety WPRichText.FormatOptions. There you hav the possibility to switch of word wrap in tables or table rows. (V4.2 or higher)

    Zitat

    What do the properties ParKeep and ParKeepNext do and what's the difference between both?

    ParKeep means that a paragraph cannot be devided by a page break. Ok, if it is longer that a page it will be divided anyway.

    ParKeepNext means that this paragraph and the following "next" may not be devided.

    Please also not the properety WPRichText.FormatOptions. There you hav the possibility to switch of word wrap in tables or table rows. (V4.2 or higher)

    Julian

    PS: I attached this answer to our new FAQ at: http://wpcubed.com/forum/viewforum.php?f=8

    Zitat

    On a table, if there is shading, the cell shows up in all black if you open the document in Microsoft Word. If I save it and reload it with Wptools it looks fine.


    MS word does not seeem to like truecolor. I don't know yet a solution for this problem. If you use a shading value (such as 10% it shouls show up shaded in word, too)

    Do you provide any resolution parameters to the DrawMetafileEx function. The best is to call it with 0 0 0 0 (for position and w,h) and Screen.PixelsPerInch, Screen.PixelsPerInch for the last two parameters if that metafile has been just created using the screen as reference. For automatic detection of resolution use 0.