Beiträge von ehimmer

I think I see why I get the error about XObject name 'WPToolsJIF_1" not found... this only occurs on the 2nd export to PDF from the same WPRichText that have linked images.

Seems that the first time I export to PDF, the images are in the PDF, but if I turn around and export it a 2nd time, the images are all missing from the PDF (file size confirms it as well, down from about 1MB to about 200KB)... plus Acrobat warns about not being able to find the XObject.

Why do the linked images not show up in the 2nd attempt to export to PDF, and what do I need to do to prevent this?? Seems to me I had this issue way back with WPTools 4, but not sure what I did to fix the problem. I quick scan of that older source of mine didn't reveal anything obvious.

A print preview of the WPRichText after exporting the 2nd time still shows the images, yet the PDF doesn't have them.

I Updated to 5.20.8 and wPDF 2.75, and it made no difference. (was running with 5.20.6 and 2.65)

I think this problem has been ongoing for a while as I've received a few emails about their report not having images, but if they do it again, it does. I thought they had a few too many beers because we couldn't repro at the time, so now all I can think of is that they must have done an export twice when they noticed the report was missing images, and then went back again to export it, and it worked (since they only exported it once that time).

For completeness of this thread, I've added a compile switch, NUMBERACTION_FIRSTALWAYSRESTART, to WPCTRRich from 5.20.8 to enable code that will force the bullets to restart numbering if it is the first non-blank paragraph in a WPRichText, exactly as if there was non-blank non-bulletted text in front of it. Useful if you will be appending multiple independent WPRichText texts to build a new single WPRichText text and don't want the numbered bullets to unexpectedly change their sequencing should there be no other non-blank text ahead of it in any particular text.

I hope Julian can add it to the source code :)

First, correct what I think is a bug:

WPI_CO_NUMBERS:                  if Changing then                  begin                    if IsSelected then                    begin                       par := TextCursor.GetBlockStart(gr);                      {$IFDEF NUMBERACTION_FIRSTALWAYSRESTART}                       if (par<>nil) then                      {$ELSE}                       if (par<>nil) and (par.prev<>nil) then                      {$ENDIF}                          par := par.prev;                    end                    else par := ActivePar.prev;

Then the actual bullet logic for numbered bullets:

{$IFDEF RESTART_NUMBERING_ALA_MSWORD}
                        // - previous par is "empty" and pre-previous par is
                        // "numbered" then this number will continue
                        // - previous par is "non-empty" and pre-previous par is
                        // "numbered" then this number will restart


                        //JZ: Changed ActivePar to TextCursor.CurrAttribute
                        //JZ: Skip bullets V5.20.8
                        bStartNumber := FALSE;
                      {$IFNDEF NUMBERACTION_FIRSTALWAYSRESTART}
                        if (par <> nil) then
                      {$ENDIF}
                        begin
                          // empty, and non-numbered, remains searching
                          // while (par <> nil) and (par.IsEmpty ) and (not par.AGet(WPAT_NumberSTYLE, gr)) do
                          //  par := par.prev;


                          while par <> nil do
                          begin
                             par.GetNumberText(nsty,true);
                            if nsty<>nil then
                            begin
                               gr := nsty.AGetDef(WPAT_NumberMODE,0);
                               if (par.AGetDef(WPAT_NumberLevel, 0)>0) or
                                  ((gr<>WPNUM_BULLET) and (gr<>WPNUM_CIRCLE)) then
                               begin
                                    gr := par.AGetDef(WPAT_NumberSTYLE, 0);
                                    break;
                               end else bStartNumber := TRUE;
                            end
                            else if not par.IsEmpty then break;
                            par := par.prev;
                          end;


                          if GetAsyncKeyState(VK_CONTROL) < 0 then
                              bStartNumber := not bStartNumber;


                        {$IFDEF NUMBERACTION_FIRSTALWAYSRESTART}
                          if IsSelected then
                             block_s_par := TextCursor.GetBlockStart(zdiff)
                          else
                            block_s_par := nil;
                          if block_s_par=nil then
                            block_s_par := ActiveParagraph;


                          if (par = nil) then
                            block_s_par.ASet(WPAT_NumberStart, 1)
                          else
                          begin
                        {$ELSE}
                          if (par <> nil) then
                          begin
                            if IsSelected then
                               block_s_par := TextCursor.GetBlockStart(zdiff)
                            else block_s_par := nil;
                            if block_s_par=nil then block_s_par := ActiveParagraph;
                        {$ENDIF}


                            // Remove Number Start Attribute
                            TextCursor.CurrAttribute.ADel(WPAT_NumberStart);
                            TextCursor.CurrAttribute.BeginUpdate;
                            if (not par.IsEmpty) then // non empty, restart !
                            begin
                              if not par.AGet(WPAT_NumberSTYLE, gr) then
                              begin
                                if not bStartNumber then
                                   block_s_par.ASet(WPAT_NumberStart, 1)
                              end
                              else
                              begin
                                TextCursor.CurrAttribute.ASet(WPAT_NumberSTYLE, gr);


                                if bStartNumber then
                                     block_s_par.ASet(WPAT_NumberStart, 1);


                                if par.AGet(WPAT_NumberLevel, numlevel) then
                                  TextCursor.CurrAttribute.ASet(WPAT_NumberLevel, numlevel)
                                else
                                  TextCursor.CurrAttribute.ADel(WPAT_NumberLevel);
                              end;
                            end;
                          end;
                          TextCursor.CurrAttribute.EndUpdate;
                        end;
{$ENDIF RESTART_NUMBERING_ALA_MSWORD}

