(Hey THIS is FUN)

2012-03-27 01:25 AM

SetDefaultPrinter bug

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

Administrator

(KiX Supporter)

2012-03-27 01:29 AM

Re: SetDefaultPrinter bug

Please post your code or an example of your code.

Keep in mind SetDefaultPrinter uses the printer name, not printer share. It is suggested that you use the same name for the printer and the share to avoid this problem.

(Hey THIS is FUN)

2012-03-27 02:25 AM

Re: SetDefaultPrinter bug

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

Code:

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.

Administrator

(KiX Master Guru)

2012-03-27 03:23 AM

Re: SetDefaultPrinter bug

wonder...
it must not be, but was thinking. back in the day for old programs we needed to do "net use lpt1: \\server\share"

not sure if this really old hack would be needed these days, but if the program says there is no printer installed, when there clearly is, you might be dealing with a dinosaur program that requires something like that.

(MM club member)

2012-03-27 09:42 AM

Re: SetDefaultPrinter bug

In the mean time you can use the VBS code converted to kix:

Code:

Dim $net
$net = CreateObject("wscript.network")
$net.SetDefaultPrinter("\\server\ict colour")

(Hey THIS is FUN)

2012-03-27 01:58 PM

Re: SetDefaultPrinter bug

To Lonkero, your suggestion is not applicable, because the program is happy with the installation of the printer in kixtart. The problem only crops up when I use Kixtart to set the default printer.
To Arend, I am already using a vbs script almost identical to the one you have written up there. so I have got my script to work. The point of my post is to highlight the fact that there is an issue or bug with the setdefaultprinter function. I do agree with Lonkero, that the program is an older style program so probably uses a legacy based way of determining which printer is the default. But as it works when I manually set the default printer, to me it means that the kixtart function is not accurately replicating the result that should occur.
Thanks

Administrator

(KiX Supporter)

2012-03-27 02:58 PM

Re: SetDefaultPrinter bug

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

(Hey THIS is FUN)

2012-03-27 10:12 PM

Re: SetDefaultPrinter bug

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 $\:\)$

Administrator

(KiX Master Guru)

2012-03-28 04:00 AM

Re: SetDefaultPrinter bug

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.

(Hey THIS is FUN)

2012-03-30 10:02 PM

Re: SetDefaultPrinter bug

I have done the following:
I used the "net use lpt1: \\server\share" method as suggested by Lonkero and this has no effect on the problem. Obviously the program does not use the parallel port scenario.
I attemped to use the process monitor, but I couldn't work out what to filter, and I ran out of time to look at it. I will look into the matter when I have more time, but what I will do longterm is use the converted vbs coding as suggested by Arend as this works flawlessly. But I will attempt to find the cause of the issue and post the solution. Many thanks for all the advice so far.

Administrator

(KiX Supporter)

2012-03-30 11:51 PM

Re: SetDefaultPrinter bug

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.

(MM club member)

2012-03-31 01:55 AM

Re: SetDefaultPrinter bug

I tried regshot (was my first thought as well) quickly yesterday with no luck. But I wasn't extremely thorough. Maybe you'll have better luck.

Administrator

(KiX Supporter)

2012-03-31 08:05 AM

Re: SetDefaultPrinter bug

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?

(Hey THIS is FUN)

2012-03-31 12:05 PM

Re: SetDefaultPrinter bug

Allen, I tried using registry monitor programs, but I am not seeing different there. Whatever the difference is about the function setdefaultprinter, its not in the registry. That much I can confirm.
I cannot use the process monitor to see whats happening when I attempt to print from that program after using setdefaultprinter because the print command and button is greyed out. Never fear, I will research the issue and see if I can track down what causes it.

Administrator

(KiX Supporter)

2012-03-31 03:58 PM

Re: SetDefaultPrinter bug

I've done a bit of googling on this.

What happens if you hit Ctrl-P while in the program?

Maybe your AV is to blame... see this article.
http://www.wordbanter.com/showthread.php?t=42716

A couple of articles mention bad/corrupted profiles. Here's one with QBs.
http://community.intuit.com/posts/quickbooks-will-not-recognize-my-default-printer

A number of articles mention completely removing the printer and the drivers and reinstalling them as a fix.

Administrator

(KiX Master Guru)

2012-04-05 09:36 PM

Re: SetDefaultPrinter bug

still, after 10 years I found articles of also checking the win.ini $\:\)$

Administrator

(KiX Master)

2012-04-05 11:37 PM

Re: SetDefaultPrinter bug

This can clear out all printers and settings and possibly correct other errors.

http://windows.microsoft.com/en-us/windows/help/printer-problems-in-windows

