Macro starbasic with search of text with attribute not work if attribute is UNO struct and ValueSearch=true

English
, , ,
#1

The attached file performs an attribute search test with a starbasic macro that uses the createSearchDescriptor method.
The attribute is CharBottomBorder modified by the application of character styles xIniz (creates a top border but not a bottom border) and xFine (creates a bottom border but not a top border)
For this the searches assume the property searchStyle true, otherwise the search would not recognize anything.
The button on the left performs a search on the attribute setting the ValueSearch property false
Only the texts associated with an attribute change are correctly recognized, regardless of the format (value) applied.
The function AFTER selecting the recognized text saves the content of the CharBottomBorder property, a UNOstruct new com.sun.star.table.BorderLine2, and uses it as the format for the second search (button on the right) which sets ValueSearch to true on the contrary
In this case, for the recognition, the modification of the attribute is not enough: this must assume a precise format, and to be sure to define it correctly I obtain it directly from the text recognized in the first search (ValueSearch = false)
It should recognize two paragraph texts, but it recognizes nothing
Why? Are attributes consisting of a struct not recognized?
With other attribute searches (e.g. CharColor, CharFontName, CharBackColor, etc) I have no problem
Libreoffice 7.3.5.2 ubuntu 16.04

askSearchAttribute.odt (20.9 KB)

#2

I propose the problem in another way:
Suppose oTR is a reference to a textRange of a selected text (in my macro in the attachment it was the variable ox)
Have the following code:

global oBorderLine as new com.sun.star.table.BorderLine2
global oBorderLine2 as new com.sun.star.table.BorderLine2

oBorderLine = oTR.CharBottomBorder
oBorderLine2 = oTR.CharBottomBorder

Both oBorderLine and oBorderLine2 point to the same oTR.CharBottomBorder object
Their type also coincides with that of CharBottomBorder (they are all instances of com.sun.star.table.BorderLine2)

why after running the following statement

b = EqualUnoObjects (oBorderLine, oBorderLine2)

b is false?

In my research with attributes it is as if the equality of the CharBottomBorder could not be recognized with anything, not even with its current value, assigned to a homogeneous variable as type
Am I doing something wrong ?

#3

I didn’t check deep; but possibly tdf#106984 has something to do here; see my comment there.

Why do you think they point to the same object?
Anyway, a struct is not UNO object (in this function’s sense) - it only compares objects implementing UNO interfaces.

#4

Thanks, you are right. In fact a UNO struct is an object but not a UNO object (does not support css.uno.XInterface)
So there is no point in testing for equality with the EqualUnoObject function

But, clarified that oTR.CharBottomBorder is a structure, if I run

oBorderLine = oTR.CharBottomBorder
oBorderLine2 = oTR.CharBottomBorder

I think that since oTR.CharBottomBorder is in common (oTR is a text range of pure text) the two variables should point to the same struct oTR.CharBottomBorder

Or am I wrong something?

I started reading your comment, it is at the limit of my knowledge, I need some time to understand it.
It is possible that it has to do with my problem, which apparently I can only solve, for now, with a first search with valueSearch false and then scan the textranges found by manually testing the values ​​of the struct, which however was just what I wanted to avoid, thinking you could do it all in one step

#5

There should be no pointer semantics here; e.g., changing a member through oBorderLine should not affect neither the respective member of oBorderLine2, nor of oTR.CharBottomBorder.

#6

See sections 10.1, 10.8 and other references to UNO structures in the book by A. Pitonyak OOME_4_0.odt.

#7

Even after re-reading A. Pitonyak, of which I had forgotten some considerations recalled by @mikekaganski on structures, I have not found a solution

The CharBottomBorder property is of the com.sun.star.table.BorderLine2 type, a structure that directly provides two properties (LineStyle and LineWidth) in turn derived from com.sun.star.table.BorderLine from which it inherits 4 properties (Color, InnerLineWidth , OuterLineWidth, LineDistance) which, in turn, does not seem linked or connected to anything else.

