Vizlib Home Try Vizlib
Welcome
Login
Submit a ticket
  1. Help Center
  2. Vizlib Community
  3. The latest releases and updates
  4. Vizlib Advanced Text Object v1.6.3 released!

Vizlib Advanced Text Object v1.6.3 released!

David
started a topic about 4 years ago



1. [VSP-303]: Image library doesn't take virtual proxy into account

When the background image was using the content library selector it wasn't taking into account the virtual proxy where the app was being opened with, making the image not to render.


2. [VZB-793]: Actions not executed as expected when navigation to another sheet was used

Due to the synchronously order of the actions some of them were not executed due to the defined order.


3. [VSP-227]: Tooltip doesn't disappear in VATO until you refresh the browser

In some situations the tooltip was getting stuck into the page.


4. [VZB-768]: Tooltip sometimes is displayed twice

In some scenarios tooltip was appearing twice on the same object.


5. [VSP-244]: Vizlib Action - data not saved after user-triggered reload

The data was not saved after the reload action.


 Vizlib Advanced Text Object Documentation  

  • S
    Sashin Patel
    said about 4 years ago

    We have found a possible bug in this release. Our solution has been live for ~8 months using the "Advanced Text Object" with no problems, until this issue began on Monday evening, following this v1.6.3 release.


    Issue Details

    • We are using the "Advanced Text Object" in a mashup with React
    • Due to our React folder structure, the web file is not located directly in the /extensions/<<EXTENSION NAME>> sub-directory
    • A websocket call to the "app" method fails with a 404 error
    • The "Advanced Text Object" attempts to use the websocket URL below:
      wss://<<HOSTNAME>>/<<EXTENSION NAME>>/app
      This returns the 404 error

      The correct websocket URL would be:
      wss://<<HOSTNAME>>/app

    • If we create a mashup not using React (i.e. with the usual folder structure using the basic mashup template) the websocket URL is correct and we do not receive a 404 error

    We would take an educated guess that the logic which creates the websocket URL is assuming a default folder structure for the extension and no longer supports a custom folder structure.

    Any support would be very much appreciated.

    Thanks,
    Sashin

Login to post a comment
Topics in this forum
View all

Didn't find what you were looking for?

Start a new topic