(Hey THIS is FUN)

2012-04-12 09:33 AM

Re: SetDefaultPrinter bug

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

(Hey THIS is FUN)

2012-04-19 05:17 PM

Re: SetDefaultPrinter bug

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.

(KiX Master)

2012-04-19 05:41 PM

Re: SetDefaultPrinter bug

The syntax in your examples are wrong. You cannot apply the value 0 to the function, you can only test the return value with an IF or some other construct.

Administrator

(KiX Supporter)

2012-04-19 05:51 PM

Re: SetDefaultPrinter bug

Well... sad to say, I had the gold in my hand, and didn't know it... $\:\($

Quote:

and aside from capitalization looks exactly the same with kix or using the GUI for me

Les, I think what he has works because Kix is so forgiving, but you are right, that does need to be in an if or at the very least done like this: $RC=addprinterconnection("\\Server\Share")

(MM club member)

2012-04-19 07:41 PM

Re: SetDefaultPrinter bug

Does this work?

Code:

$ServerName = LCase(@LServer)
SetDefaultPrinter ($ServerName + "\ICT Colour"

Administrator

(KiX Master Guru)

2012-04-19 08:59 PM

Re: SetDefaultPrinter bug

well well...

is the addprinterconnection also with lower case?
does it work if you use @lserver with addprinterconnection AND setdefaultprinter?

I think what is going on in here is that the program cares about case even though windows doesn't.
windows still stores the case in the default printer info and thus, if the case for the added printer and default printer are different, the program gets confused.

continuing on this logic, vbscript then only works as long as the printer is also added lowercase. if you add it with kix and have capitals in it, then it should fail. or, as Shane suggested, using only lowercase default printer.
if the printername (and the servername) contain uppercase characters in both places:
a) HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Devices
b) HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows,Device-value

and the program still doesn't work right, then the program only accepts lowercase servername, which is odd and shall be an issue with the program itself.
if it works, then it's just matter of the program caring too much in windows standards but I might not call it a bug in that cause. maybe a odd feature instead.

(Hey THIS is FUN)

2012-04-19 11:31 PM

Re: SetDefaultPrinter bug

Sorry, I did not copy the coding across correctly, I meant to delete the = 0 part of the coding. Yes, you are quite right that I should have the if endif scenario. But that does not affect the outcome here. Whether the if is used or not, the setdefaultprinter only works if I put in the correct case of the name of the server. But thanks for pointing that out Les

Oh Allen, the irony - yes you had the gold in your hands. I hate it when that happens to me, when its been in front of my eyes all along and I missed it. Been there many times.

To ShaneEp, your suggestion would only work if all the servers names were in lower case, which they may not be. The more relevant question is why the case sensitivity is an issue for setdefaultprinter when its not an issue for the vbs coding. The vbs coding does not care about the case sensitivity.

To Lonkero, the issue may only affect this specific program, in which case its not a major issue. But I can put in Server (CAPS) in the vbs code and it works. It only fails with setdefaultprinter macro. I have just checked the coding and at this specific client the addprinter is set using server not Server. So you may have something there, but your explanation does not explain why the VBS code does not care about the case sensitivity. I brought the CD of the program home with me. I will test out whether the setdefaultprinter function working properly depends on the case of the server name or on the case of the addprinter function and get back to you. But this below works

Set net = WScript.CreateObject("wscript.network")
net.SetDefaultPrinter "\\Server\ict colour"

I have no answer for why the capital S works in the vbs script, but it doesn't work in setdefaultprinter.

Worst thing about coding has always been the damn punctuation lol ! Gets me every time.

Administrator

(KiX Master Guru)

2012-04-19 11:37 PM

Re: SetDefaultPrinter bug

did you check the registry values?
if you input the "Server" in the vbs and go and see the registry and it's there in lower case, well, there is the answer.
vbs either lowercases it always, or checks the printer that is mapped and uses that case.

Administrator

(KiX Supporter)

2012-04-20 03:16 AM

Re: SetDefaultPrinter bug

This is interesting...

Code:

setdefaultprinter(lcase("\\Server\Brother HL-2270DW series"))

sets the registry to an all lowercase printer, and you have to refresh/F5 to see the default printer change in GUI.

Code:

Dim $net
$net = CreateObject("wscript.network")
$net.SetDefaultPrinter(lcase("\\Server\Brother HL-2270DW series"))

sets the registry ignoring the lower case function and sets it to match the name in the GUI. The GUI automatically switches the default without having to refresh/F5.

Administrator

(KiX Master Guru)

2012-04-20 04:53 AM

Re: SetDefaultPrinter bug

