A Most Unique Challenge

[oscarbum]

Thanks to the tons of help I've received from this site, I'm now the man at work. So, now they throw something HUGE and, frankly, I'm not sure FilePro can do it. I can't figure out how anyway.

Think of it like this. The boss wants FilePro to do a seating chart for a theatre. I need it to be able so that a user can click on a seat, have the seat clicked on show up in a record, and make it obvious that the seat is no longer available(change color, whatever.) Killer stuff.

Again, I don't know if FileMaker is even capable of something like this, but if anyone has a suggestion on how I might be able, I would be unbelievably gracious.

[Vaughan]

Sure, FMP can do this. Lotta work though.

Easier in FMP 7 than FMP 6 though -- I wouldn't start a major job like this in an old version anyway, unless you can get a guarantee you'll be paid to re-write it in a years's time.

[stanley]

Oscar:

Sure. FMP can handle this. The question is: How?

The other question is: Do you have enough time to implement it?

The simplest (and most labor-intensive) solution would be to create a layout with a button for every seat with a container field superimposed over it, and a corresponding script for every seat/button. The script would mark that seat as "taken" (or whatever) and also put a color into the container field.

You could have a record for every show, and a field for every seat (which is how the marking would happend.)

Pretty straight forward, but a lot of work.

-Stanley

[comment]

Isn't this sort of like a calendar file? Rows instead of weeks, seats instead of days.

[Fenton]

It sounds very much like a calendar solution; though with more "days in a month." Basically you have so many rows of seats, and so many "columns." It depends of course on the seat plan of the theater how well this works out, how rectangular the floor plan is, as to how efficiently you can use portals. But it can be basically a portal per column, and a record per row.

I would recommend version 7. In a calendar solution you have a "space" for each possible "day" (which is more than 31). This means about (can't remember exactly, and it's late for counting) 37 scripts for an action of clicking on a day; same amount of calculations for a day. Lots of small precise layout. It can be tedious.

In version 7 the 37 scripts can be condensed to 1. Quite a savings. Because of being able to assign a "script parameter" to each button (day squares) on the layout. And you would have 1 per seat.

The ability to read "through" an intermediate table occurrence, to show data in a square, may also save a lot of time.

The seating chart is mostly a bunch of portals and records, defined by simple numbers or letters, often globals or unstored calculation fields for the left side of the column portal relationships, and similar data in the rows. It's all kind of a "mirror," to reflect the real data, which is in a simple list table. There is very little "real" data in the chart table; just what's needed to produce the rows and columns (I've said that, haven't I :-)

If you look at the guts of a calendar file you'll get the general idea. A calendar has some special calculations for the first and last spaces, because each month is different there, and may or may not have days in those spaces. A theater wouldn't have that problem.

The other advantage of 7 is the ability to stop and start a portal at specified rows. This could a great help if the floor plan is at all irregular.

There are probably other ways to approach this, using repeating fields more than relationships. But though they may be faster for something like this, I don't much like working with them. That's partly a personal preference (and lack of experience with them), but I also think they are less flexible. If it is a largish theater they better give you a decent computer. This will not fly on a slow machine.

[comment]

Nothing to do with theatre, but my v.4 calendar has only 7 scripts.

[oscarbum]

Well, I have 6 months to pull it off. If I can't do it by then, well then I have 18 months. I've already built a layout with the seating. I don't know how well the calendar solution would work. The theatre has 600 seats. So, in regards to Stanley's solution, basically the each show is a record and each seat has its own field? Never having worked with Containers, am I correct that I should have a container field under each button, but it can be the same container for each seat, right, I don't have to make individual containers? What if I have different Containers for each ticket type? Basically, they want the seat to turn a different color based on the type of ticket it is.

Man, this is going to be huge.

Thanks for all your help.

[QuinTech]

Hi, Oscar. Cris Ippolite of iSolutions demoed this exact system at DevCon last summer. There was a lot of Macromedia Flash development involved in it as well, but it sure was a neat-looking system. It was actually used at the Academy Awards (or some other big mucky-muck show).

I doubt that he would explain to you how he did it (seeing as he makes a living selling it), but you might be able to buy the program from him if you contact them.

