On Wed, 2005-06-01 at 10:06, Mathias Bauer wrote:
> Ian Laurenson wrote:
>
> > * In Writer searching is at a document level thus coding for searching
> > within a selection is extremely tedious and the resulting code is slow.
>
> Interesting, can you provide an example that shows the problem?
>
oSearchDescriptor = thisComponent.createSearchDescriptor
oSearchDescriptor.setSearchString("the")
oFirstSelection = _
thisComponent.getcurrentController.getSelection.getByIndex(0)
oFound = thisComponent.findNext(oFirstSelection, oSearchDescriptor)
As FindNext is only a method of the Writer component and not of a text
range, if the search string is not in the selection the code continues
searching until either the end of the document or the string is found,
where upon you need to check if it is inside the range with something
like:
bFound = (thisComponent.getText.compareRegionEnds(oFound, _
oFirstSelection.getEnd) > -1)
But this is an over simplification as the text ranges may not belong to
the same text range (e.g. in Table), and the end of a text range is
determined by the direction of the selection.
For a more complete and working example see: IannzFindReplace.sxw
available from: http://homepages.paradise.net.nz/hillview/OOo/
> > * Having an enumeration for PageLayout that doesn't include an option
> > for "none" when you simply aren't concerned about duplex printing.
>
> Sorry, I don't understand this. Can you show it with a few code lines?
>
I was referring to:
http://www.openoffice.org/issues/show_bug.cgi?id=3910
This issue is about the difficultly to avoid having a blank page
automatically inserted to make sure that odd numbered pages are always
right facing pages.
All of the enumerations for com.sun.star.style.PageStyleLayout are about
left and right facing pages, there is no way of specifying that left and
right facing pages are to be ignored, which is relevant for simplex
printing or as a desirable option for electronic "printing".
> > A much higher priority for me is having more in the API such as the
> > ability to easily have docked/floating windows in extensions.
>
> This is a feature we have considered for the next release. The biggest
> obstacle is that we lack a proper GUI toolkit, but at least we should be
> able to offer all controls you can use in a basic dialog also for
> docking/floating windows.
>
> As an example, we could use the xml description of a Basic dialog and
> declare it as a floater or a docking window.
>
Docked/floating windows is quite an important issue for me.
Is there anyway that I can create a component with this functionality
now?
or
Should I look into helping to change the source code for this issue
(this would be my first attempt at writing OOo source code - so I may
need some help)?
or
Should I just be patient and wait?
Thanks, Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
