#204588 - 2012-03-27 01:25 AM
SetDefaultPrinter bug
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
I have come across an issue which I assume must be a bug in the setdefaultprinter function. This issue occurs irrespective of whether Win XP or Win 7 is used and also occurs whether I use Kixtart 4.50 or version 4.62 (the latest version). Some of my client use a program called revelation natural art (they are schools) and when I use the setdefaultprinter option in the script, the script sets the default printer to whatever I specifiy in the script, but the program cannot print because it says there is no printer installed. However, if I manually set the default printer, as in right click printer and then setdefault printer, the program is then able to print. I then used a VBS script
Set net = WScript.CreateObject("wscript.network") net.SetDefaultPrinter "\\server\ict colour"
which I called from the kixtart script and the program works perfectly using the VBS script! It doesn't worry me a great deal as the VBS script works perfectly, but I thought that I would mention that the Kixtart function is not 100% right, as its obviously not setting something that the VBS script does. So if anyone else has ever had the issue where a program says that it cannot print, because there are no printers installed, despite the fact that printers are installed, this may be why!
Thank you
|
Top
|
|
|
|
#204590 - 2012-03-27 02:25 AM
Re: SetDefaultPrinter bug
[Re: Allen]
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
Hi Allen,
Thanks for your quick response. The setdefaultprinter function does work. I am not stating that it doesn't. But its not doing something that it should be. I am using the printer name. I am also using the same name for the share name and the printer name in order to avoid any problems with this - I discovered that years ago when I started with Kixtart. To give you an example of my script where its not working with this specific program
If AddPrinterConnection ("\\server\IT colour") = 0
? "Added IT Suite printer "
Endif
If SetDefaultPrinter ("\\server\IT colour") = 0
? "Set default printer to IT Suite Printer"
Endif
This installs the printer and sets the printer as default. All the programs see the printer as the default printer - thus it works - BUT the abovementioned program does not work unless I set the default printer MANUALLY or I use the VBS script to set the default printer. Hence the problem is something about the way the SetDefaultPrinter function works as in it is missing a step somewhere.
Thank you.
Edited by Allen (2012-03-27 02:58 AM) Edit Reason: added code tags
|
Top
|
|
|
|
#204592 - 2012-03-27 09:42 AM
Re: SetDefaultPrinter bug
[Re: Lonkero]
|
Arend_
MM club member
Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
|
In the mean time you can use the VBS code converted to kix:
Dim $net
$net = CreateObject("wscript.network")
$net.SetDefaultPrinter("\\server\ict colour")
|
Top
|
|
|
|
#204595 - 2012-03-27 02:58 PM
Re: SetDefaultPrinter bug
[Re: Robdutoit]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4545
Loc: USA
|
I think you missed the point with Arend's post. If your script is kix, why use vbscript, when it can be easily converted to kix code.
I think at this point it is likely you have found a very obscure bug. Maybe you can run a process monitor and capture what is looking for when your program runs and you ask it to print.
http://technet.microsoft.com/en-us/sysinternals/bb896645
|
Top
|
|
|
|
#204598 - 2012-03-27 10:12 PM
Re: SetDefaultPrinter bug
[Re: Allen]
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
Thats a very good idea ! I will be with that client on Thursday, so I will run process monitor and see what gives. What I will also do is run process monitor and see what happens when I use the VBS script as opposed to the kixtart function. Having said that, the coding used by Arend and myself obviously works correctly, so perhaps kixtart should deprecate the setdefaultprinter function in favour of the coding as proposed by Arend. I will update you on Thursday evening with my results. Thanks
|
Top
|
|
|
|
#204599 - 2012-03-28 04:00 AM
Re: SetDefaultPrinter bug
[Re: Robdutoit]
|
Lonkero
KiX Master Guru
Registered: 2001-06-05
Posts: 22346
Loc: OK
|
sorry, but I must disagree that my comment wouldn't apply. the program says there is no printer installed when there is, which means, it's the software that doesn't work.
so, it has nothing to do with kixtart adding a printer. it has everything to do with kixtart not making the default printer in a manner that software expects. some really old programs, all they knew was if there was a printer attached to parallel port. now, this software might be one of those "dump" ones. if so, testing it is the easiest thing to do. after having your kixtart script add and set the printer as default, just open command prompt and do the net use line I gave earlier. if this "fixes" the software, you know where the problem lies. and if this fixes the issue, it is not a kixtart issue. kixtart uses internal windows calls to make a printer default.
now, totally another question is, if there is a new method in windows of setting the default printer, should kixtart be updated to use that instead at the same time dropping support for older OS'es.
_________________________
!download KiXnet
|
Top
|
|
|
|
#204612 - 2012-03-30 11:51 PM
Re: SetDefaultPrinter bug
[Re: Robdutoit]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4545
Loc: USA
|
Regshot might be a better tool for the job. http://sourceforge.net/projects/regshot/
If I have time this weekend, I might take a peek myself.
|
Top
|
|
|
|
#204614 - 2012-03-31 08:05 AM
Re: SetDefaultPrinter bug
[Re: ShaneEP]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4545
Loc: USA
|
I agree Shane... not much there. It changes "HKEY_USERS\"+@sid+"\Software\Microsoft\Windows NT\CurrentVersion\Windows","Device", and aside from capitalization looks exactly the same with kix or using the GUI for me. Based on Jochen's UDF GetDefaultPrinter ( http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=118766 ), this is the correct location to check this.
So maybe the process monitor on the specific program while attempting to print is the right direction?
|
Top
|
|
|
|
#204711 - 2012-04-12 09:33 AM
Re: SetDefaultPrinter bug
[Re: NTDOC]
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
Just to keep you updated on whats going on. As its been Easter, I have not been back to the client. I will check the win.ini file as that is a likely starter. I will test all the scenarios that Allen and NTDOC has suggested, but I already know the AV is not the fault, as this has occurred at two different clients and they both have different anti virus solutions. I have tried on different computers both xp and win 7, so the profile is not likely to be the problem. But I will look at each everything, because I suspect its something about the way the domain is setup at the clients because I noticed a very interesting thing when I was testing the setdefault function at home (without the affected software). At home, if I run the setdefault function it changes the default printer and changes the tick to the new default printer. At the clients, it changes the default printer, but it ONLY changes the tick to the correct printer in the devices and printer page, if I REFRESH - ha there is a new clue ! I will be in at the client next week Thursday. Thanks
|
Top
|
|
|
|
#204768 - 2012-04-19 05:17 PM
Re: SetDefaultPrinter bug
[Re: Robdutoit]
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
Hooray, I have found the cause of the problem!
If you type
SetDefaultPrinter ("\\server\ICT Colour") = 0
the program works perfectly, but if you type
SetDefaultPrinter ("\\Server\ICT Colour") = 0
Then it fails.
it also fails if I use something like this
$ServerName = @LServer SetDefaultPrinter ($ServerName + "\ICT Colour") = 0
The program says there is no printer installed even though all the printers are installed and the correct printer is set as default.
In case you missed it, the name of the server in this example is server (in lowercase), but if you type Server (uppercase S), thats when the program fails to find the printer. In the case of this specific client, the name of the server is in lower case, but in the script it started with uppercase. It also fails when you use the @Lserver macro so for me setdefaultprinter is unworkable as I use the same script for all my clients and they all have different server names, which is why I use the @LServer macro which obviously is returning the server name in uppercase I presume.
Interesting thing though, is the program works perfectly if you use the VBS script mentioned above in earlier posts and it makes no difference whether you use lower or upper case in the VBS script.
I don't know if this qualifies as a bug with this specific program or whether its a bug with setdefault printer, but I would say as it works in both lower and uppper case in the vbs script, that the bug lies with setdefaultprinter function.
Ignore the comment I made in my post on the 12th april. The refresh and movement of the tick issue is a windows xp issue. It works perfectly on Windows 7, but with XP you either have to refresh the window or close the printer windows and re-open. As such, that is not relevant to the issue being discussed here.
Thanks to everyone for all the input, my preferred solution now that I have worked out what the problem is, would be to take the vbs script and incorporate it into my kixtart scripts as Arend suggested. So I now consider setdefaultprinter to be obsolete as the VBS scripts work regardless of the case sensitivity. Many thanks to all.
|
Top
|
|
|
|
Moderator: ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 248 anonymous users online.
|
|
|