[Solved] OO Writer - Identifying Duplicated Paragraphs

[Col]

I would be grateful if someone could help me out here. I have just moved to Open Office and am gradually finding my way round it. I have a little experience of VBA which I used with Excel but every time I try to run an Excel/ Word vba macro OO doesn't like it and it doesn't work. I did think that there was a degree of compatibility with VBA macros but it seems there is very little or none as I'm finding out. The vba syntax is different from that of OO so finding my feet is rather difficult.

I have an OO macro (see below) which deletes paragraphs which have somehow got duplicated within a single file - probably my carelessness with cut and paste. This macro leaves a blank space where a paragraph has been deleted. I would be grateful if some kind person could help me by changing the coding of the macro so that it does not delete the duplicated paragraphs but only converts them to uppercase. I've had a look at the macro but gave up in despair as I didn't have the knowledge to do anything with it. This macro runs ok in OO version 4.1.7.

By the way, does anyone know of a script or software to convert VBA macros to the OO macro language?

Thank you

Code: Select all

      
Sub DeleteDuplicateParagraphs
oDoc = ThisComponent
enum = oDoc.Text.createEnumeration
While enum.hasMoreElements
thisPara = enum.nextElement
s = thisPara.getString
c = c + 1
If Len(s) > 0 then
Check(s,c,oDoc)
EndIf
Wend
End Sub

Sub Check(s,c,oDoc)
enum1 = oDoc.Text.createEnumeration
While enum1.hasMoreElements and c >= cc
enum1.nextElement
cc = cc + 1
Wend
While enum1.hasMoreElements
nextPara = enum1.nextElement
ss = nextPara.getString
If ss = s then
  ss = ""
  nextPara.setString(ss)
EndIf
Wend
End Sub

[FJCC]

I can't find a simple way to change the case of the paragraph. I may well be overlooking something obvious. This code makes the duplicate paragraph red. Will that work?

Code: Select all

Sub DeleteDuplicateParagraphs
oDoc = ThisComponent
enum = oDoc.Text.createEnumeration
While enum.hasMoreElements
thisPara = enum.nextElement
s = thisPara.getString
c = c + 1
If Len(s) > 0 then
Check(s,c,oDoc)
EndIf
Wend
End Sub

Sub Check(s,c,oDoc)

enum1 = oDoc.Text.createEnumeration
While enum1.hasMoreElements and c >= cc
enum1.nextElement
cc = cc + 1
Wend
While enum1.hasMoreElements
nextPara = enum1.nextElement
ss = nextPara.getString
If ss = s then
  nextPara.CharColor = RGB(255,0,0)
EndIf
Wend
End Sub

[JeJe]

UCase function

Code: Select all

  ss =UCase(ss)

[JeJe]

OOBasic and VBA are very similar in the parts which don't relate to doing things with their respective Office Suites - but are largely different when it comes to manipulating documents etc. You probably have to rewrite them yourself. LibreOffice has I'm told got a little more compatibility.

[John_Ha]

I can't find a simple way to change the case of the paragraph.

Does this help? I recorded a macro where I used Format> Change Case > UPPER CASE

Code: Select all

sub change_case
rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
rem dispatcher.executeDispatch(document, ".uno:ChangeCaseToUpper", "", 0, Array())

end sub

I have just moved to Open Office and am gradually finding my way round it.

Andrew Pitoynak's book on macros is very good - see https://www.pitonyak.org/oo.php

[Lupp]

By the way:

It's common behavior of AOO and LibreOffice API to ignore objects anchored "To Character" or "As Character" when comparing paragraph strings using the API. This may be intended and regarded reasonable.

However, I would see it as a bug that in case of "As Character" the object gets lost when newly assigning the .String property if any calculation took place, even it wasn't (acceptably) changing the string at all (like NewString = "" & OldString). To do so is again common behavior of both branches.

Strangely the bug refuses to work if the old value of .String is formally reassigned.

Conclusion? You cannot get securely reliable and consistent results by any software. Let's get happy with artifcial intelligence and real-time networking. However, we may not survive it.

[John_Ha]

Conclusion? You cannot get securely reliable and consistent results by any software.

Agreed!
In the 80s I went to a conference on software reliability. The consensus was that you could write reliable code up to about 3,000 lines but that was the absolute maximum. The code specification, writing and testing worked out at about $1,000 a line.

[Col]

Many thanks to all who responded and offered their helpful advice. JeJe correctly offered the asked solution but FJCC, while not providing exactly what I asked, offered an alternative which on reflection is better suited to my need. Many thanks to JohnV who wrote the original macro I found.