I tried to leave the code and comments as is, and just added the new code in the switch defined section. If there is a better way, I'd love to see it!

I think this is a bug in your number bullet code:

Original (current):

WPI_CO_NUMBERS:                  if Changing then                  begin                    if IsSelected then                    begin                       par := TextCursor.GetBlockStart(gr);                       if (par<>nil) and (par.prev<>nil) then                          par := par.prev;                    end                    else par := ActivePar.prev;

I think it should be:

WPI_CO_NUMBERS:
                  if Changing then
                  begin
                    if IsSelected then
                    begin
                       par := TextCursor.GetBlockStart(gr);
                       if (par<>nil) then   // <-- changed line
                          par := par.prev;
                    end
                    else par := ActivePar.prev;

With the original code, if the paragraph selected is the first paragraph, the logic will be using the attributes of the selected paragraph instead of the previous paragraph. Note that if the cursor was on the first paragraph and nothing was selected, par = nil, but if the first paragraph was selected, par <> nil but rather par=par.

By pure luck it still works fine, but might not in the future (plus unfortunately it won't work fine as is when I add my needed change that I'm going to have to put in place to force the first par in a WPRichText to always restart numbering).

But it's what my users expect. Let do a poll! ;)

Seriously though, I understand, but please consider making it a compile switch or a property. Or even a new event "AfterBulletSet".

May I make one small request?

In building a final document, I combine multiple WPRichText's together. If one WPRichText ended with a numbered list, and the next WPRichText starts with a numbered list, the 2nd set continues the numbering.

You seem to have it restart the numbered list if the previous non-empty paragraph was not a number list... perfect, but can you also make it so that if the numbered list is the first non-empty paragraph to also set the flag to restart the numbering (i.e. WPAT_NumberStart, 1)? This way, combining two WPRichTexts won't affect the sequencing as the user saw it when editing the two WPRichTexts separately. I hope I was clear.

Thanks

Something didn't get copied right since there is a compile error... see the code near

if nsty<nil>0) or
                                  ((gr<>WPNUM_BULLET) and (gr<>WPNUM_CIRCLE)) then
                               begin
                                    gr := par.AGetDef(WPAT_NumberSTYLE, 0);
                                    break;
                               end else bStartNumber := TRUE;
                            end
                            else if not par.IsEmpty then break;

