Refresh from database

[benplace]

I have an app that reads from a database and fills in one column if the completed field = 0 and another column if it = 1 in the database.
Basically two columns incomplete and complete.
When someone checks something complete I want everyone else running the program to see it is complete. What I did is create a timer that refreshes ever 15 seconds. This causes the screen to flash and people click wrong things if it refreshes. Is there another way to have everyones program update without using the timer?
I hope that makes sense.
Thanks in advance for help.

[Shaggy Hiker]

There are lots of possibilities, some easier than others. A timer with an interval that long would mean that the state of all the programs could be wrong for as much as 15 seconds. If that isn't a problem, then I think that the easiest solution is to address the screen flash, which is probably simple enough, but we'd need to know more to understand it.

Alternatively, you could use a faster time to reduce the delay, or you could implement a messaging system. The latter is the most difficult solution, but would be ultimately the most responsive. If all the computers are connected via a LAN, then a UDP message broadcast whenever something is completed would be relatively easy to implement. It becomes more difficult if you have firewalls in the way, as the messages would have to get through the firewall.

I guess it comes down to how responsive you need the system to be.

[benplace]

They are all on one internal LAN so no firewall issues. How would I write code to send out a broadcast telling the program to refresh?

[benplace]

Basically I need to run this code

Me.bFlag = False
        ListBoxUpdate()
        Me.bFlag = True

whenever an event happens, like the completed button is pressed ot a chekedlistbox item is checked.
It has to run on all computers that have the program open, no matter where the button is pressed or the item is checked.

[Shaggy Hiker]

Well, it isn't quite THAT easy. What you would have to do would be to send a broadcast message. Each program would also have to be listening for these messages, and would have to take action when the message is received. That is when you would run that code.

If you want to explore the UDP option, you might take a look at the UDP class I put over in the .NET CodeBank. That class is derived from code I use for this type of thing in a robot brain. There isn't much to it. There are other alternatives, as well. I believe there is now a UDP provider for WCF services, though I doubt that learning WCF for this situation would be justified.

[benplace]

I am looking at a generalized UDP class post, and I am not sure how I would implement this into my code.

[Shaggy Hiker]

The objective that I would be trying for is this:

1) One method to call when you want to alert all the others.

2) An event raised on the UI thread when an alert is received.

The first one can happen pretty nearly anywhere. UDP packets are super fast to send, so this can all happen on the UI thread without any problem.

The second is more complex. The UDP Listener has to be waiting for something to arrive, and when it does, it raises an event. That waiting means that it should be done in a background thread so that it doesn't block the UI thread. However, the event has to be raised on the UI thread.

If you are looking at this thread:

http://www.vbforums.com/showthread.p...&highlight=UDP

it is an overly complex class for doing what you need. That was written to queue incoming messages for later use, but you probably don't even need to care about that. The messages may be as simple as a single byte. In fact, from your description, you probably don't even care what the message says. As soon as you receive ANYTHING, you would raise the event. Therefore, you could use the class as is, or you could strip out all the parts related to Threading.Monitor and the dgList, because you wouldn't be using any of that. In fact, you could remove the Add method and replace it with a direct call to:

myContext.Post(AddressOf GotData, New UDPEventArgs)

because the contents of the UDP packet can be ignored. What that would mean is that on the main form, or somewhere else where it can be accessed, you would create an instance of that class giving it a port number (use a large fairly random number greater than 10,000, such as 23654, or something like that). The only key to the port number is that it not conflict with any other communication on your network, which is unlikely if you use a five digit number. By default, it already is set up to broadcast, so it should work like that. The properties for SourceIP and TargetIP would only be used if you want to designate specific targets (non-broadcast), and want to use a sourceIP other than Any.

Unless you change the code to remove the dgList, you would want to periodically flush that. Otherwise, the queue will keep filling up with tiny byte arrays as the program runs.