Ahh I thought pcommand was something you replace with your plugin name. Gotcha.
Unless I'm doing something wrong, this method of communicating via farr:// and Wb.ExecJavascript doesn't seem to be that robust. For example, a simple test page with
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<script>
var timesrun = 0;
function runthis(str)
{
timesrun++;
document.getElementById("link").innerHTML = ""+timesrun;
document.getElementById("link").click();
}
</script>
</head><body>
<a id="link" onclick="location.href=this.href" href="farr://pcommand RETURN something">Send return signal</a>
</body></html>
And then in the plugin
BOOL MyPlugin_SetStrVal(const char* varname, void *val)
{
// farr host will pass us function pointer we will call
if (strcmp(varname,DEF_FieldName_NotifySearchCallbackFp)==0)
callbackfp_notifysearchstatechanged = (Fp_GlobalPluginCallback_NotifySearchStateChanged)val;
std::string s(varname);
if (s.find("pcommand",0)!=std::string::npos)
{
MessageBox(0,"Received message from javascript. Calling js function.",varname,0);
callbackfp_set_strval(hostptr,"EmbeddedWb.ExecJavascript","runthis('something')");
return TRUE;
}
return FALSE;
}
Then igo [the html page].
Click the link, and at least for me, the link sends the farr:// command 3 times, but the plugin only receives it twice, and the loop isn't infinite as it should be.
I tried adding a delay in case windows doesn't handle executing protocols quickly or something, but to no avail.
I have a backup method with an XMLHttpRequest object if the above method isnt possible, but before I give up with it, any suggestions?