Ian Laurenson wrote:
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:
i agree that sometimes the generic interfaces are not enough (here
XSearchable, where the first parameter of findNext only specifies the
start point).
I can only say please communicate the weakness of API's and/or submit
RFE's so that we can try to improve it. I know that we have such
weakness in a lot of areas of the API. But i also know that it is not
easy to improve it that it would be sufficient for all use cases.
Especially missing documentation (e.g. properties, interfaces) are bad
and can be fixed simply.
Juergen
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