These are the references:

BorderLine

com :: sun :: star :: util :: Color Color
short InnerLineWidth
short OuterLineWidth
short LineDistance

BorderLine2.html

short LineStyle
unsigned long LineWidth

The com.sun.star.table.BorderLine2 structure is used in different contexts, especially in the css.table.tableborder structure, but it would appear not to depend on or be associated with other UNO elements that may affect the search

Once all the values ​​of the own and inherited properties have been set at the same time, assigning them all in the comparison structure, I don’t understand what else is affected

I also tried, just to be sure, to create an array of propertyvalue (dim args (5) as new com.sun.star.beans.PropertyValue by assigning all 6 properties separately, but obviously it gave me error as I tried to assign it to SearchProperties

By default all the properties of com.sun.star.table.BorderLine2 take the value 0, and in fact the search with valuesearch = true and comparison term a struct with all the properties set to zero selects all the paragraphs with the unchanged CharBottomBorder property

This search is obviously complementary to the one with valuesearch = false, which obtains all the textRange with CharBottomBorder whatever the type of modification

Is there a way to understand if this structure is associated with other UNO structures / objects that may interfere?

References to this type of code BorderLine_8idl_source.html also don’t help

#8

I seem to be starting to understand the question. :slightly_smiling_face:
Do you want to set the name and value of the property in the search attributes, and the property value is UNO structure?
Not sure if this can be done.

#9

In the meantime, thanks to everyone for their contributions
The problem is this: the value of a property being searched is a structure.
This is the case with the CharBottomBorder property
I have attached a file with the code.
If manually or with a style I modify this structure in a textRange, the search with ValueSearch = false recognizes that the default of CharBottomBorder has been changed, then it recognizes all the paragraphs to which, for example, a style has been assigned that modifies the default of the border
This is my case, in fact in the search I set searchStyles = true.
If, on the contrary, I assign a comparison structure with all the property values ​​set as I see them in the ONE object inspector of writer 7.3.5.2 that I use, the search does not give any match
The compromise solution I used is to first run a search with valuesearch = false and then scan the results by testing the charbottomborder property manually.
For now I have not found anywhere in the documentation a reference to limits in the use of structures in search with macro, it is simply not mentioned
And an answer in this particular case can be extended and be of help in other similar cases with properties to look for consisting of structures
If anyone can provide me with any reference in this regard, thank you very much because it prevents me from continuing with useless tests (which, however, I think I have exhausted, I do not know what else to try)

#10

@mikekaganski: Based on my “1965-style” thinking I would assume that any programming style / system / language / paradigm should provide means to compare content-keeping entities for equal (identical) content. Where content is represented by pointers, the pointers may be compared (regarding the obvious complications). After all, a “paradigm” may be as abstract as theory requires, but should not deny or ignore the fact that content has to be kept somewhere at runtime. Why isn’t there info about starting point and length for and binary access to any item represented in RAM (or somewhere) in one or another way? Complete information concerning what’s direct/simple storage and what’s pointers or indirect in whatever way shouldn’t be needed for a decision concerning the “deep equal”. Having used various implementations of Pascal for some time, I can hardly imagine reasons for what such means should be omitted.
What’s wrong with my thinking? Is it just a problem due to null-termination? Can’t believe.

#11

@Lupp: I’m sure you wrote your thoughts to initiate a discussion, not to imply that I said something that disagreed with your valid points? Note that I agree with you, and what I wrote above was to help see the current state, rather than to say that “this is the best possible implementation!!!1111” :slight_smile:

#12

What I wrote was mainly meant to be an actual question (slightly OT) of the kind “Why is it this way? I think it should be different.” I’m well aware of the fact that my thinking may be outdated. You are a professional in the field for (at least) years now, while I was something of the kind for 12 weeks in 1968. Insofar I feel “refreshed” a bit by your statement to also not be exactly glad with the current state.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.