Windows Session Info

Started by fhammer, November 24, 2015, 01:18:16 PM

Previous topic - Next topic

fhammer

How can I determine, from within a wbt app, if this was the first time I was invoked, within the current windows session? Thanks much.

td

There are many ways to check if an instance of an application already exists in a session.  One simple way is to call the AppExist function .  Check out the Consolidated WIL Help file for details.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

fhammer

Thanks for responding. I checked out the help for AppExist but it only appears to check for "currently-running" apps. In my case, I want to determine, for example, during execution of A.wbt, if A.wbt has ever been run previously, within the current Windows session (i.e. since Windows started).

I've looked into using environment variables or temporary files. If I could set or create something in the app, which would automatically go away when the user ends the Windows session, that would do it. If there were a windows session id, which changes for every windows session, that would also do it.

Thanks again.

td

Your description was open to multiple interpretation and what you are now stating as your goal is not a particularly common request.   There is nothing 'internal' that would tell you if an app has been executed before in a session because once the a process terminates, all the internal information is gone.   You will need to save some kind of execution counter external to the process, whether an ini file, the registry or something else.  Storing information to a file or the registry is trivial.  However, a process can't make something go away when that process is no longer running so would have to be able to guarantee that the process is running when the session ended.  Another problem is that while session ids are unique among currently running sessions, they can be reused once the session previously associated with that session id goes away. 

You would likely need to do something along the lines of creating a logout script or background service that cleared whatever it is that you store when your app executes.   Also note that there are several ways to obtain the current session id.  Search on 'sessionid' and 'session id' in the Tech Database for some examples.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

snowsnowsnow

I think I would create an INI file that stores the time the app was most recently run, and then compare that to the start time of the current session (which, I assume, is available somewhere - I have not researched this aspect of it).

So, the logic would be something like:

read INI file - get a timestamp - call this "A"
Lookup start time of current windows session - call this "B"
compare them - if A > B (i.e., the program has been run later than when the window session started) exit now
(else) write the current time into the file
continue with program

td

Good idea Snow.  There are several ways to get the logon time including but not limited to WMI, the ADSI extender or the Terminal Services extender.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

....IFICantBYTE

Another way might be to use the "Atom" UDFs I just posted in the Script sharing area?
Regards,
....IFICantBYTE

Nothing sucks more than that moment during an argument when you realize you're wrong. :)

td

Kernel atoms have many uses but they would not cleanly help fulfill the OP's requirements in a way that is as straight forward as Snow++'s simple solution.  Atoms are useful for interprocess or intraprocess communication but the OP's problem is more inter instance communication.  Under these circumstances atoms may result in a resource leaks.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

If this sort of monitoring is really important, perhaps a simple script set up as a service to monitor one or more applications - writing to a log file each process ID as it starts and if it has terminated.

ChuckC

Windows Terminal Services session ID #'s get re-used, both during the same incarnation of the operating system, and in future incarnations as the system is rebooted.  Keeping track of both the system boot time and the TS Session start time would be important.

td

The simplest approach might be just write the session id and session start time to an ini file when a match isn't present.  On subsequent script starts check the for an id+time match.  When they match just exit. One down side is the you may need to write logic into your script to periodically clean out old entries, if that became a problem.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

In fairness to snow++, I don't think snow's method is affected by boot time considerations either, assuming I have translated his proposed algorithm as he intended. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

....IFICantBYTE

Yeah Snow's idea would work well.
It might be overkill, but if easy enough, I would try and convert to Universal Time just to get rid of any daylight saving / changing time issues.

I think this thread has been beaten to death now, and the original poster has probably moved on, but another possible idea is to store a start flag in the Local User Registry as a volatile key? REG_OPTION_VOLATILE
 
Regards,
....IFICantBYTE

Nothing sucks more than that moment during an argument when you realize you're wrong. :)

fhammer

Thanks for all the responses!  As suggested by several respondents, I ended up using the windows start time GetTickCount( ), converting it to a YMDMS windows start time by subtracting from current time, and storing it in an INI file. Each instance of my wbt computes the windows start time, and checks it against what is stored in the INI file. It works great, to within an accuracy of a second or two.