Background

[acantho]

Is it possible in Filemaker 5.5 to turn a custom patern into a background for a part?

I can change the colour but I don't seem to see an option to use a custom background

[stanley]

Acantho:

You can use any image (formats are an issue - I always use JPEGs) as a background (via Insert->Picture), but you'll have to manually resize it in an image editor to make sure it fits, and lay it into each layout individually. It can be a bit of a bother, but it can be well worth it as a way to spruce up the look of your system.

-Stanley

[acantho]

Thanks Stanley.

I am aware of that.

What I'm trying to do is have an image that tiles or similar as a background and that wouldn't be affected or affect the layout itself. ie. if I needed it to be on something like an invoice page that could technically be anywhere from 1 to 5 pages long.

I want the same background on each page but don't want it to always print 5 pages (which is what would happen if I inserted 5 images, one for each page).

[mr_vodka]

Why not use a global container field that you can have in the background and then set it to the image that you want at a certain point.

[acantho]

hmmmm

not quite fully following you but you started to get my brain thinking again.

Wouldn't a global container still cause the same problem as if it were just an image placed there?

The computer would still recognise that there's now something on all 5 pages (since that's what I used in my example previously).

Unless I somehow made it so that it only showed if something was on the page...

But then I'd still have the problem of items that might be sliding.

AND

I'd have problems with size of image and consistency.

[acantho]

Okay here's a different scenario involving a similar problem but with a completely different question.

What if I just wanted to make the background striped with two different colours of stripes?

Same criteria as previously posted.

Lets say the layout in browse mode is extremely long with about 50 line items/fields. If all items are filled it takes up 5 pages but they're all sliding up to remove any blanks that might happen.

The stripe background is for the body and each line item falls into a stripe (without making each field coloured cause that wouldn't help me solve the real problem LOL).

How can I make it so that the stripe background doesn't cause the layout to always print 5 pages when everything else has slid up to accomodate 2 pages?

Maybe if I figure this out, it will help with what I'm trying to accomplish.

Edited December 18, 2006 by Guest

[comment]

I am under the impression that your REAL problem lies elsewhere. It seems you have 50 line items in a single record. You should have your line items in a related file, where each item is a separate record. This is also the file you would use for printing. The body part of your printing layout would be only tall enough to print one line.

I don't know if version 5 allows for alternate background fill of a body part, but you could simulate this effect by placing a calculated container field on the layout, returning different backgrounds for odd/even records.

[acantho]

It's funny... I've had different people comment on the line items thing before.

But for what I'm doing, placing each line item into a separate file would have at least 50 different files. And/or would include about 7 times the data entry. That would also mean hiring at least 2 additional people to be able to do the work that one person can do currently AND would greatly increase the possibility of errors.

I think I see what you are trying to do with the calculated field but I don't need it for different records but for each different line item and though I can see it working... and I think it would work (would still have to test it) This would mean 50 different container fields. Hmmmmmm

Anybody else have any ideas cause I'm going to try it and come back to you.

[comment]

placing each line item into a separate file would have at least 50 different files

That is NOT what I suggested. There would be only ONE LineItems FILE. Each line item would be a RECORD in that file. The amount of data is the same - the only difference is the data structure.

[acantho]

Why would I do that though?

This is all data entered manually so all I'm seeing is added data entry with no change in result.

*shrug*

I just don't see the benefit

[comment]

Well, for starters, it would solve the problem that started this thread - and I suspect the problem in your other thread as well.

But that's just gravy. The real benefit of a proper data structure is the ability to retrieve data in a meaningful way. I don't think you will be able to produce a 'Sales By Product' report, for example, with your current structure.

EDIT: I have said before that the amount of data is the same - so there is no "added data entry". Let's not go in circles.

Edited December 19, 2006 by Guest

[acantho]

But there is added data entry... in my situation I don't need a common aspect to create the lookup.

In yours, that has to be added every entry (unless I'm not understanding you correctly) which is a lot of added data entry and makes for a large increase in possible errors.

I may not be understanding you correctly but it sounds similar to what I'm designing for another database. But for that one we get the data electronically for the most part so it would end up saving us time.

And no the other problem is a layout/page # thing which wouldn't matter where the data was coming from. the end result would be the same LOL.

Edit:

But seeing as how I have a short period of time to accomplish everything... I may wait to see if we're going to upgrade to FM8

Edited December 20, 2006 by Guest

[comment]

unless I'm not understanding you correctly

I am afraid that is the case. I would suggest you search for a basic invoicing demo and study it, but it may be difficult to find one for version 5.

[comment]

Here's an old demo (version 4) that you can convert.

Invoice_Demo_4.zip

[acantho]

Yeah I've gone over the file and I see where you're coming from.

I've been thinking about how it would work with what we're doing and I see some possibilities but with each one I see complications.

We already have many similar systems as you have set up but it's the lineitems that would really complicate things.

I could probably make it work using several different layouts to accomplish the necessary data entry.

I'll have to get back to you on this one everybody as it does look like it might give me the ability to do what I want.

Time to start the brain up again I guess. This is going to take some work.

[acantho]

Would you still use this type of system when the line items aren't necessarily all the same?

An example might be

payments

returns

orders

exchanges

but in different types of currencies. AND which might be billed to completely different people in completely different ways.

I realise this example is all money but I figured the different types of currencies might work for my question.

[comment]

I am not sure what payments, returns, orders and exchanges are, so it's difficult to answer yes or no. Let me instead suggest a rule-of-thumb: anytime you find yourself creating multiple fields of the same kind, for example:

PaymentAmount1

PaymentAmount2

PaymentAmount3

...

it's time to think of creating a new file to hold multiple related records (in this case Payments).

Payments in different currencies would usually be kept in the same file, and normalized to the "home currency" of the business, for example:

Date:

CustomerID:

Amount:

Currency:

Rate: (looked up from a Rate table)

cReceived = Amount * Rate

[acantho]

Okay.... here's a question.

What if

PaymentAmount1

PaymentAmount2

PaymentAmount3

is billed differently to different people or something like that.

They are the same type of transaction but the result of those transactions causes different reactions.

Would you then just use summaries to figure that out?

This probably makes no sense to anybody but me LOL

I hate when I get weird scenarios whirling around in my head that nobody can see but me :o

[comment]

As you guessed, there's not enough information here to provide an answer. One thing is certain: the transactions would NOT be recorded in a person's record; they would be in a related file. Whether they would ALL be in one related file, or split into several related files according to type, depends on whether they are more alike than different, or more different than alike (for the purposes of the solution).