how to find richtext codes for highlight, underline etc
- Thread starter CJ_London
- Start date
- Local time
- Today, 12:48
- Joined
- Feb 28, 2001
- Messages
- 28,695
The question you must ask is "how precise will that measurement have to be?" You appear to have at least one suggested solution but I will comment on what I did in case you have to change directions.
On every Form_Current routine and every Form_Unload routine I added a line that dumped the value of Now() into a Public variable that (in my case) was kept in a general module. Since everything I did was done through forms that had this feature, that gave me a moment-in-time at which I knew SOMEONE was doing something with some form. Then my separate once-per-minute timer could decide how long I was idle and whether it was time to exercise the shutdown code. In my case, ordinary users had 30 minutes. Developer-class users (me and two other people) had 60 minutes.
When I wanted to know what everyone was doing, the Form_Current, Form_AfterUpdate, and Form_Unload events gave me places from which to write a small logging entry. I had a subroutine that write to a table listing a date/time, the name of the form, and the ID or prime key of the current record. That way I had at least a couple of points where I knew someone was working on something. You would be able to do an after-the-fact analysis of this kind of table to get at least some useful information.
One problem here is that you can write logs all over the place to track what was done, but the more logs you write, the more time you take away from other tasks within the app. You have to remember that for the most part, Access is single-threaded when it calls our event code. If you are doing X, you cannot also be doing Y and Z at the same time.
Another problem inherent in this concept, though, is that even if you are working one someone's problem, there will sometimes be some "think time" that is absolutely unquantifiable. There is no way to know whether that apparent idle time was someone daydreaming at the desk or or someone trying to understand what they see in the customer's history files. You cannot differentiate that kind of thing because it doesn't occur inside the computer. It is inside someone's head. Since we don't have the man-machine direct plug-in interface, it becomes hard to read what someone was thinking.
The digital equivalent to this question comes when you ask about Word, Outlook, etc. You can tell if these things are open using, among other methods, the GetObject routine (which you can look up online) so that you can find if an instance has been launched and not yet shut down. In fact, to use Outlook Application Objects from Access, you are strongly recommended to use a GetObject before trying to launch your own copy of Outlook, because Outlook doesn't like it when you have multiple instances. One of its internal databases doesn't share nicely.
In order for you to know that someone is actually doing something in Word or Outlook or Excel - or even a second instance of Access - leads you into no-man's land. You cannot go there. And I don't mean "from Access." It isn't the VBA environment that would stop you. Windows Security will not let you reach into another task image or another process. The privacy standards mandated by the US Government and the EU Government have the effect that it is ILLEGAL to reach in and look at what another task is doing.
The SYSTEM account can do that to some extent but you do not DARE run any user-controlled app as SYSTEM because of its implications. You can use Task Manager to look at some superficial aspects of other tasks but there is no way for you to look any deeper than Task Manager would show you. To actually know what someone is doing in another taks, you would need some Windows privileges that are SO powerful that having them would cause your IT shop to come after you with lit torches and rusty pitchforks seeking to slay the monster you created.
On every Form_Current routine and every Form_Unload routine I added a line that dumped the value of Now() into a Public variable that (in my case) was kept in a general module. Since everything I did was done through forms that had this feature, that gave me a moment-in-time at which I knew SOMEONE was doing something with some form. Then my separate once-per-minute timer could decide how long I was idle and whether it was time to exercise the shutdown code. In my case, ordinary users had 30 minutes. Developer-class users (me and two other people) had 60 minutes.
When I wanted to know what everyone was doing, the Form_Current, Form_AfterUpdate, and Form_Unload events gave me places from which to write a small logging entry. I had a subroutine that write to a table listing a date/time, the name of the form, and the ID or prime key of the current record. That way I had at least a couple of points where I knew someone was working on something. You would be able to do an after-the-fact analysis of this kind of table to get at least some useful information.
One problem here is that you can write logs all over the place to track what was done, but the more logs you write, the more time you take away from other tasks within the app. You have to remember that for the most part, Access is single-threaded when it calls our event code. If you are doing X, you cannot also be doing Y and Z at the same time.
Another problem inherent in this concept, though, is that even if you are working one someone's problem, there will sometimes be some "think time" that is absolutely unquantifiable. There is no way to know whether that apparent idle time was someone daydreaming at the desk or or someone trying to understand what they see in the customer's history files. You cannot differentiate that kind of thing because it doesn't occur inside the computer. It is inside someone's head. Since we don't have the man-machine direct plug-in interface, it becomes hard to read what someone was thinking.
The digital equivalent to this question comes when you ask about Word, Outlook, etc. You can tell if these things are open using, among other methods, the GetObject routine (which you can look up online) so that you can find if an instance has been launched and not yet shut down. In fact, to use Outlook Application Objects from Access, you are strongly recommended to use a GetObject before trying to launch your own copy of Outlook, because Outlook doesn't like it when you have multiple instances. One of its internal databases doesn't share nicely.
In order for you to know that someone is actually doing something in Word or Outlook or Excel - or even a second instance of Access - leads you into no-man's land. You cannot go there. And I don't mean "from Access." It isn't the VBA environment that would stop you. Windows Security will not let you reach into another task image or another process. The privacy standards mandated by the US Government and the EU Government have the effect that it is ILLEGAL to reach in and look at what another task is doing.
The SYSTEM account can do that to some extent but you do not DARE run any user-controlled app as SYSTEM because of its implications. You can use Task Manager to look at some superficial aspects of other tasks but there is no way for you to look any deeper than Task Manager would show you. To actually know what someone is doing in another taks, you would need some Windows privileges that are SO powerful that having them would cause your IT shop to come after you with lit torches and rusty pitchforks seeking to slay the monster you created.
