FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

DISK I/O

Follow a strategy for sharing files


I have a program in PG/FB to tabulate results at gymnastic competitions and would like to expand it to accept scores directly from the each event rather than entering then in later at one station.

I'd appreciate any help. What routines/modules should I be looking at so that each computer will send the score to the main computer and it, in turn, will accept it?

Does anyone have suggestions for a strategy to do do this? Or small examples?

Stu Cram

So each event would have its own Mac? and they would all be networked on ?

Why not have each computer create a specially formatted text file that could be sent to the Master Mac. The Master Mac then could, at the operator's leisure, read the data from each of the text files into your Program.

Like, have menu items for "Balance Beam" and "Floor Exercises" and when one of these was selected, the data from a specific text file, containing the current results for the "Balance Beam", would be read into your Program. It would appear that you're going to have a separate Program for each of the events anyway, right? Don't know if this has been any help, but it seems fairly simple.

Joe Wilkins

There are three methods I can think of which have different advantages and disadvantages.

Method 1:
Ideally, create an application which is a Server application on your network. Basically, it would receive messages from Client applications via AppleEvents and collate the table as required. Each message would contain the data you wish to log. The Client would transmit the data when entered by the operator (or equipment?). Since this would be in realtime, the Server application could display results and summaries as they occur.

Method 2:
Each Client would create one file for each entry with a unique filename perhaps based on the client location and time of hit. All these files from all different clients would be stored in one folder. At the appropriate time, the processing application would read all the files one by one and collate the results.

Method 3:
Although risky if multiple hits occur simultaneously, you could have a disk file which is opened using "A" meaning "Append" so data is added to the end of the file by the client software. Each client would try and append its data to the end. You would have to Open, Write and Close within as small a time as possible to minimise the risk of another client attempting a write at that time. At the end, another application would tabulate the results from processing that data file.

Just some thoughts to get you going.........!

Deep

This could work - but it can also be automated.

Client app
- builds shared folder on its HD
- Saves results to shared folder
- (I do it this way to minimise the chances of data loss)

"Master App"
- logs on to shared folders (under user control)
- every few seconds - check each folder for changes to file
- if changed, read and append results.
- hint - don't forget to check if file is open by other app.

No need for apple events etc and all the code is available or relatively easy.
You could even add some nice user interface stuff to create the folder,turn on appletalk etc.

There is some client/server apple event code floating around (I think Tedd sent me some once if you want to go that way.

David

I've done something very similar recently, so here goes.

First, you'll have to buy Staz's AppleTalk software. You won't need Apple Events unless you have to pass messages between two programs running concurrently on one machine.

Second, work out what information will be gathered externally, and design your message structure. This design work is the key to everything. For example, if you captured data on floor exercises, the ascii message would look something like :

@A_R1_12_F_8.6_8.2_8.4_8.1@

Broken down, this would be :

message start flag (anything unique)
Message type (make up your own structure)
delimiter
Sending Unit
delimiter
competitor number
delimiter
floor exercise identifier
delimiter
score
delimiter
score
delimiter
score
delimiter
score
message end flag

You'll need to create as many messages as you need, but think it through and work out every possibility - although you can add messages easily, it's easier to get the design right first.

Staz's filter does most things for you, but I would edit it slightly so that you can log on as Server or Client - just duplicate the relevant bits of code and comment out the bits you don't need.

(BTW, this is how you create a sculpture of an elephant. Just get a block of granite and hack out all the bits that don't look like an elephant. But I digress.)

Then you can log on the central machine as a Server, and wait until all the Clients log on - create a message to tell you when they have. Actually this isn't necessary, you can log on clients on the fly, and log them off when you want - just create messages to tell the Server who's on and who's off.

When all the Clients are on, the Server can send out a message saying "go".

Then just idle the Server until you get a message in, route the message to be processed by the message type/ sender/ exercise or whatever. Then send a message back to acknowledge the message, and update the database.

You can also send out messages to each client giving any information you want,such as overall scores, etc. You could even handle database access in the same way - just receive a query, do the search, and send back a message with the results.

That's it, really. Staz's filter does all the hard work for you. Grossly underpriced at $29.50, too.

But remember three very important things.

Design, Design, and Design.

Phil