HTMLviewer and declare function searchFor

Targets macOS
1

Hello,
running the code below I get a strange behavior, in the sense that the searchFor function, as it were, freezes the app until it returns the result: the flying pizza shows up and Activity Monitor shows Memory usage rising from 30MB to 500MG each time the function is called.

Now, the folderitems I’m passing are all PDF files, some of them small, and some around 400KB.
Apart from freezing the app, another strange thing is that if no match is found, I have to wait for several seconds, while if a match is found, the result is pretty immediate. One would say that the code is running in a synchronous way.

So, is the way I’m using this process all right, or am I overlooking something obvious?

Suggestions welcome. Thanks.

BTW: I know that the function below is flagged as “deprecated”; but it seems newer related declares are still beta.
//https://developer.apple.com/documentation/webkit/webview/1408343-searchfor?language=occ

  1. Load the folderitem
    HTMLViewer1.LoadPage(f)

  2. after the page is shown, I click a pushbutton with this code:

Sub Action() Handles Action dim result as Integer if HTMLViewer1.htmlSearchFor("Hello",false,false,false) then result = 1 else result = 0 end if End Sub

[code]Public Function HTMLsearchFor(extends v as HTMLViewer, text as String, forward as Boolean, caseSensitive as Boolean, wrap as Boolean) as Boolean

#if TargetCocoa then
declare function searchFor lib “Cocoa” selector “searchFor:direction:caseSensitive:wrap:” (obj_id as Integer, inText as CFStringRef, inForward as Boolean, inCaseSensitive as Boolean, inWrap as Boolean) as Boolean

Return searchFor(v.Handle, text, forward, caseSensitive, wrap)

#endif

End Function[/code]

2

A function called from your program is executed in your program thread.
Creating another Xojo thread and calling the same function in this thread produce the same result.
This is the nature of Xojo’s cooperative thread system: only one thread runs.
To have the same function executed in an async way you need to create a plugin or a dll with another tool/language that create a non Xojo thread that calls the function.

3

In fact I noticed it because I had tried to run the code in a thread and getting the same problem.
But I hoped…

4

Just for the records: using a helper app things get all right, although speed, although better, is still pretty sluggish.

5

Did you try with HTMLViewer.SearchForMBS instead in MBS Xojo Plugins?

6

@Christian: I do not use plugins.

But I’d like to point out that the “sluggishness” happens only with somewhat big PDF files (from 400KB to several MB); feeding html files, it is as quick as the wind.

Actually I’m baffled by the fact that, (in a normal environment without the need of helper apps), the HTMLselectAll (+ copy) method (below) that works well for html files does not work for PDF files opened in a htmlViewer. Or to be more precise, HTMLSelectAll works only after I manually click into the htmlViewer page.
I tried several javascripts to force a click or to select portion of the content, but, like HTMLSelectAll, these javascripts too work only for html files, leaving PDF files unresponding. I guess the reason is that PDF files are loaded as embedded frames, not in the usual of html files.

Public Sub htmlSelectAll(extends v as HTMLViewer) //# Selects the entire text. #if TargetCocoa then declare sub selectSentence lib "Cocoa" selector "selectAll:" (obj_id as Integer, sender as Integer) selectSentence(v.Handle, v.Handle) #else #pragma Unused v #endif End Sub

7

Maybe it’s just a limitation of the PDF viewer in WebKit?

8

That’s my guess too.