is CBlock functionality documented anywhere?

[MISV]

For instance I have a WKWebivew.evaluateJavascript_completionHandler where a parameter is OpaqueCblock (the first is the Javascript code)

I think it is a kind of closure but is there any documentation?

Do I need to enable some defines? What is the syntax? OpaqueCBlock is simply defined as a pointer...

Here is Apple help:
https://developer.apple.com/documentation/webkit/wkwebview/1415017-evaluatejavascript

But I am more interested what the syntax is in Lazarus/FPC

It is something like this I want:

     

Code: Pascal  [Select][+][-]

1. FWebBrowser.FWebView_CocoaWKWebView.evaluateJavaScript_completionHandler('document.documentElement.outerHTML',
2.         //procedure (const AStrResult: string)
3.         //begin
4.         //  TmpGetDocumentAsStr := AStrResult;
5.         //  TmpCS.Acquire;
6.         //  TmpExecuted := True;
7.         //  TmpCS.Release;
8.         //end
9.       );
10.  

[trev]

When I was floundering with cblocks, I believe I found my answers in the release notes and posts on the FPC mailing list:

* https://wiki.freepascal.org/FPC_New_Features_3.2.0
* the mailing list refereence for exampels went to svn.freepascal.org

You can look at some of my Wiki articles for examples:

* https://wiki.lazarus.freepascal.org/macOS_MIDI_Player
* https://wiki.lazarus.freepascal.org/macOS_NSURLConnection
* https://wiki.lazarus.freepascal.org/macOS_NSURLSession
* https://wiki.lazarus.freepascal.org/macOS_NSAlert

Hope that helps.

[MISV]

Thank you Trev, I will take a look.

What confused me about the two first examples, e.g.
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/tblock1.pp

is that their code show a completely different declaration than evaluateJavaScript_completionHandler uses

i.e. completionHandler is of type OpaqueCBlock which is simply defined as a pointer.

... But I can see in example:
https://wiki.lazarus.freepascal.org/macOS_NSURLConnection
that you redefine the declarations so... I guess that is the solution as well...

i.e. I need to redeclare/override the evaluateJavaScript_completionHandler declaration somehow


Hmmm I will look at it some more.

Extract question.I see you use modeswitch cblocks, but what is modeswitch cvar ?

[trev]

Extract question.I see you use modeswitch cblocks, but what is modeswitch cvar ?

I could not find the cvar modeswitch in the examples I pointed you to, but the best explanation of cvar is here.

[Edit later]
Be aware that "cvar" does not mean "do not mangle", but "mangle in the same way as the system's C compiler would". I've logged a bug for the documentation I referred to above.

[MISV]

Okay. I have posted a question in WKWebView Cocoa thread... but it relates to this
https://forum.lazarus.freepascal.org/index.php/topic,42001.msg429839.html#msg429839

About redefining the delegate and what is required (as far as I can tell, Zoe does it slightly different than you)

Just trying to understand how the internals work... e.g. is there some special compiler magic with OpaqueCBlock that allows it to simply redeclared in implementor to something entirely different?

[trev]

OpaqueCBlocks are pretty opaque! I could never find an explanation.

First I tried leaving the declaration as OpaqueCBlock which compiled but resulted in a fatal runtime error.  My approach was then to consider an OpaqueCBlock to be an opaque pointer to a cblock: ie a data type declared to be a pointer to an unspecified code block. My code then compiled, did not suffer from a runtime error and the program worked as expected.

Of course my explanation/understanding may be completely wrong (bear in mind that I have three law degrees and no programming qualifications).

[MISV]

Thank you Trev

[MISV]

I will take a another stab at solving this for getting the source code / DOM after AJAX (but only way of getting source AFAIK)

FWebBrowser.FWebView_CocoaWKWebView.evaluateJavaScript_completionHandler('document.documentElement.outerHTML',
...
      );
 

[Jonas Maebe]

The OpaqueCBlocks predated FPC support for cblocks. So they're basically untyped parameters used as placeholders for cblock parameters.

To have proper cblocks support, the parser that generates those headers needs to be updated to emit actual cblock-typed parameters instead.