The "if nsty<nil>0)" gets flagged obviously. It appears the forum stripped off part of the code. I say this because I tried to post the "before" code, and doing a preview showed that it was stripped for me too. So I'm concerned that something got lost in the post. Please review or maybe email me the change.

BTW, I assumed that section of code shouldn't have been changed, and put the original back, and it apears to work OK (the 2nd group gets sequenced properly).

Thanks

Hi,

Your fix for 5.20.8 is not quite the same as my original suggestion to fix the problem... i.e. you are still not waiting long enough for the double click to occur (your code still only waits 200 ticks tops). Please look at my original suggested fix and you'll see what needs to happen.

But I've changed my suggested fix based on what you did... so for example, try changing your code from:

waitt := GetDoubleClickTime();  if waitt > 100 then waitt := 100;  tim := GetTickCount + waitt; // was 100;  pt := Mouse.CursorPos;  while (GetTickCount < tim) do ;  tim := GetTickCount + waitt; // was 100;

to:

waitt := GetDoubleClickTime();
  tim := GetTickCount + 100;
  pt := Mouse.CursorPos;
  while (GetTickCount < tim) do ;
  // Wait for a double click, but account for the time already passed
  if waitt < 100 then
    waitt := 1
  else
    Dec( waitt, 100 );
  tim := GetTickCount + waitt;

Hopefully you can see the difference.

Bullet numbering is still not working correctly... Try this:

a
b
c

a
b
c

a
b
c

Select the first set of a, b, c, and click the numbered bullet list on the toolbar. Now select the 3rd set of a,b,c, click the numbered bullet list on the toolbar... the result:

1. a
2. b
3. c

a
b
c

1. a
1. b
1. c

WPTools 5.20.8
Delphi 7

If an image is on a line by itself and is marked to be centered, it shifts offcenter if the left indent is not 0.

For example, add this:

center
<image>

Where <image> is an image. Select all, and set to justify center. Both should now appear centered in the WPRichText. While all is still selected, drag the left indent to the right. The text adjusts itself to be perfectly centered based on the indents, but the image does not... increasingly shifts more right than the text.

WPTools 5.20.8
Delphi 7

Julian,

I see that code in WPCTRRich, but "b" is false, so the font size shows blank. Sometimes I see that section of code trigger twice, b is true at first but then it gets called again, and b is then false.

I'm still using 5.20.6 (for various reasons), but unless there is some subtle differences in the code posted in your reply is different than what is in 5.20.6, there is a bug somewhere.

Can you put these on the wish list for TWPRuler enhancements:

1. Add a property to allow specification of the cursor to use when dragging the indents, i.e. allow the cursor to not be crSizeWE when dragging the indents so it is more like Microsoft Word. Sigh, believe it or not, I get this request even though I personally think crSizeWE is the proper cursor and Word has it wrong... but alas, Microsoft rules and people like consistancy in their lives.

2. Add an interval property so that when using inches, I'm not restricted to 1/8 inch intervals when dragging a tabstop (I know about the ALT key, but I'd like 1/16th inch intervals, and even 1/4 inch intervals at times, without having to modify the source on every WPTools update).

Thanks!

I do need reading glasses, but for sure the cursor is positioned to the RIGHT of the period, but acts like it is to the LEFT of the period when I hit the space bar... if I hit any other char, it adds the char to the right as expected.

It is hard to reproduce, but it happens enough that it shouldn't take that long. You have to try it at several places, don't just keep trying the same line at the same spot in the line.

Again, I'll try to save a reproducible example. Otherwise you might as well ignore it since it sounds a bit odd I have to admit.. but it does happen!

When encrypting a PDF document with a user password and the option to prevent text from being copied, the Adobe Acrobat Reader version 7.0.8 reports an error (but continues to run). The error is:

Could not find the XObject name "WPToolsJIF_1".

Note, the _1 varies, for example, it came up as "WPToolsJIF_73" once.

If I allow text to be copied from the PDF, I don't get this error.

WPTools 5.20.6
wPDF 2.6.5
Delphi 7

