What the function does is bind some Script::Variant value to the
javascript window object (or something else, depending on the name)
Many values are constants, like strings, integers, booleans, null, etc.
However, there are two special types of Script::Variant, which you get
by constructing:
Script::Variant::bindFunction(WideString name, bool synchronous);
As an example, glut_input.cpp does this:
bk_texture_window->window()->addBindOnStartLoading(
Berkelium::WideString::point_to(L"glutCallbackSync"),
Berkelium::Script::Variant::bindFunction(Berkelium::WideString::point_to(L"glutCB"),
true));
The first string "glutCallbackSync" is the object that appears in
"window" (it literally appears as the left side of an '=' expression)
The second string "glutCB" is the string that is passed to
WindowDelegate::onJavascriptCallback in glut_util.hpp
The "true" indicates that the function is synchronous, and javascript
execution will halt until it returns a value (if it does not return a
value, the page will hang).
So putting this together, what happens is
window.glutCallbackSync(arg1,arg2...) will run
WindowDelegate::onJavascriptCallback and return a value.
Also, one thing to watch out for: Berkelium does not implement arrays or
objects, so each arg1,... passed must be string, boolean, number, or null.
Anything else will result in an error message passed to
WindowDelegate::onConsoleMessage and the function will return null.
I'm attaching a sample html page that will work with glut_input. If
things are working correctly, you should see onJavascriptCallback()
displayed in your terminal window, intermingled with alert boxes.
> 2. If so, is there a simple explanation of how to use them? All I
> really need to do is to get the value of document.body.scrollwidth and
> document.body.scrollheight when a page loads.
>
> Thanks!
For your question #2:
You should make sure to check scrollWidth and scrollHeight only when the
page finishes loading (WindowDelegate::onLoad). One way to do this is to
execute javascript, calling your callback with those values, as you
suggest. I would suggest passing "false" to make the callback
asynchronous so that the page will be more responsive.
The API is somewhat clunky because it is limited by the IPC calls
defined between parent and child -- and there's no call for "run
javsacript something and return its result", so the callback madness is
a reasonable solution.
-Patrick