Conditional Printing Fails With 10.1 Sr3
Further developments:
Our design with many data sources and VBscripts has been stripped down to the level that no SQL databases are used. The issue occurs when using a user input screen in combination with the OnPostPrompt event control.
If you open it in 10.1 SR1, and preview it, you will see a user input screen with no specific info. If you then click on preview you will see the Template 2 on screen
If you open the design in 10.1 SR2 and preview it, you will see the same user input screen. If you then click on preview, nothing can been previewed.
In SR3 the behaviour is the same as in SR2
What should happen:
On post prompt, the labcode is set to the value "AB000000" by VBscipt. Also on post prompt, the ID12 takes the first two characters of labcode, i.e. "AB". Based on this ID12 the conditionally printing template should print.
In SR1 it does, in SR2 and SR3 it doesn't.
File is attached in this thread.
Cheers,
Alex
-
Alex,
I've just tested this with 10.1 SR3 and "Template 2" is correctly being previewed for me.
Does someone else sees the same issue as Alex?
0 -
I'm getting the behavior that Alex describes, perhaps you can show me what you get on your PC Domingo?
0 -
Hi Ian,
Are there any developments upon this issue? I have tried a new design which was built in SR1 and in SR3 it seems that VB code is not executed when in preview mode. In SR1 it works fine.
My overall idea is that SR3 is considerably faster than SR1, but this could also be caused by not executing the VB script. For now we are stuck on SR1 but I would like to follow with the updates.
Alex
0 -
It seems to me that the way you are going about this is flawed by design because it relies on the order by which data sourced scripts are evaluated; something of which you have no control over. It just so happened that in SR1 it worked out for you, but in later releases, that fixed other issues, the ordering by which the scripts are executed changed to be not in your favour. To my mind, seeing as you're effectively choosing which template to print based on a value, you should be using a template selector instead.
The only way to keep the way you are doing things, and make sure that this will work in future releases, is to put all of your code into the one script so that you do have control over the execution order.
BTW: I tested this in a beta of SR4 and found that it functions the same as SR2 and SR3 in this respect.
0 -
Hi Ian,
Thanks for the idea! So far I had not thought about putting all in one script. This would indeed solve the problem as to in what sequence scripts currently are processed. I will redesign and see what happens.
Thank you for pointing in this way.
Cheers,
Alex
0 -
Update on the situation. All scripts on the designs have now been transferred to one script template, which is set never to print. It greatly reduced overhead within the scripts and the script sequence can now be controlled by us. It works great and since this morning our production environment has been updated to use SR3.
The only issue is the graphics which needed a little tilt as work around to print correctly. This work arounds is working well and our label designer knows this issue and uses this work around.
Thanks for the tip!
Alex
0 -
What's the problem with the graphics? Is the print quality less that you expect it to be? This could well be an issue that's fixed in the upcoming SR4, which should be out around the end of the month probably.
0 -
Hi Ian,
The graphic quality issue was answered by you directly to me by mail on April 21st, 2014. A one degree tilt was sufficient to bypass the issue.
SInce SR4 is out now, I will test it this week to see if the issue is resolved.
Cheers,
Alex
0
Please sign in to leave a comment.
Comments
8 comments