Closed AshfordN closed 3 years ago
@AshfordN I've added the ScnLoadData.RequestId()
function. As for the
the request simply times out.
May be Andrew @c-smile could spot a misusage in your code.
Instead of synchronous request as in your case try asynchronous request like this:
function self.ready() {
self.timer(500ms, ()=>{
view.request {
url: "db:test",
output: #string,
complete: function(data,status) { stdout.println(data.toString("utf-8")) },
error: function(err,status) { stderr.println(err.toString("utf-8")) },
};
});
}
Thanks @c-smile, this works. @pravic I've made some suggestions to #281. With that, everything should be in order now.
I'm currently working on a project where sciter (i.e. a loaded script) needs to request resources (and other data) from a DBMS. So, I'm trying to implement a callback handler to respond to the
SC_LOAD_DATA
notifications of such requests. My intention is to returnLOAD_DELAY
immediately, query the database from a separate goroutine, and then callsciter.DataReadyAsync()
, with the returned data, from that same goroutine. However,sciter.DataReadyAsync()
takes therequestId
as its third parameter, but the go-sciter API doesn't appear to give access to that value; and if I passnil
as therequestId
, the entire DOM is reloaded with the returned data. Below is the basic design of my handler code:Now, as mentioned, when the above code is called to handle a request, the entire DOM is reloaded to display the text: "sample data". I've tried implementing the accessor function that is out-commented in the code above, as shown below:
However, if I use the accessor function to get the
requestId
, and callsciter.DataReadyAsync()
as follows:the request simply times out.
Below is the TIScript code making the request:
EDIT: Also, in the first block of code, there's a comment that highlights the fact that
params
is no longer valid at that point. What this means, is that callingparams.Uri()
at that point sometimes return erroneous data, and causes a segfault. So, I feel like a big part of why this isn't working is because the underlying C++ object is being destroyed, and Go just ends up holding an invalid reference.