Jump to content

Background


This topic is 5758 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

This topic is 5758 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.