Beiträge von ehimmer

Yes, I always use the OnRequestHTTPImage event, except in one place where I can't (which I won't get into). I tried to find that event in the hint stuff earlier, but for some reason could not find it. With your instruction I easily found it this time and set up the event but it still does not work. Debugging shows that the event is invoked and the image is loaded into the TextObject, but it is not showing up in the hint. Below is the same code I use in my RapidRemark manager which works for a WPRichText.

procedure TfrmWhisperReporter.RRHintRequestHTTPImage(
  RTFData: TWPRTFDataCollectionBase; Reader: TWPCustomTextReader;
  const LoadPath, url: string; TextObject: TWPTextObj; var Ok: Boolean);
var
  vImage: TRapidRemarkImage;
  vImageName: String;
begin
  if fRapidRemarkHintID <= 0 then exit;

  if (TextObject.ObjRef <> nil) and (TextObject.ObjRef.StreamName <> '') then
    vImageName := TextObject.ObjRef.StreamName
  else if url <> '' then
    vImageName := url
  else if TextObject.ObjType = wpobjImage then
    vImageName := TextObject.Source;
  if vImageName = '' then exit;

  vImage := TRapidRemarkImage.Create();
  try
    if not vImage.LoadBy(fRapidRemarkHintID, vImageName) then exit;
    TextObject.LoadObjFromStream(ExtractFileExt(vImage.Name), vImage.Image);
  finally
    FreeAndNil(vImage);
    Ok := true;
  end;
end;

It is invoked this way:

  fRapidRemarkHintID := pRapidRemark.ID;
  fRapidRemarkHint.Painter.RTFData.OnRequestHTTPImage := RRHintRequestHTTPImage;
  fRapidRemarkHint.Painter.RTFData.LoadFromStream(pRapidRemark.Remark);
  fRapidRemarkHint.ShowHint(pRect);

The images are referenced by name only. I parse out the name and pull it in as a stream from our database. Here is the code I am trying to use when popping up a hint of what we call a RapidRemark. RapidRemarks are a list of saved comments users can quickly add to a report comment. They can click on a node in a tree view to see a view of the RapidRemark in a hint window before applying it to the report. Sometimes these saved comments include images or frequently used diagrams. This is the same basic code logic I use elsewhere to resolve linked images but tailored here for this hint stuff.

procedure TfrmWhisperReporter.ShowRapidRemarkHint(pRapidRemark: TRapidRemark; pRect: TRect);

  procedure LoadImages();
  var
    i: Integer;
    vImageName: String;
    vTextObj: TWPTextObj;

    function AddImage(): Boolean;
    var
      vImage: TRapidRemarkImage;
    begin
      Result := false;
      vImage := TRapidRemarkImage.Create();
      try
        if not vImage.LoadBy(pRapidRemark.ID, vImageName) then exit;
        Result := vTextObj.LoadObjFromStream(ExtractFileExt(vImage.Name), vImage.Image);
      finally
        FreeAndNil(vImage);
      end;
    end;
  begin
    for i := 0 to fRapidRemarkHint.RTF.RTFData.TextObjects.ObjCount-1 do
    begin
      vTextObj := fRapidRemarkHint.RTF.RTFData.TextObjects.ObjList[i];
      if (vTextObj <> nil) and ((vTextObj.ObjType = wpobjImage) or vTextObj.IsImage) then
      begin
        try
          vImageName := '';
          if (vTextObj.ObjRef <> nil) and (vTextObj.ObjRef.StreamName <> '') then
            vImageName := vTextObj.ObjRef.StreamName
          else if vTextObj.ObjType = wpobjImage then
            vImageName := vTextObj.Source;

          if vImageName <> '' then
            AddImage()
        except
        end;
      end;
    end;
  end;

begin
  fRapidRemarkHint.RTF.RTFData.LoadFromStream(pRapidRemark.Remark);
  LoadImages();
  fRapidRemarkHint.ShowHint(pRect);
end;

No problem on the Title stuff, but one last question I think. Is there a way to support linked images? Currently they show up as white space even though I loop through each of the TextObjects (RTF.RTFData.TextObjects) and load the linked image before it invokes the Draw method via the ShowHint method.

Maybe have a SetTextFromStream method, or Stream property for the official release? I load RTF from a database into a TMemoryStream which I usually load into a WPRichText using LoadFromStream.

So, using this is not as pretty as using aHint.Text assignment. Just saying.

aHint.RTF.RTFData.LoadFromStream(vRR.Remark);

Very nice! Exactly what I was looking for. Thank you!

Couple of things to point out... the hint title shows up in the middle (vertically) of the hint box. Pretty much behind the RTF text. I don't really need a title, so no big deal.

The other thing is I'd like to change the background color. If I use a dark VCL style, the black text is against a dark background.

What I got to work for the most part is to use this in the class Create constructor:

FRTFText.Memo.PaperColor := clInfoBk;

This produces the hint window with the clInfoBk colored rectangle, but draws the clInfoBk rectangle slightly lower within the hint window by a few pixels. You can see the VCL style background color behind the clInofBk rectangle, and the hint window outline and stem is covered by the clInfoBk rectangle at the bottom due to the offset. If I don't use that PaperColor setting, this does not happen.