oh, so vbs actually has a logic in there.
now, the question is, in windows world, what does it matter what case it is?
I almost want see what kinda code Ruud runs in the kix because I bet he has no case preserving logic in there.

I did find other programs that require case to be correct, like ICA or access.
but, the reason the case mattered was always something funky.

I found lot of comments that printernames are case-sensitive but, nothing from microsoft.

Ruud? some thoughts?

(Hey THIS is FUN)

2012-04-21 12:50 PM

Re: SetDefaultPrinter bug

I can confirm Allen's experiment. If I put in catc for name of printer in the vbs coding, the registry will show it as CatC which is what I named the printer in this test. Thats why the VBS works, because it changes the case to whatever the actual case of the printer is.

To Lonkero, testing on my computer reveals that the program doesn't care whether the name is upper or lower case, it is only interested in matching the case identically. so if the printer name is CatC, then thats what I need to put in the setdefaultprint coding. so its not just the name of the server - in my clients case, the name of the printer just happened to be in the correct case by co-incidence, it was the server name that was in the wrong case.

With regards to whether setdefaultprinter should be modified to take this issue into account, I must leave to yourselves to decide. If I am the only person in over a decade that has an issue with setdefaultprinter, then I do not see the value in modifying the setdefaultprinter function.

I am quite happy to use the vbs coding so that I don't have to worry about case sensitivity. I did mention in an earlier post that Kixtart could consider deprecating setdefaultprinter in favour of the vbs coding. But thats up to you. Now if I could find the cause of my having to login twice every single time onto the Kixtart forum, I will be chuffed.

thanks for all the input. We got there eventually lol

Administrator

(KiX Master Guru)

2012-04-21 02:07 PM

Re: SetDefaultPrinter bug

well, nothing vbs can supersede something kix.

anyways, it doesn't take Ruud much effort to change the logic and I think he should do it. it won't break any fucntionality just improves it.

and thanks to Allen for checking the registry confirming where the problem actually lies.

(Hey THIS is FUN)

2012-04-21 07:18 PM

Re: SetDefaultPrinter bug

When I say VBS, I am actually referring to the coding that was converted from VBS into Kixtart to be accurate. My concern is that its not necessary to create work (ie update setdefaultprinter) because one person in a decade had a problem with it. But if it only takes 5 minutes or so, then it might be a worthwhile update. Cheers Rob

Ruud van Velsen

(Hey THIS is FUN)

2012-09-10 08:11 PM

Re: SetDefaultPrinter bug

Well, I don't have the software mentioned, so I can't check with that, but I do see that there's a difference between the result of setting the default printer with VBS or KIX.

And I'll investigate that to see if I can align Kix with what Vbs (or actually: WScript) does.

Thanks for the report!

Ruud

Ruud van Velsen

(Hey THIS is FUN)

2012-09-11 05:22 PM

Re: SetDefaultPrinter bug

Actually, I did some more research and found that KiXtart produces the exact same result as manually setting the default printer does. VBS/WSH for some reason produces a different result.

So, I expect the issue reported at the start of this thread also occurs if the printer is set manually.

As such, I will leave things as is in KiXtart.

Kind regards,

Ruud

Administrator

(KiX Supporter)

2012-09-11 11:13 PM

Re: SetDefaultPrinter bug

Maybe I don't understand what you are seeing.

If you set the printer as default through the GUI, the registry setting will match the case. If you use Kix and do not match the case exactly as the gui, it will cause the issue that the poster was having. In other words, kix sets the registry setting to match what you type in the script, not what is in the GUI.

Wscript somehow knows that if you do not match the case of the gui, it will transform it in the registry to match.

Does that help?

Ruud van Velsen

(Hey THIS is FUN)

2012-09-12 12:16 PM

Re: SetDefaultPrinter bug

Ah.... now I understand... Apparently the application is case sensitive as far as the default printer name is concerned.

Ok, that's an easy thing to fix, this will be in the next 4.63 build.

Thanks for explaining the issue!!

Ruud

(Hey THIS is FUN)

2012-09-15 01:25 PM

Re: SetDefaultPrinter bug

To Ruud, Just so that you know, I have gone down the route of using

Code:

Dim $net
$net = CreateObject("wscript.network")
$net.SetDefaultPrinter($ServerName + "\" + $printsetup) 
etc etc etc

so I am not too fussed about the setdefaultprinter bug as only affects one old program, which is only used by one or two of my clients. However, having said that, as the function is not matching what happens when you manually set the printer - i.e. the correct case is entered into the registry, it probably makes sense to fix it so it does exactly what the manual setting does.
Thanks Rob