HTH,

Jerry

[Ender]

The iSolutions thing is very impressive, and it's worth looking into.

If you wanted to try to do this in FM natively, I'd suggest breaking the theatre into sections, and just showing seats for one section at a time.

[comment]

I don't know how well the calendar solution would work.

About this well.

theatre.zip

[iSolutions]

Hi Oscar-

Sounds like you have the same challenge that was presented to us on similar projects. We solved the problem by creating a stand alone executable file using Flash, that speaks to FileMaker via FileMaker Server Advanced using XML.

Sounds more complicated than it really is...but what it allows us to do is run an interface file (much like Java does for other DB apps) that communicates with a FileMaker database.

In the case of the solution we built for the Oscars (Academy Awards Show), we can launch the executable from within FileMaker...even transport it in a container field, then it opens without a browser, plug in or app....and the user sees an EXACT replica of the theater in vector form. Users simply drag and drop an icon onto the seats they want and records are instantly created int he appropriate FM table.

Same is true for editing records or deleting them via the interface.

Sounds complicated and expensive, but it is really not either of the two. We have built several other venue maps and calendar versions of this technology.

We had also tried to build the same with buttons back in the day....but it was soooo slow over a large network and needed so many factors to run smoothly, that we left that for the Web route.

I know a few DEVCONs ago, Alber Alverez ate somebody's hat because he found an actual use for more than 100 active buttons on screen. Albert contended that there is never a use for so many....the guy who 'proved him wrong' built a seating chart using 1000 buttons of somethign crazy like that. He ate the hat...but then I showed him this Flash FileMaker stuff later that day in the speaker's lounge and I think it gave him indigestion.

[transpower]

Oscarburn: Do you mean FilePro or FileMaker? These are two different languages. I agree with Vaughan that you should do the work in FileMaker Pro 7. But this is not A Most Unique Challenge; this same question came up a couple of months ago. I stated then that (with Developer) one could define a matrix of 1's and 0's to show whether or not a seat were occupied. The user would enter the row-col nos. and the program would respond with whether or not that is available, etc.

[stanley]

Oscar:

Here's a very simple version of what I was talking about. This is a single file, with just two seats. You click on the seat and it toggles between green and red, meaning available or not. Yours might be much more complicated, but this is the idea.

-Stanley

[Reed]

Just to throw in another possibility, here is a link to a seating chart solution from Duncan Creations.

http://www.duncancreations.com/index.php?option=content&task=view&id=2

Dana

[cjaeger]

Unless you have a straightforward rectangular seat layout, it's worth to have a look at the Mouse X, MouseY functions of the free Jazz plugin.

I included a small starter file - just the display and click mechanism, not the logic.

JazzMouseTest.fp7.zip

[Brian C]

In your seating chart table create a field:

SeatStatus (number)

This field will be your "flag" which will determine if a seat is taken or not. Use a value list of:

0

1

"0" = Open, and "1" = Taken.

It is nice to use 0 and 1 in fields to be used as a True/False indicator because you can format the number format to be boolean to show No or Yes instead of the 0 or 1 if you want to show a text list.

Create a 2nd file/table called "SeatingStatus" that has 2 fields:

field 1: ID (number) (only 2 records needed here, 0 and 1)

field 2: Picture (container) (either a color or a picture to stored to indicate if the seat is open or not)

Create a relationship from your seating chart table/file to the SeatingStatus table/file to link from the SeatStatus field to SeatingStatus::ID field.

Last, create a calcuation field

cSeatStatusPic (calculation) (calculation result = container)

calculation: SeatingStatus::Picture

[Søren Dyhr]

Eventhoug it looks like Duncan's in principle, am I lacking the posibility to reserve in option as well as cancelation. Then do I use the same related records over and over again in each show insead of making a batch of seats for each show, the reasoning is that the only thing the relations are used for is to avoid flatish repetitions of calcfields - because when it comes to it who are ever goin to make datamining on say a theater seat ...you can't fill the entire theater with 12th row in the middle - since i reuse the related records is it crucial to toggle off the statusarea's rolodex.

Then just a note I use the webdings font instead of containerfields - if you think things looks silly!

--sd

show.zip