So, is this probably not the right way to set the background color?

FWIW, if I change your Draw statement to this, it lines up correctly whether using the PaperColor or not:

  FRTFText.Draw(TCustomHintWindowHelper(HintWindow).Canvas,
    2, FOffRTF-10, HintWindow.Height-14,
    WPScreenPixelsPerInch, WPScreenPixelsPerInch, 0
    );

Wow, awesome! Wasn't expecting this response! I'll give it a shot as well as looking forward to the next update.

I am looking to have a balloon hint for my application that displays WPRichText. I currently use the standard TBalloonHint and display the WPRichText in plain text, but if the text is long, the TBalloonHint is pretty bad and can go off the screen.

Just wondering if anyone has already put something like TBallonHint together but uses a nice presentation using a WPRichText control.

Thanks,

Eric

Good to know!

This is a snipit of my code which might help explain the simple merge process. It seems to work as I mentioned, but more testing needed.

vMasterPar := vMasterRichText.FirstPar;
vSlavePar := vSlaveRichText.FirstPar;
while (vMasterPar <> nil) and (vSlavePar <> nil) do
begin
  if vMasterPar.ComparePar(vSlavePar) <> 0 then break;
  vSlavePar := vSlavePar.DeleteParagraph;
  vMasterPar := vMasterPar.NextPar;
end;

vMasterRichText.SelStart := MaxInt;
vMasterRichText.FastAppendParagraph;
vMasterRichText.SelectionAsString := vSlaveRichText.AsString;

In the repeat loop you do this:

if (i = CharCount) and (j = SecondPar.CharCount) then

which is why I thought j in that 2nd line's while statement should be looping thru SecondPar.CharItem for skipping over SecondPar's white space.

Anyway, using a paragraph ID is not good enough because users can still edit those paragraphs, and they might even edit them the same way or perform multiple merges, so I really need to look at the paragraph's content. For context, an inspection company might use multiple inspectors to inspect a property, so they will all need to merge their findings into one master report. In our previous version of our app, we received a lot of complaints that leading unmodified "template" text was duplicated, so I was looking at ways to avoid this issue. "Template" text is initial text pre-filled into a comment area, but could later be edited and added to in some cases.

Using your ComparePar seems to do the job with initial tests, so I'll test other scenarios. If it doesn't quite work like I need it, at least I have something to work with to create my own. Just wanted to point out those two lines of code which seemed questionable at first glance.

I am appending one WPRichText to another in a merge kind of operation, and I was wanting to delete any leading paragraphs of the slave RichText that are already in the Master RichText because they are both initialized with the same leading text. By merging the two as-is, I would end up with duplicate leading text wherever the slave was appended to the master RichText.

My thought was to loop thru the leading paragraphs of both RichTexts and compare them. If they were the same, I knew I could delete that paragraph from the slave. I was hoping the ComparePar would handle any text objects as well, because I might have a paragraph that just contains an image or linked image, so I want to be sure it compares this as well.

While looking at the code for TParagraph.ComparePar to see what was being compared, I am slightly confused, well, maybe heavily confused. Why are these two statements doing the exact same thing?

