Create a Windows Service 1

[dsi]

I need to create an application that will run on a workstation, similar to a service. The program will be launched at startup and needs to shut down automatically when the user logs off.

The program is windowless, and will not do anything unless a flag (file) is present on the network.
Here is what I was thinking:

...
App.TaskVisible = False
...
Do While Dir("\\Network\SomeDir\User.txt") = ""
    Sleep 15000     'Check for flag every 15 seconds
Loop
...
'Do stuff,delete the file, and restart the process

This works fine, and does not eat up the processor.

THE PROBLEM IS:
When I log off, Task Manager does not shut this application down. I would like this application to run more like a service. I have not been able to find any info on this subject. Any ideas?

Thanks!

 

[dsi]

Itfigures! As soon as I posted this, I found a Microsoft article that indicates you shouldn't use VB to create services? In light of this new information, let me revise the question.

We have an NT network with 35 workstations. I need to be able to run an application on any one workstation from another. Any ideas on how can I run a VB application on a different workstation without 3rd party software?

 

[Alt255]

DSI, I'm not clear about what you are trying to accomplish here. Your two posts seem to ask for different results.

My experience has been that it is quite all right to RegisterServiceProcess using VB after loading the app from the RunServices reg key. If you want to respond to changes in the currently logged-on user, why don't you periodically retrieve the name of the logged-on user and compare it with the last user?

You shouldn't have a problem running an application located on another computer as long as you know the proper UNC path to the app and all the dependencies are available on the local machine.

If you intend to execute an app remotely, it is most easily accomplished by sending a message (using e.g. the Winsock control) to an app running on the local machine, telling it to ShellExecute the requested application. (I think this is what you were hinting at). Setting a marker via a file isn't very efficient and could introduce unforseen failures.

There shouldn't be a problem running a "process" (a loose interpretation of the word) designed to perform the task.

Are we on the same base?

Alt255@Vorpalcom.Intranets.com

"If you can get people to ask the wrong questions, they'll never find the right answers."[tt]
Thomas Pynchon[/tt]

Perhaps the reverse is also true....
​

 

[dsi]

Alt:
I am not quite sure what base I am on! After reviewing my posts, I guess I did not fully explain my ultimate goals. I want to force the remote computer to run the application, not run the remote application on my system.

Here are a couple of scenarios:
1 - run a batch file on the computer for user #3
2 - display a message to users #4 & #8
3 - log off user #10 (forcefully)

I need to be able to do this from computer #1 or #2

The solutions I came up with (probably not the best)
A:
If I could have a service running, I could constantly (every minute or so) scan for a user file on the network (user.txt). If the file existed, it would perform the action requested.
B:
Install the application on each workstation. Be able to run that application on computer #3 from computer #1 or #2.

Problems:
I tried to use the RegisterServiceProcess function, but received an error. By the sounds of it, the application must be run from a Services registry key.

Even though I know the full UNC path, only the printer folders are shared.

Do you think that this would be better accomplished using the Winsock control, passing the ShellExecute command?

I appreciate your patience.

 

[Alt255]

I think you are so close to a solution you can't see it. Set up an app on each workstation designed run other apps, shutdown, logoff, show messages... whatever you want it to do. Control the workstations from the server using Winsock.

Most of what you want to do can actually be performed directly from the server using the API but the issues and conditions and implementations become a little hairy around the edges. That's why I suggest performing all the dirty work at the local level, based on messages sent from a remote controller. If you have "listener" on each workstation you can control everything, almost like you were sitting at the console.

Alt255@Vorpalcom.Intranets.com

"If you can get people to ask the wrong questions, they'll never find the right answers."[tt]
Thomas Pynchon[/tt]

Perhaps the reverse is also true....
​

 

[dsi]

OK. Here is what I am going to try:

1. Create a separate application that will be installed on each workstation. This app will handle all of the tasks that may be required (logoff, display messages, run batch files, copy files ...)

2. Use Winsock to run this application on the workstation from the server console. Unfortunately, I am new to this, so we can all expect to see some Winsock questions in the near future.

 

[chiph]

If your French is good and you don't have a lot of money, take a look at:

http://www.devparadise.com/technoweb/code/vb/A165.php3

Or, if the reverse is true, take a look at:

http://www.hallogram.com/ntservicetoolkit/

Chip H.