Task or in process 2

[BasicBoy]

I have a Diary program (written by myself in VB6)which we use to send messages to each other at the office. It checks every two minutes whether there is a new message for a user and then warns him/her. I use Access as a database.
The problem is that when the user has not opened the program, he cannot be warned of a new message.
I now need to use another way to warn the user of a new message when the program is closed.
I have seen certain programs in Windows are handled as tasks and other as processes. I know however that Skype and Teamviewer are running as processes. Why this is so I do not know.
Thirty years ago we had programs which was termed as TSR (terminate and stay resident). I do not know whether this is the same.
Can someone please point me in the right direction to write a program in VB6 which might open when a user starts Windows and which will stay resident as a process to check for new messages every so often.
Thanks a lot. I wish I could award five stars for a complete reply here.

 

[LaurieHamlin]

Which versions are you using (OS and Access)?

 

[BasicBoy]

Windows 7 and Access 2010.

 

[dilettante]

There are basically two approaches to this.

One is used when (a.) the program needs to run even when no user is logged on to the PC and (b.) one program is used for any and all users that log on or may be logged on (fast user switching scenarios, multi-user server machine, etc.). This would be to write part of the application as a Windows Service.

That is probably overkill though, and may not really fit your situation.

The other is simply to install your program to run on logon, and the easiest and most manageable way is to install a shortcut in the Startup folder. Beyond that you might just write the program to minimize to the notification area ("tray"). You might even want the program run run minimized on startup (user logon).

A progam minimized in this way can do a variety of things to announce activity. One is to change the appearance of the "tray icon." Another is to use notification balloon messages, most of the plumbing for this being built into Windows. Yet another is to implement what are known as "toast notifications" where a small window slides up from the "tray" like toast popping up from a toaster.


None of this really has anything to do with the versions of Windows or Access you are using. The possible exception being Win9x which does not support Windows Services but (a.) that is probably the wrong path for you anyway and (b.) Win9x OSs are beyond dead.

And you'd want to avoid Access like the plague for this. Just use Jet 4.0, which is part of Windows. Remember: "Access" is just a database client that heavily parasitizes Jet (and ACE in later versions) and adds all sorts of cruft to a clean database created through ADO/ADOX.

This point seems to be lost on so many people who see an MDB or ACCDB file and think "Access" when they shouldn't. You do not need MS Access installed on a machine to create and use Jet (or ACE) databases in VB6 programs. Of course ACE requires that you deploy the newer "Access runtime" components so stick to Jet.

 

[strongm]

>certain programs in Windows are handled as tasks and other as processes

Your terminology is confused (to be fair, not helped by the naming of some of Microsoft's tools)

What you refer to as a task is really a program (or application). And a running program consists of at least one process (possibly more than one). It also inherits the desktop and permissions of the user that launches it.

Since there is no user and no desktop before a user logs in, a program can only run after a user logs in.

However, there are times when we need an application to run when Windows starts up but before a desktop user logs in (there may also be requirements that an application does not terminate when the desktop user logs out). Antivirus software would be a typical example of this. Such applications are run as services (and, as such, have a number of special requirements) - they still need a user account to run under (which defines the permissions that they get) but do not have an associated desktop. These are sort of like the old TSRs that you mention.

However VB6 is not really designed to allow you to create services. Here's an aging Microsoft KB advising against doing it (with rationale). It also contains a link to a KB that briefly mentions an OCX (NTSVC.OCX) that actually allow you to go against their own advice (i.e. it allows you to create services in VB6). They do not provide a link to the OCX itself anymore, however. So here's a site where it is still available:

http://www.andreavb.com/vb_downloads.html

(should be the second download down). A helpfile is included.

Note that, whilst I have had no problems with this OCX on OSs up to and including Windows 2003 I have never tried it on anything more recent (i.e. from Vista onwards), and I'd suspect that it might be troublesome.

 

[dilettante]

Note that, whilst I have had no problems with this OCX on OSs up to and including Windows 2003 I have never tried it on anything more recent (i.e. from Vista onwards), and I'd suspect that it might be troublesome.

Works just fine, at least as far forward as Windows Server 2008 R2 (basically "Windows 7 Server").

You might (or might not) be surprised at how much of my income comes from writing services in VB6. Works fine, lasts a long time.


But I suspect he just needs a Startup Folder program with minimize-to-tray.

 

[BasicBoy]

Thanks you both for your excellent contributions.

I am presently using the notification area with NotifyIcon API to put an icon in this area when the program is minimised and I prevent the program from showing an icon in the taskbar.
I also change this icon to an icon showing a postal envelope with stamp with a .wav audio to show users when a message arrives for them - and they find it quite cool.

I can also start the program on startup or login, but users are free to close the program anytime for whatever reason they think fit, which happens often if they work with powerful programs or run out of memory.

So, I cannot depend on them having their program open always.

The suggestion of Windows services seems to be a good one and I especially like the toast type notification, although I do not have a clue as to how to use Windows services or the toast notification. If you can elaborate somewhat on that I will appreciate.

Thanks

 

[dilettante]

The biggest issue with services is that they can't have a user interface. You could get away with that in the past but it was always a bit dicey and in any case is blocked by Session 0 Isolation on all supported versions of Windows.

So you need a separate UI program that runs in the users' sessions and talks to your service using Named Pipes or other IPC. Worse yet your service would need to monitor logons in order to know when to start the UI program, and would probably need the users' credentials in order to impersonate the user for proper operation.

Even then the user can kill the UI program and you are back to Square One.


Some ISVs take this another step. They add a third program. This third program gets started by the service but runs in the background. When it needs to notify the user it starts the UI program. Even if the user kills the UI program this middleman keeps running. Or the user can manually run the UI program when he wants to interact with it.

However you may as well just skip the service and have this middleman be started upon logon, and put everything but the UI in there. This lets you skip dealing with services as well as the tricky logon monitoring and user impersonation stuff.

After all, if the user is going to kill both of these they'll probably stop or even disable a service just as well.