Developers ›  Knowledge Bank ›  Articles ›  Updates-May2024

May 2024 updates to ScriptX Client Library

The MeadCo ScriptX Client Library has had some significant updates.

With v1.15 significant changes have been introduced to the MeadCo ScriptX Client Library. Whilst significant the updated library is compatible with previous versions of the library so the version sees only an uptick to v1.15.

Summary of changes

  • The library is now independent of jQuery. This means that the library can be used in environments where jQuery is not available or is not desired.
  • Option to force no use of jQuery.
  • A 'paranoid' connection mode option in which connections arbitrated by Orchestrator are validated on every call.
  • New functions for observing the state of the job queue.

Details of changes

Independence from jQuery

The library has been restructured to remove the dependency on jQuery. This means that the library can be used in environments where jQuery is not available or is not desired.

If jQuery is not available the library now uses the fetch() API for making network requests. This is a modern API that is available in all modern browsers. Also, browser native APIs are used for management of and retrieval of document content for printing.

However, note that the fetch() API only supports asynchronous calls. This may have consequences for old code which assumed synchronous behaviour. Synchronous behaviour is deprecated in browsers so it is strongly recommended that code is migrated away from synchronous calls. There are asynchronous alternatives for all synchronous functions. The MeadCoScriptXJS Library provides useful wrapper function that return a Promise() which enables simpler asynchronous coding and supports use of async in code.

UI

An additional code module provides a simple UI for the library. This is a simple UI that can be used to display dialogs for Print setup and Page setup.

There is now an additional implementation that does not depend on jQuery but does depend upon Bootstrap 5 (which also does not depend on jQuery). See the Dialogs with ScriptX.Services article for more detail on this.

Option to force no use of jQuery

