"paii, Ron" <none (AT) no (DOT) com> wrote:

Shuttong down a TS/Citrix session is very unlikely to cause corruptions.

1) after fifteen minutes any batch processing is likely to have finished.

2) I would think that TS/Citrix would send a program shutdown message to the apps
running inside the session which would then gracefully end. Now what might not
happen is your last updates which you haven't completed on the form might not make it
to the data storage.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

Thanks for the responses!

I should have mentioned that before we had things set up this way, the
timeout was set up differently and the citrix window with the app icons
would timeout but, when the users came back to their workstations, they
still had access to work in the applications they had already opened.
This conflicts with the rules that we are required to comply with.

I also should have explained about the Access and Crystal better, I
guess. Those are applications that the users have published to them
once they login to Citrix. So, if the user opens these applications,
i.e. connected to a database, and they walk away from their machine for
15 minutes, I need them to have to enter their password in order to
continue working in these applications. I'm even okay with them having
to log back into Citrix and then have the applications right where they
left off, but I can't have the open applications available to them once
the idle timeout has been reached.

Tony, if you can relay to me how I would go about setting this up, I
would be grateful!

Thanks!
Sam



*** Sent via Developersdex http://www.developersdex.com ***

Hi,

All and all you need to write client code to manipulate the window on
your behalf.

So first, from an Access macro, you need to get a handle to the window
that you are interested in. You may need to import the correct Win32
API to do this. Use a sniffer like Visual Studio's Spy tool to get the
Window name or handle class.

Once you have an actual window handle (hWnd pointer which will change
for every execution) you can use this to send all kinds of Windows
events, including fake mouse movements.

You would need to find a way to do this from a separate thread than
your batch job, otherwise you may simply have a lot of movement after
your job is finished.

Also, in certain scenarios, Office (Access) may be running in a
background mode and not interact with Windows' UI layer. This is why
Office Automation (from Office as well as out of Office) is and always
has been a bit of a black art (VSTO is solving this somewhat).

So all-and-all it can be done, but you are actually facing a problem
domain that has it's own set of problems. You can read up on "automated
UI testing" since these guys do similar things (how to automate mouse
and keystrokes while running batch processes).

Getting the administrator to extend the timeout may strech your
political skills, but is still easier than writing a script that works
predictably :-)

Good luck.
JamesA

*** Sent via Developersdex http://www.developersdex.com ***