No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Setting response type on RPCRequest objects

    Brower: Chrome Version 81.0.4044.138 (Official Build) (64-bit)
    SmartClient version: v12.0p_2019-06-12/LGPL Deployment (built 2019-06-12)

    I've implemented a multi-file download scheme using the RPCManager class, but I needed to set the responseType property of the underlying XMLHttpRequest object. I didn't see a public attribute in the SmartClient documentation to allow me to do this, but I noticed a xmlHttpRequestResponseType attribute for the RPCRequest class in the SmartClient source code. I was able to use this property successfully for my implementation. Is this attribute safe to use? Is there a public attribute I can use to set the responseType?

    Could you explain what you're up to here? Are you trying to issue an XMLHttpRequest that the browser handles as a download (like pops up a "Save As..") dialog, or something else, like binary handling in JavaScript?


      I'm downloading files as binaries. Here's the snippet of code I'm using:

      records.forEach(record => {
      actionURL: download_Url,
      contentType: "application/x-www-form-urlencoded",
      params: {
      FileID: record.FileID,
      httpMethod: "POST",
      useSimpleHttp: true,
      showPrompt: true,
      xmlHttpRequestResponseType: "arraybuffer",
      callback: function(response, data, request) {
      if (response.status === isc.RPCResponse.STATUS_SUCCESS) {
      var blob = new Blob([data]);
      var link = document.createElement("a");
      link.href = window.URL.createObjectURL(blob); = getFileName(response);




        Well, you are already in unsupported terrain because we don't document any of our handling of "arraybuffer" response types - it's neat that it "just worked"!

        It's not clear what you're getting out of using the RPCManager here - code for direct use of XMLHttpRequest might be comparable in length, since you've got a lot of settings here to switch from the typical RPCRequest use case to this more "raw" usage.

        That said, we don't have any plans to rename the undocumented xmlHttpRequestResponseType setting, if you prefer to continue as you are.


          Sounds good. Thank you!