PDF Printer in VM displays GUI on Host !
Posted: Mon Oct 24, 2011 1:19 pm
I'm seeing some very odd behaviour with BullZip PDF Printer.
It's so odd it's actually something I didn't think was even possible, and I can't see how it would be desirable.
I'm running PDF Printer in a Virtual Machine and it is showing the Settings GUI on the Host !
I don't want that to happen, and I'm surprised it is even possible.
What I am actually doing is running PDF Printer from a script which is in turn run from Kinook Visual Build.
My Visual Build script is writing to PDF Printer's settings.ini to :
1. turn off view after print.
2. set the location of the output file.
3. request that no settings dialog be shown.
Then Vis Build calls the VB script to run PDF Printer.
PDF Printer then seems not to read the settings.ini and puts up the dialog anyway. And it does so on the Host ! Which, as I said at the top, is something I don't want, and am surprised is even possible. Certainly it ought not to be the default behaviour - actions in a VM should stay there, shouldn't they ? Unless clearly using the Integration Tools to interact with the host. And I wouldn't have thought that would be appropriate in this case.
The Host is running Windows 7. The VM system is Microsoft Virtual PC. The Guest OS is Windows XP SP3.
I am aware that I can do all the selection of settings from the VB script that calls PDF Printer, but at the moment this is an old script that doesn't do so.
I'd appreciate advice on how to stop it interacting with the Host, or acknowledgement that it is a bug, or explanation of why it is considered correct.
Regards,
Richard.
It's so odd it's actually something I didn't think was even possible, and I can't see how it would be desirable.
I'm running PDF Printer in a Virtual Machine and it is showing the Settings GUI on the Host !
I don't want that to happen, and I'm surprised it is even possible.
What I am actually doing is running PDF Printer from a script which is in turn run from Kinook Visual Build.
My Visual Build script is writing to PDF Printer's settings.ini to :
1. turn off view after print.
2. set the location of the output file.
3. request that no settings dialog be shown.
Then Vis Build calls the VB script to run PDF Printer.
PDF Printer then seems not to read the settings.ini and puts up the dialog anyway. And it does so on the Host ! Which, as I said at the top, is something I don't want, and am surprised is even possible. Certainly it ought not to be the default behaviour - actions in a VM should stay there, shouldn't they ? Unless clearly using the Integration Tools to interact with the host. And I wouldn't have thought that would be appropriate in this case.
The Host is running Windows 7. The VM system is Microsoft Virtual PC. The Guest OS is Windows XP SP3.
I am aware that I can do all the selection of settings from the VB script that calls PDF Printer, but at the moment this is an old script that doesn't do so.
I'd appreciate advice on how to stop it interacting with the Host, or acknowledgement that it is a bug, or explanation of why it is considered correct.
Regards,
Richard.