Automatically print validated docs 2

[florindaniel]

Hello,

I'm trying to solve this problem:

I have multiple workstations that are editing documents
(invoices, etc...), when a document is OK it is validated by the operator (there-s a flag
in the DOCUMENTS table that is replaced by .T.)

Is there some way to have a monitoring app, on an other workstation, that senses a document in
the table changed status and print it. Having a timer in the form and periodically scan for
the changes seems not too elegant . Can I RAISE EVENTS across the network?

Thank you
Daniel

 

[Mike Lewis]

Hi Daniel,

Actually, a timer would be the simplest way of doing this. I'm not sure why you say it's "not too elegant".

But the timer wouldn't be on a form. I would create a separate executable, which probably wouldn't have a user interface. It would initialises the timer; when the timer fires, it would search for the documents that have the flag set, then go ahead and print them.

There are a couple of points to watch for. The program that sets the flag must be sure to flush its buffers (by calling the FLUSH() function) after it commits the update. But even if it does this, the timer event might not see the updated flag. It might be necessary for that event to open the relevant table each time it is called, and to close it when it has finished. (I had a similar problem once, and found that I could avoid the overhead of opening and closing by buffering the table, even though the method in question never writes to it. If that's an issue for you, I can check back on my code and give you more details.)

Despite that point, I really think a timer would be the best way to go.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I would have a form on the remote scanning machine - and I'd show a log on it...
Much easier to debug!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

Why are you uncomfortable with a timer, Daniel?
Are there too many records to check? Are you afraid of reading a bad/outdated flag status (as Mike points out could be tha case).

What's good for this kind of job is a job table, in your client application you don't just set a flag to the document, but add a record in this seprate job table, telling to print the changed doc. The job records can be deleted, once the job is done and deleted records can be reused by a RECALL. That means the DBF does not grow large, the timer does not have to scan many records at any time, this doesn't grow by the number of documents but only will reflect how many changes there are at any current time, you may never grow to more than 10 records overall, depends on how many users there are and how fast they change documents, what nature the documents are, etc.

On the other side, there is interprocess communication. But I doubt you will want to dive into all the options you have, but several are possible through network, too. RPC is another thing, CreateObjectEx() a third.

But a timer is very convenient and nothing unusual.

Bye, Olaf.

 

[florindaniel]

Thank you all (Griff... I don't get it, I do have a form on the remote machine)

I think it was mainly about me being uncomfortable with timers ( I really don't know why)

Thank you again

 

[GriffMG]

Hi

I was just saying that I would use a scanner that did have a user interface - Mike was suggesting he would do it with one - I like
to see a log running so I know all is well.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

I don't insist on my point about the user interface. It depends on the situation. But of course the user does need some way to quit the app, which suggests at least some minimum UI is needed.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads