setPrinter(index) not syncronous

[tresf]

@robertcasto @bberenz we seem to have another bug where qz.setPrinter(index) followed by qz.getPrinter(); results in the printer being undefined.

The old behavior was to use the qz.setPrinter(index) as a synchronous replacement to the qz.findPrinter() call.

-Tres

[akberenz]

It is not possible to make that call synchronous with getPrinter. While the call currently isn't being handled by the socket, setting it up to correctly change the result of getPrinter will not return fast enough for a call on the next line to return properly.

[daveland2]

My question is what is the proper protocol for making getPrinter return a meaningful value after making a call to setPrinter(i)?

My first attempt to work with this assumed a synchronous behavior:

qz.setPrinter(i);
console.log("qz.getPrinter: " + qz.getPrinter());

My second attempt tried an asynchronous approach:

qz.setPrinter(i, function()
{
    console.log("qz.getPrinter: " + qz.getPrinter());  //%//
});

Both approaches returned the null value for getPrinter.

(I was just guessing how to do the asynchronous approach, since I could not find any documentation on how to properly handle this situation. The anonymous callback function did get invoked, but getPrinter() returned null.)

The remark "the call currently isn't being handled by the socket" suggests that some work needs to be done on the QZ Print side of this situation. Is this correct? (The effect of calling qz.setPrinter(i) seems to do the right thing in my program. It is just that I cannot do a validity check to verify that a printer has been selected.)

Can we expect something to be done that will enable one to work with setPrinter(i) and getPrinter() together, or do I need to pursue alternatives?

Dave Eland

[tresf]

@daveland2, I'm responding in many areas for consistency... but I wanted to update this bug report.

For now, I'd recommend you change your code to assume that oncesetPrinter() has been called on a valid index, the printer is set. This means you will need to stop relying on the immediate readiness of getPrinter(). The reason for this is that our new websockets approach is intentionally asynchronous, so any function that is considered "syncronous" is technically not. This is not a problem using a FIFO approach for appending, but it will cause issues when trying to immediately set/get. This happens to be the first scenario we've run into.

Ideally, we could add a new callback qzDoneSetting but we will likely hold off on this for now, as adding new callbacks now is a bad idea until after we rewrite the core of the qz-print code this summer.

[daveland2]

Tres:

Thanks for your response.

I appreciate all the attention you have given to this issue.

Reworking my approach for reliably setting the printer to work with is not a deal-breaker, so I will make the necessary adjustments in my code in the light of what we have learned from this issue.

Dave

On Sat, Jun 13, 2015 at 3:02 PM, Tres Finocchiaro notifications@github.com wrote:

@daveland2 https://github.com/daveland2, I'm responding in many areas for consistency... but I wanted to update this bug report.

For now, I'd recommend you change your code to assume that once setPrinter() has been called on a valid index, the printer is set. This means you will need to stop relying on the immediate readiness of getPrinter(). The reason for this is that our new websockets approach is intentionally asynchronous, so any function that is considered "syncronous" is technically not. This is not a problem using a FIFO approach for appending, but it will cause issues when trying to immediately set/get. This happens to be the first scenario we've run into.

Ideally, we could add a new callback "qzDoneSetting" but we will likely hold off on this for now, as adding new callbacks now is a bad idea until after we rewrite the core of the qz-print code this summer.

— Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/45#issuecomment-111743812.

[tresf]

Closing as wontfix. Thanks for the report Dave.