Prob's using Albert Kallal's SetDefaultPrinter on some OS's

[MLH]

I'm using Albert Kallall's code to set printers in A97.
I find that on some machines, the code locks up
and on others, it does not. I would like to overcome
this and was wondering about the experiences of
others who attempt to set default printer in A97?

I have an app running on an XP home edition box
fine. Same app running on XP Professional fails
when SetDefaultPrinter() is called.

I can post more of the code, which may be found
at http://www.members.shaw.ca/AlbertKal.../printch97.zip
but I did not wish to clutter the post with too much
that may distract from the question.

[salad]

MLH wrote:

I'm using Albert Kallall's code to set printers in A97.
I find that on some machines, the code locks up
and on others, it does not. I would like to overcome
this and was wondering about the experiences of
others who attempt to set default printer in A97?

I have an app running on an XP home edition box
fine. Same app running on XP Professional fails
when SetDefaultPrinter() is called.

I can post more of the code, which may be found
at http://www.members.shaw.ca/AlbertKal.../printch97.zip
but I did not wish to clutter the post with too much
that may distract from the question.

I'm using XPPro and don't have a problem. Maybe step through the code
and see where it locks up on one of the machines that locks.

[MLH]

Thanks, Salad, for the helpful comments.

I had a hunch someone might suggest that. The machine is 75 miles
away. I'll have to RADMIN into it from here. The app on the remote box
is in a runtime environment. I've never tried single stepping in that
situation. Will give 'er a go.

BTW, Salad, with STOP statements in code to simulate breakpoint,
will the one-line-at-a-time execution mode continue if the procedure
with the STOP statement in it calls another procedure? Or, must I
put a STOP in the called procedure as well to carry on with single-
step execution?

>
I'm using XPPro and don't have a problem. Maybe step through the code
and see where it locks up on one of the machines that locks.

[salad]

MLH wrote:

Thanks, Salad, for the helpful comments.

I had a hunch someone might suggest that. The machine is 75 miles
away. I'll have to RADMIN into it from here. The app on the remote box
is in a runtime environment. I've never tried single stepping in that
situation. Will give 'er a go.

I don't believe you'll be doing anything like that in a runtime environment.

>
BTW, Salad, with STOP statements in code to simulate breakpoint,
will the one-line-at-a-time execution mode continue if the procedure
with the STOP statement in it calls another procedure? Or, must I
put a STOP in the called procedure as well to carry on with single-
step execution?

Sub Proc1()
MsgBox "This is proc1"
Stop
Proc2
End Sub
Sub Proc2()
MsgBox "This is proc2"
'run Proc1 thru, then run again after commenting out next 2 lines
Stop
MsgBox "Proc2 stopped"
End Sub

>

>>I'm using XPPro and don't have a problem. Maybe step through the code
and see where it locks up on one of the machines that locks.

[MLH]

>I had a hunch someone might suggest that. The machine is 75 miles
away. I'll have to RADMIN into it from here. The app on the remote box
is in a runtime environment. I've never tried single stepping in that
situation. Will give 'er a go.

I don't believe you'll be doing anything like that in a runtime environment.

Well, you are probably right. I've never tried it. But it makes sense
that the access developer team would not provide such debugging
tools at the runtime level. I have no clue how to test for the porint
of failure on the remote installation. Unless someone intimately
familiar with similar issues reads this post and responds with a
working solution - I'm just stuck.

>>
BTW, Salad, with STOP statements in code to simulate breakpoint,
will the one-line-at-a-time execution mode continue if the procedure
with the STOP statement in it calls another procedure? Or, must I
put a STOP in the called procedure as well to carry on with single-
step execution?

Sub Proc1()
MsgBox "This is proc1"
Stop
Proc2
End Sub
Sub Proc2()
MsgBox "This is proc2"
'run Proc1 thru, then run again after commenting out next 2 lines
Stop
MsgBox "Proc2 stopped"
End Sub

OK. Thx. I see how it works now.

[salad]

MLH wrote:

>>>I had a hunch someone might suggest that. The machine is 75 miles
away. I'll have to RADMIN into it from here. The app on the remote box
is in a runtime environment. I've never tried single stepping in that
situation. Will give 'er a go.

I don't believe you'll be doing anything like that in a runtime environment.

Well, you are probably right. I've never tried it. But it makes sense
that the access developer team would not provide such debugging
tools at the runtime level. I have no clue how to test for the porint
of failure on the remote installation. Unless someone intimately
familiar with similar issues reads this post and responds with a
working solution - I'm just stuck.

Why not create a new database as a runtime. Stuff the printer code in a
module. Then put in a bunch of msgboxes in the code or add a table and
at breakpoints add something to the table that tells you where you got
to before locking. Then run a form that calls the something to executes
the code. It may take passing the person the database a couple of times
till you find the code line that stops.

[Albert D. Kallal]

I would also check if the user in question has restrictions on changing .ini
or registry entries.

Companies that lock down there computers more tight then normal will NOT
give users permissions to change registry entries, and that could/would
include the .ini file which looks like registry settings to windows xp.

Further, I seen even strange behaviours access 97, as once again, it wants
FREE REIN of the machines features.

Since a97 is about 10 years old, then it is little surprise that registry
entries and security issues are a issue. This as a general rule means that
ms-access needs to run on a machine without any restricted group policies.

You might want to check/ask if they are running a domain server (that is
just a fancy term for a "central box" that controls all permissions, and
even logons of EACH computer in the building. (this makes sense, as you
can't possible manage 100's of computers by walking around to each machine!!
Of course, if that domain server ever goes down, then users can't even
logon, or access files on their OWN computers attached to the network!!

This likely some permissions issue, and the user can't change ini files.
Check if the user can even change their default printer manually - they
might not even be able to do that. If they can't change the default printer
manually..my code certainly will not. However, if they *can* change the
default printer, it still might be a permissions issue.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[David W. Fenton]

"Albert D. Kallal" <Pl*******************@msn.comwrote in
news:Kf7Mg.530409$IK3.132365@pd7tw1no:

Companies that lock down there computers more tight then normal
will NOT give users permissions to change registry entries, and
that could/would include the .ini file which looks like registry
settings to windows xp.

Pardon me, Albert, but you seem to be unfamiliar with the default
configurations of workstations in a domain controller configuration.
The default is to make people members of the Users group only, and
*not* administrators, and then domain policies are applied to the
workstations that prohibit changes to the registry or to the C:
drive outside the user's profile.

Anyone who is *not* planning their Access applications with this in
mind is about 7 years behind the curve -- these changes were
implemented in Win2K.

And when Vista comes out, no matter whether you're in a domain or
not, your apps are all going to break.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[MLH]

Personally, I found your comments of great interest,
Albert. And I thank you for taking time to post a reply.