If you are using an old version of jQuery that does not work with this library (versions of jQuery earlier than 1.19) but the old version is required by your code you can disable the use of jQuery by this library in one of three ways (requiring the use of 'fetch' is a proxy for 'do not use any jQuery'):

  1. Include this code before referencing the library:

            
        <script type="text/javascript">
           var MeadCo = {
               useFetch: true;
           };
        </script>

    or,

  2. Set the fetchEnabled property to true in the MeadCo object before any calls are made to functions in the library. For example: 

            
        <script src="https://cdn.jsdelivr.net/npm/meadco-scriptxjs@1/src/meadco-scriptx.min.js"></script>
        <script src="https://cdn.jsdelivr.net/npm/scriptxprint-html@1/dist/meadco-scriptxservices.min.js"></script>
        <script type="text/javascript">
            MeadCo.fetchEnabled = true;
            MeadCo.ScriptX.Print.Licensing.connectLite(servicesUrl, "{XXXXXX-LICENSE-GUID}",1, "warehouse");

            window.attachEventListener("load",async () => {
                await MeadCo.ScriptX.InitAsync();

                ...
            }
        </script>

    or,

  3. When using attributes for initialisation, use the new data-meadco-usefetch attribute: 

            
        <script src="https://cdn.jsdelivr.net/npm/meadco-scriptxjs@1/src/meadco-scriptx.min.js"></script>
        <script src="https://cdn.jsdelivr.net/npm/scriptxprint-html@1/dist/meadco-scriptxservices.min.js"
            data-meadco-server="http://127.0.0.1:41191" 
            data-meadco-orchestrator="41190"
            data-meadco-license="8f351de0-5990-45c3-8fd2-8037b878939f"
            data-meadco-license-path="warehouse"
            data-meadco-license-revision="0"
            data-meadco-usefetch="true">
        </script>
        <script type="text/javascript">
            window.attachEventListener("load",async () => {
                await MeadCo.ScriptX.InitAsync();

                ...
            }
        </script>
Paranoid connection mode

Only applies to ScriptX.Services for Windows PC with Orchestrator.

This mode is only useful if it is possible for multiple users to be signed in to the PC concurrently. If this possible then you must configure ScriptX.Services for Windows PC to ensure that each user uses a port that is unique to them.

This can be achieved with custom configuration - configure each users port in their configuration of ScriptX.Services for Windows PC and use that port in the html delivered to the user.

Much easier is to use Orchestrator.

When Orchestrator is used to determine the port number this occurs on the first call made to ScriptX.Services for Windows PC in the lifetime of the page. The result is cached and used for the life of the page in the browser.

In a multi-user sign-in environment, there's a possibility that if the Orchestrator fails and the ScriptX.Services for Windows PC also fails for user "J", and another user "E" logs in, user "J" might end up using the instance of ScriptX.Services for Windows PC intended for user "E". This could result in printing tasks being performed on the wrong printer. This scenario could only occur if user "J" has not refreshed the page (for instance, by navigating away and then returning) as upon page reload, the Orchestrator will be invoked again, which would either result in an error or the correct port assignment.

The library now supports a 'paranoid' connection mode. In this mode, connections arbitrated by Orchestrator are validated on every network call. This is a useful mode for ensuring that the connection is always valid.

Note that use of this mode will slow down the operation of network calls.

Please note the cascading failures and conditions for this issue to arise. Note that the likelyhood of failure is reduced depending on work-flow. For example, if a user loads a page for printing and then closes it and returns to a 'main page' of the application then they are more likely to encounter a reported failure as the print page loads and is unable to locate the ScriptX.Services for Windows PC server.

It is recommended to asses the performance impact of this mode against the possibility of incorrect output and the consequences of that.

Usage

When using attributes for initialisation, use the new data-meadco-trust-verified-connection attribute: 


        <script src="https://cdn.jsdelivr.net/npm/meadco-scriptxjs@1/src/meadco-scriptx.min.js"></script>
        <script src="https://cdn.jsdelivr.net/npm/scriptxprint-html@1/dist/meadco-scriptxservices.min.js"
            data-meadco-server="http://127.0.0.1:41191" 
            data-meadco-orchestrator="41190"
            data-meadco-license="8f351de0-5990-45c3-8fd2-8037b878939f"
            data-meadco-license-path="warehouse"
            data-meadco-license-revision="0"
            data-meadco-usefetch="true"
            data-meadco-trust-verified-connection="false">
        </script>
        <script type="text/javascript">
            window.attachEventListener("load",async () => {
                await MeadCo.ScriptX.InitAsync();

                ...
            }
        </script>
Observing the state of the job queue

With ScriptX.Services there are two job queues:

  1. The queue of jobs on the client that are waiting to be delivered to the ScriptX.Services server.

  2. The queue of jobs delivered to the server that are waiting to be printed.

The reason for two queues rather than just the queue at the server is that a loop of Ajax calls at the client does not guarantee that the calls will be received at the server in the same order. To resolve this a queue is maintained on the client from the which the Ajax calls are dispatched with a time delay between each.

The library provides functions to observe the state of these queues. These functions are:

Property Description
activeJobs Returns the number of jobs in the queue at the server.
clientSideJobs Returns the number of jobs in the queue at the client and waiting for delivery to the server.
noJobsWaitingDelivery returns true if no jobs are waiting for delivery to the server.

These functions can be used to provide feedback to the user on the state of the print queue.

If the client tab/window is closed before the jobs are delivered to the server then the jobs will be lost.

Two functions are provided that simplify ensuring that processing is complete before alowing other actions:

Function Description

waitForSpoolingComplete(iTimeout, fnComplete)

Starts a (asynchronous) monitor to observe until no more jobs spooling/waiting at the server then calls the given callback function.

The MeadCoScriptXJS Library provides a wrapper on this function with a promise.
waitForDeliveryComplete(iTimeout, fnComplete)

Start (asynchronous) monitor to observe until all submitted jobs have been delivered to the server, there will probably be jobs still waiting to process/spool at the server. It is not safe to close the browser window until this function indicates completion
waitForDeliveryCompleteAsync(iTimeout)

Returns a promise that is resolved when all pending operations originated with Print, PrintHTML and BatchPrintPDF have been delivered to the server. This is useful to determine when it is safe to call window.close() and not loose jobs and is a significantly shorter period than waitForSpoolingComplete().

            
            <script type="text/javascript">
                ...

                MeadCo.ScriptX.PrintPage(false);
                await MeadCo.ScriptX.Print.waitForDeliveryCompleteAsync();
                self.close();

            </script>
 

Warning:

This ScriptX.Add-on sample can only be viewed using Internet Explorer.