Portal Info to Field in a Tab

[BAAIII]

I have 3 Tabs (One, Two, Three) which each contain 64 Unique fields in 8 rows by 8 columns. The first field in each row holds a unique ID number. This unique ID number is currently being input by typing.

I have a portal which contains the unique ID number that is currently being typed into the Tab. What I want to do is:

Click on the ID field and have the Unique ID number in that field placed inside the Tab ID Number field. Herein lies the rub:

I need the current TAB (one, two or three) and an EMPTY Tab ID Field to be selected.

So Far: I have made the Portal Field ID Number a button and have extracted the info from there. Having trouble finding an empty ID Number field in the CORRECT TAB.

Any help would be greatly appreciated.

[Søren Dyhr]

Beyond there almost certainly is a severe normalization issue here, should you try to investigate Count(

http://www.filemaker.com/help/Functions%20Ref3.html

But with the matters at hand should you not have whopping 192 fields in one table, and the knowledge that the first coloumn is for storing ID of some sort, points in direction of cutting up a portal by 8 lines for each tab, but there might be a problem with the actual position where there could be exclutions??

If this is the case should you investigate the templates posted in this thread - since there must be a relaional solution to you organization of data:

http://www.fmforums.com/forum/showtopic.php?tid/176396/post/204083/#204083

--sd

[BAAIII]

I looked through your information but didn't see anything that shed any light for me. The Portal can contain 1 to 1000 rows of data, all keyed off the UNIQUEID.

The TABS are really worksheets. In other words, each tab gives the user different areas to compute the data he needs. The 8 rows in each TAB compute to one answer per row. The IDNumber is the starting place to pluck one piece of information from the Portal, per row.

With the value (freight from point A to point B ) from the Portal all the other items are then input into the rest of the row in a TAB. When the rows (1 to 8 calculations) are finished with input then a button is pressed to calculate the entire freight and final cost of product to the delivered destination.

Since the product can be delivered to different locations I chose a maximum of 8 destinations per TAB. Some or all may be used. I chose 3 TABS since there could be 3 different products going to 8 different locations.

The PORTAl (Freights) are the same for any of the tabs and are pulled from a FM DB which contains over 70,000 records. These records are Point A to Point B moves through different companies. The user must select which freights he wishes to use from the specific ORIGIN point. Generally this is less than 500 combinations.

The goal is to make it as "user friendly" as possible so that they may only need to "click" on the proper FIELD, ROW etc. from the Portal to begin the ball rolling. It also helps prevent "typos".

Edited December 13, 2006 by Guest

[Søren Dyhr]

The 8 rows in each TAB compute to one answer per row

Could you give an example of this kind of computation??

--sd

[BAAIII]

Well, I accomplised what I needed. I used the following link to and it showed me how to do exactly what I needed:

http://www.24usoftware.com/TabControl

Thanks anyway.

[Søren Dyhr]

But the tabcontrol, doesn't solve the normalization problems at hand? It's posible that the problems you solve this way isn't much more than a fix - and wouldn't have occured when propperly structured.

--sd

[BAAIII]

I appreciate your interest but I really don't think you understand what I am doing. In our business we have multiple factors which go together to make a final destination cost.

The base price of the item; the type of equipment the material is loaded into; the cost of the equipment; the minimum weight guaranteed; the base cost of the freight; the fuel surcharge on the freight; and finally these are all added and divided to compute the delivered price.

Each tab is for one item which is computed into a delieverd cost for up to 8 different desitinations. Each base freight is unique from point A to point B and the portal "looks" into the freight file to determine only those rates from point A. The user selects which freight to use and clicks on the ID which then places the following into the tab: The freight, The Desitation and Unique ID.

The user then selects the other information from drop down menus or direct input. When all the "rows" that he needs are input an "update" button is clicked and the data is computed. This was all previously done by using a calculator and would take a lot longer to do.

If there is still an easier way to do this I would be interested.

[Søren Dyhr]

Each tab is for one item which is computed into a delieverd cost for up to 8 different desitinations

Which then is eyeballed - or?? Wouldn't it just give 24 destinations, and what does the scripted tabcontrol do in this case? It seems like you for each chosen peice of equipment fill in cells with data looping it's way thru 192 fields??

--sd

[BAAIII]

Data only goes into one row at a time. Up to 8 rows per tab. This is one origin point to multiple destinations. If the user has another "grade or item" for multiple locations then he would use another tab. He can have up to three multiple calculations per record. The 4th tab is single point A to Single point B for 10 different "items"

The Portal to row was just to fill in any open ID on a specific tab. I needed to know which tab I was working with and then find an empty ID field. If none exist the user is informed that he will need to delete an ID in order to add additional.

[comment]

A sample file - perhaps a simplified one - could be useful here. I have no idea what you mean by "row". Filemaker does not have rows (unless you mean records). It is also not clear if your file is a database (i.e. record-keeper) or a calculator.

[Søren Dyhr]

It is also not clear if your file is a database (i.e. record-keeper) or a calculator.

Indeed it's what nagging me, if it's the layout that matters - might Runtime Revolution or Facespan be a more likely tools, or if the calc's as such is focus might a spreadsheet be more obivous. There is a danger if you tries to pull a database tool out of it's realm that expresions like "...severe omission" etc. starts to show up.

What is it you expect from the tool, since everything looks like a nail, if what you have in your hand is a hammer!

Data only goes into one row at a time.

This seems unhealthy, data shall not be ushered around, but instead be made to appeare somewhere by a reference only!

--sd

[BAAIII]

It is both a data base and a calculator,of sorts. The DB is used in Brokerage and each record is an account. Each account is located in various cities throughout the US. The material that is purchased is generally produced by the account and falls into 10 to 15 different catagories.

The material is sent to different locations, on a monthly basis, depending on pricing. The calculation is used to determined the cost of a specific material delivered to different customers. The freight plays a very important part of the calculation as does the type equipment used to ship the item. Some equipment is privately owned and some is owned by the RR. They carry different rates to the same destination. Depending on the amount of material loaded in the equipment the cost of freight, per unit, can vary by quite a bit.

Due to supply and demand products can move to different locations each month. The DB contains specific information about the account which includes the usual name, rank and serial number. All the information for the user is contained on one page with the 4 tabs.

Example: You make widgets and you want to get $5 for them FOB your door. Pete says he will pay you $10 delivered to his location while Fred says he will pay you $15 delivered to his. Which deal is the best for you? Until you know what it cost to ship to Pete and Fred you can't tell.

Let's say you can ship to Pete for $4 and to Fred for $11. If your freight is complicated, and ours is, then you need a way to handle this quickly. In the example you sell Pete because you will get $6 for your product from him while Fred is only willing to pay you $4 FOB your door.

In our situation you could have this calculation for numerous destinations (Pete, Fred, Bill, Joe etc.). Is this getting any clearer?

PS. I said earlier the fields on each tab are 8 rows by 8 columns.

Edited December 19, 2006 by Guest

[Søren Dyhr]

Is this getting any clearer?

Although it gives the deployment scenario, is it instead your methods to get there that makes us wonder ...how does this employ the grid of fields and the tabbed layouts - if it weren't for eyeballing in the the end anyway.

What we want to do to keep this task inside the database realm is making a querry to establish which deal is the best, by entering the various bidders prices and the items dimentions and weight somewhere and perhaps get a portal ranking the options with the best deal in the first row of a portal with very little scrutinizable detail to prevent the user being in doubt.

If you won't let us see a template, could you perhaps paste in a snappy of your scripting ...since it most likely are here you're giving yourself away with a less than optimal database structure. Long scripting is a sign of iadequate structure ...usually!

--sd

[comment]

Is this getting any clearer?

Not by much. But there are a couple of things that I can say with some certainty:

1.

How you arrange your fields on a layout is completely meaningless. Filemaker does not care if you placed them in rows and columns, or in a hexagon. They are still just a bunch of fields on a layout.

2.

In your example, I would have a record in a table of Products(?) that says I have a certain quantity of widgets for sale. The offers from Pete and Fred would be two separate records in another table, related to the product by ProductID.

The revenue from an offer would be calculated in the Offers table, using data from the offer and from the parent record in Products (and possibly from other tables, such as Locations, Fuel Costs and whatever else may be required).

A portal to Offers on a layout of Products would show the offers made on the current product, together with the calculation results.

[BAAIII]

Here is a screen shot.

Screen_Shot.pdf

[Søren Dyhr]

No I would like to see the script, the screenshot was close to what i could imagine ...it's the way the data really needs the scripted access to the particular tab, that makes me wonder?

They are still just a bunch of fields on a layout.

Exactly and what makes it a database centric task to perform? Why isn't the the fields structured beyond their position in one particular tab??

I would assume that the matters debated in this thread:

http://fmforums.com/forum/showtopic.php?tid/182688/post/231686/hl//

...carries a lot in common with this apparent scripting obsession, although I in that thread would know of a quick and reliable way to do it, if it weren't for a poorly thought structure, why do you think Genx is asking if you're using repeating fields?

--sd

[BAAIII]

(( - might Runtime Revolution or Facespan)) I guess I don't understand what you are saying other than you think my DB sucks. It doesn't work for Excel and I can't program for Windoze. I could write the entire program in SuperCard but it seems to do what I want using FileMaker. The freight DB is in FM and so when I thought about trying to use it I automatically felt that it would work in FM.

The fields are just fields and I used the terminology of 8 rows by 8 columns to try and give a visual. Perhaps I should have phrased it differently.

((Why isn't the the fields structured beyond their position in one particular tab??)) I don't know what you mean.

I am not using repeating fields. ((...it's the way the data really needs the scripted access to the particular tab, that makes me wonder?)) All the fields on each tab are Unique. Why is that such a problem?

COMMENT Your 2. would not work because the business is not structured that way. The sheet is designed for the producer not the consumer. It is the cost of his goods delivered to other markets which drives the calculations.

[comment]

This doesn't seem to be going anywhere. I made a suggestion based on your example. That's about all the information you gave us. If the business is not structured that way, then I don't know.

[Søren Dyhr]

I could write the entire program in SuperCard but it seems to do what I want using FileMaker.

I felt I knew you were trying to pull filemaker out of it's realm, Supercard, Hypercard or Runtime Revolution are all dialects of the way to approach matters - being GUI toolkits ONLY.

All the fields on each tab are Unique. Why is that such a problem?

Thier similarities!!! ...and only slight deviation from the raw data listed in the portal ...the measures to usher COPIES of the same data to various spaces is hardly normalized ...what you send to your unique fields is actually subsets of data, which is morphed slightly by other relational data.

--sd