while (i<CharCount) and ((CharItem[i]=#9) or (CharItem[i]=#32)) do inc(i);

while (j<CharCount) and ((CharItem[j]=#9) or (CharItem[j]=#32)) do inc(j);

Instead of the 2nd line, you could effectively just say j := i; So, is the 2nd line supposed to be the following?

while (j<SecondPar.CharCount) and ((SecondPar.CharItem[j]=#9) or (SecondPar.CharItem[j]=#32)) do inc(j);

In any event, will ComparePar do what I need in regards to comparing text and text objects in a paragraph? If not, is there another method or do I need to write my own?

Thanks!

Eric

Is there a gutter image that can be used (or created in a future release) that can be used to signify that a paragraph is set to keep with next? For our use since Keep With Next is used a lot, It would easier for a user to see this at a glance without having to go to each paragraph and checking for this property.

If I have a section with a single paragraph and apply a border to it, it is fine in the editor, but when I do a print preview the border is not there. However, if I add new paragraph below that paragraph having the border, then that other paragraph's border now appears in the print preview. Go back and remove that other paragraph, and the paragraph borders no longer shows up.

The problem has something to do with trimming trailing blank lines that includes the paragraph having a border. If I trim trailing blank lines and only have the one paragraph with a border, this issue shows up. But if I don't trim trailing blank lines then it works fine and the borders show up with or without the extra paragraph. That extra paragraph prevents the trimming of the paragraph having a border.

I use my own trim function based off yours I think. It is the same one I have been using in my old app for WPT5. The reason why I had to use mine is mentioned in the comment:

function TfrmGenerateReport.MyIsNonSpace(par: TParagraph): Boolean;
var
  i: Integer; 
begin
  if par.HasChildren then
    Result := TRUE
  else
  begin
    Result := FALSE;
    for i := 0 to par.CharCount - 1 do
    begin
      if (not MyIsSpace(par, i)) then // (par.CharItem[i] > #32) then
      begin
        Result := TRUE;
        break;
      end;
    end;
  end;
end;

function TfrmGenerateReport.MyDeleteTrailingSpace(pWPRichText: TWPRichText; pParStop: TParagraph = nil): Boolean;
var
  vPar, vPrevPar: TParagraph;
  i: Integer;
begin
  // MyDeleteTrailingSpace was added primarily to prevent WPTools'
  // DeleteTrailingSpace from removing ending signature lines in the WDI report.
  vPar := pWPRichText.LastPar;
  Result := FALSE;
  while (vPar <> nil) and (vPar <> pParStop) do
  begin
    vPrevPar := vPar.PrevPar;
    if (vPar.ParagraphType = wpIsSTDPar) and
      (not (paprNewPage in vPar.prop)) and
      (not MyIsNonSpace(vPar)) then
    begin
      vPar.DeleteParagraph;
      Result := TRUE;
    end else
    begin
      // Truncate that last line ....
      if vPar.ParagraphType = wpIsSTDPar then
      begin
        i := vPar.CharCount - 1;
        while (i >= 0) and MyIsSpace(vPar, i) do
          dec(i);
        vPar.CharCount := i + 1;
        if (pWPRichText.TextCursor.active_paragraph = vPar) and
          (pWPRichText.TextCursor.active_posinpar > vPar.CharCount) then
        begin
          pWPRichText.TextCursor.active_posinpar := vPar.CharCount;
          pWPRichText.ShowCursor;
        end;
      end;
      break;
    end;
    vPar := vPrevPar;
  end;
  if Result then
    pWPRichText.DelayedReformat;
end;

I have not debugged the code yet to see if I am deleting too much of something that might remove the border property. But it works fine in WPTool5, but not in WPTools9 which is why I am posting this. :D

WPRichEdit 9.1.016

Eric

I stand corrected... I guess I didn't know the answer! Interesting, I may have a look at that later! However, its low priority for now (only one customer has asked in like 15 years) and because I want to start playing with the MacOS version of WPTools we bought!!!! (Have to finish my current project first... oh so close).

Probably not possible since Word doesn't even do this AFAIK, but recently had a question from a customer asking if we can create rounded corners on tables and/or paragraph borders.

I already know the answer, but told them I would at least ask :)

Thanks,

Eric

Works nicely.. thanks!

I don't actually need those pixel values for much of anything.other than for the user's benefit and support reasons. When a user adds an image to a report, we automatically scale photos (vs diagrams) down to a reasonable size so their PDF report size is manageable for emailing. Sometimes we get a question as to why their reports are so big, so we ask what they configured their image scaling to be in our app. And so to confirm it is all working and that they are not importing using a different method (diagram vs photo), we right click the image in the report and view its properties to see what the actual image size in pixels is which tells us something about how they added the image and if it had been scaled down or not.

In our old app using WPT5, the Picture.Width and Height used to return the pixel dimensions, but in the WPT9 re-write it is not for some reason. I can use other methods to get the pixel size, like perhaps using ImageEn (which we now use for the image editor), but that seems overkill on my side just to get the pixel dimensions.

But ContentsWidth and ContentsHeight are in twips, correct? I want the actual physical bitmap dimensions in pixels right out of the image file.

When I use the following MulDiv, it correctly provides the actual bitmap size in pixels, but I'm not sure this is always going to be the physical image size under all High DPI and various screen resolutions... maybe it is but I just don't know because it is referencing twips in the equation. I just want the bitmap dimensions as defined in the bitmap itself, not something that is being computed.

vPixelWidth := MulDiv(fWPTextObj.ObjRef.ContentsWidth, Screen.PixelsPerInch, 1440);
vPixelHeight := MulDiv(fWPTextObj.ObjRef.ContentsHeight, Screen.PixelsPerInch, 1440);

In WPTools 5, I had a dialog popup which showed the linked image properties. I would show the presented size using WPRextObj.Width / 1440.0 and WPTextObj.Height / 1440. I would also show the actual image size in pixels using WPTextObj.ObjRef.Picture.Width and WPTextObj.ObjRef.Picture.Height. However, in WPTools 9, WPTextObj.ObjRef.Picture.Width and WPTextObj.ObjRef.Picture.Height return 0. It appears fPicture/fGraphic is nil, so Vcl.Graphics returns 0. for both TPicture.GetWidth and TPicture.GetHeight.

And yes, I believe the linked image has been loaded since it is visible in the editor. Is there a new way to get the image size in pixels or do I really not have it loaded? I load it on the RequestHTTPImage event using TextObject.LoadObjFromStream(ExtractFileExt(vReportImage.Name), vReportImage.Image);

I did not load linked images this way in WPTools 5, so that is different and might have something to do with it. For example, In WPT5 I loaded images from a file in a function but now I load them from a stream in the RequestHTTPImage event. They are JPG images.

Eric

Hmmm... just noticed that even if I set it to poOwnerFormCenter, it continues to position it to main form center even if I create the TWPPagePropDlg in code. Better, but not sure why it is doing that.