I have on several occasions been adding text to a WPRichText during runtime, and had to go back to add text to the end of a paragraph that ended with period. When I position the text cursor to the right of the period to add more text to the end of that paragraph, all text gets inserted to the left of the period if I begin the new text with a space!! Pushing the period right.

For example, if I went back to add " Test" to the end of the above paragraph, I would end up with: "Pushing the period right Test." and I wanted: "Pushing the period right. Test"

I have to delete the period to get it to add text properly. Unfortunately, it is hard to duplicate. I'll try to catch it when it gets into this state, but perhaps it is something obvious that you see in your code.

WPTools 5.20.6
Delphi 7

Sorry Julian, but I am getting a bit frustrated in that I am constantly asked the question as to why the font size in the toolbar is blank!!

It is blank because the font size is the default font size, but a user has to select some text before it will show them what the heck font size is.

The main problem is that a user wants to set some text the same size as some other text, but they don't know what that size is. So I get the call and have to tell them to select some of it, then you will see what the size is... and that is followed by an apology from me that I can't fix it.

Please find a way to show the current font size on the toolbar even when it is using the default size.

Thanks,
Eric

WPTools 5.20.6
Delphi 7

I changed the threshold value used in WPCTRMemo from 100 to the system setting in Windows, and it made a profound difference!! It seems to work great now on the tablet.

Code change in the TWPCustomRtfEdit.Click procedure:

isDblClick := FALSE;
  tim := GetTickCount + 100;
  while (GetTickCount < tim) do ;
  tim := GetTickCount + GetDoubleClickTime();//100;
  while (GetTickCount < tim) and not isDblClick do
    if GetAsyncKeyState(FVKLeftMouseButton) < 0 then isDblClick := TRUE;

Only change was to the second instance of setting tim. It was 100, I changed it to the Windows API GetDoubleClickTime() function call.

Double clicking using Notepad for example pretty much selects the word when double clicking at almost any speed (time between the two clicks).

However, double clicking in a WPRichText is hit and miss. While it does work, it is still only about half as forgiving about the speed of the double click as it is when using Notepad.

I'm getting a lot of complaints about the double clicking not working reliably, especially on tablet PCs (I have found it extremely sensitive on tablets no matter what adjustments I make to the pen settings, but it is also very noticable on a standard PC using a mouse).

Additional info which might help or confuse things even more:
A very fast double click seems to work 100%, but things seem to get out of sync if you double click at a medium speed. By out of sync I mean I can continually double click at that speed and it never selects the word until I move the cursor pos and do it again. Then doing it again at that medium speed will work quite well... or until it gets out of sync somehow.

It is like you have your own double-click logic and the spatial tollerance (i.e. distance between two succesive clicks), is too small... hence the increased problem on a tablet PC (and any changes to the pen settings for this makes no difference in WPTools)

Can you please take a look at this. Thanks!

WPTools 5.20.6
Delphi 7

Why does the OnDblClick event occur when dragging some selected text???

WPTools 5.20.6
Delphi 7

I don't notice any side-effects after commenting out that section of code other than fixing the problem I had. :)

If I use the following code to insert a bookmark in the first table cell's paragraph:

BookmarkInput( '_Toc_' + TNavDocument(node.Data).ID, true );
ActiveParagraph.ASet(WPAT_ParIsOutline,2);
InputString(nodeDesc);

The first cell's alignment is thrown off (too low as compared with other cells in that row). Yes, I have BookmarkTextAttr.Hidden set to true.

If I don't issue the "InputString", the alignment is what it should be.

I'll email you samples. But note that the alignment issue is very significant if the cell's font is small, like a point size of 7. It appears to align the text using the font size of the hidden text which, in the example I've sent you, is larger than the visible text... based on what I see in the RTF anyway. In general, I would think the font size of hidden text should be ignored.

I can get around the problem by setting the font size really small just ahead of the InputString:
"CurrAttr.Size := 1.0;"

WPTools 5.20.6
Delphi 7