Re: [2003] Why can't app print?

Your application may be looking for the vb5fr.dll under the user's windows directory. (It could be looking in a subdirectory of windows, depends on the app) You can verify this using Filemon. If this is the case, you can set the compatibility flag for your app so that it will look under the "real" windows folder instead.

For example, if your application is named test.exe, and it is 32-bit, you would create the following key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\Test

And then you would create a REG_DWORD value named Flags under the above key you just created, with a value of 0x00000408:

See these documents for more information on the compat flags:

http://technet2.microsoft.com/WindowsServer/en/library/df78c476-00d5-41f0-a21d-e1e12e3d1f8b1033.mspx?mfr=true

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwts/html/AppCompSc.asp

Printers can have their permissions set so that only certain users/groups can print to them, however, there is no application-specific printer permissions.

There is an issue with your program and/or the combination of the specific printer driver and your program. I created a test app using VB6 (I don't have v5) and it printed fine under 2000 TS and 2003 TS, with multiple different printers.

As to why no error message, it could be that your program (or one of its components) is suppressing the error(s), or not checking for the faulty situation--not sure.

-TP

Vincent Delporte wrote:
On Sat, 28 Oct 2006 20:25:46 -0400, "TP"
<tperson.knowspamn@xxxxxxxxxxxxxxx> wrote:
Have you tried a simple test case? For example, create a
new project and put a button on it with the following code:

Yes, that's exactly what we tried on Friday... but the EXE wouldn't
even start, complaining that it couldn't find VB5FR.DLL, which is the
DLL that contains localized strings, although it was installed in
SYSTEM32 by our installer. As a second test, I used PEBundle to
combine the EXE and the DLL, but got the same error when running the
EXE.

Also, as Vera mentioned, normally you would have an
administrator install your application on the TS, so that
they would have access to register your COM objects,
and overwrite any of your program files with newer
versions.

That's what we did: The admin opened a TS sessions as administrator to
let me run our installed. Obviously, TS users run with much less
permissions, and I assume that's what the problem is, since the user
can print with Wordpad in her session.

The thing that puzzles me, is that, according to Vera, printers
normally don't have restrictions as to who is allowed to print (the
fact that the user can print with Wordpad shows that it's the case).
So why would just our application be unable to print, with no error
message?

I asked the adminstrator to
- check Even Viewer
- download and run FileMon and RegMon to see if anything interesting
shows up.

We're in a difficult situation, because he thinks that either our
application is not TS-compatible or I didn't know what I was doing
while installing the application on the server through a TS session.

I'll try to build a single 2003 Server with AD here (used one as a
workgroup server), and see if I can find something.

If you like you could change your app to use reg-free
COM, that would eliminate the need to modify the
registry each time you update.

We're moving to this, but currently, we have a few ActiveX controls
that must be registered with every new release.

Thank you.
.