Banging my head against the side of the layout!!!

[mluka]

Hi, all.

What a weird "problem"!

I need to put two merge fields next to each other, inside the same "field", right-aligned, for display on a layout. I want them to display in the left-hand third of the layout.

The problem is that <><> is so long that I can't slide it into position: it bumps into the left edge of the layout!

If I try to resize the whole gizmo, FM re-extends it towards the bottom which results in the "field" being 3 or 4 lines high, which is not what I want at all...

Any suggestions?

Thanks!

[LaRetta]

If your chevron is <>, you can make everything but the first chevron 3 pt font and it will still display the proper font size based upon what font the FIRST chevron is. So highlight all but the first chevron and change font to something very small so it all fits. This trick isn't documented anywhere that I'm aware of ...

Update: I realized that, with 2 merge fields, you might not recognize that each much be treated independently. So the chevrons below in blue should NOT be resized very small but the rest can be:

[color:blue]<>[color:blue]<>

If you have spaces between the two fields, the spaces must be blue as well (left full sized).

Edited June 27, 2006 by Guest

[mluka]

Hi, laRetta. Thanks for the response.

You're right! It works!

Although, in view of the fact that it IS "undocumented", who knows how long it's going to work? The powers that be might someday decide that it's a bug and "correct it" and break the solution... (Sigh...)

I also did something else: I reduced the size of the TO name to just 2 characters. I hate doing this because it makes everything more cryptic, but...

[but I must say that I'm somewhat disconcerted, as I'm building this solution, at the number of "tricks" that have to be used to make FM do fairly simple things (all in the interface area) piling up fields one on top of the other to control what displays; putting unnecessary fields on tab-control panels to be able to select them, etc. Bah... at least the database part seems to work OK!]

Thanks for your tip!

[LaRetta]

Are you a Developer? Are you looking for a program which will expand and flex as your business requires it? Or do you instead wish to spend four years learning Access which will dead-end on you? Or maybe you want a fully-assembled pseudo-program which fools the purchaser into think they are actually designing, when in fact the structure is already pre-determined and the joke is on you?

If you want something fully assembled, FileMaker is not for you. Manipulating the program is what Developers DO. It combines an easy learning curve with power and flexibility. It doesn't get any better than that.

UPDATE: All of the things you mentioned only point that you have aptly rated yourself. Nothing wrong with that. But don't judge the program by what you don't understand yet. You will love the ride once you begin figuring it out.

LaRetta

Edited June 27, 2006 by Guest
Added update

[mluka]

Hi, LaRetta. Thanks for your comments.

I don't want to start a long thread (in the wrong forum, yet), but let me address a few of your points.

I'm not a commercial developer. I own a business, have used (mostly as a user, a few times as a developer of internal systems) FM since about 1986 and was in IT for about 30 years before buying this business (in dry-cleaning) a few years ago.

If you want something fully assembled, FileMaker is not for you.

We already have a fully assembled solution, based on an archaic database.

It supports all our counter functions: receiving an order, keeping track of it in production, printing tickets, receiving payments, generating accounting transactions, tracking inventory of supplies, printing reports, etc. This solution already uses: touchscreens, barcode scanners, thermal coupon printers, cash drawers. It runs on a network and supports multiple users. I mean, it's using those and they're working well. It doesn't require a keyboard nor a mouse. I can train a new counter person (experienced in the dry-cleaning environment but not necessarily with computers) to the point where they can handle 95% of transactions, in about one hour.

But I can't modify it, the developer is unavailable and the solution has enough features that I don't like and is missing enough features that I want that I've decided to replace it with our own.

I picked FM because: some resources were available, FM is finally relational, it has fairly easy tab-controls, it can supposedly run in kiosk mode in a multi-user environment (contrary to what a FMI support person told me), it can now support a decent "separation model" (the same support person didn't have a clue what I was talking about, put me on hold for 10 minutes to consult someone else and then told me "no one had heard of this"...) and it's available on Mac and PC platforms (development is on Macs and use will be on the PCs which are already installed).

But I hesitated for a while, because I suspected we'd have some problems with the interface (the interaction with the user) and some of the equipment (printers, specifically). But all in all, I figured there were enough benefits of going with FM and, as you said so well, not having four years to learn Access (or something else, more likely), decided to go ahead with FM.

I'm not saying it was a wrong decision. But the problems have materialized. On occasion, I've had to modify the design of some function, either because FM couldn't give me what I had designed, or I could tell that it would be sufficiently complicated that I didn't want to invest the extra time and run the risk of hitting a wall after a significant investment of time.

On several occasions, I was able to find workarounds to seemingly simple problems. But usually at a cost of several hours of research, trial and error, etc. Thank God I was able to draw on the resources of the forum for this. You (and several other forum members) have saved me countless hours of needlessly wasted time and I thank you for this.

A few times, I've made compromises that only the owner could make. Printing is one example: the Epson (TM-T88III, a standard of many point-of-sale applications) has its own native fonts. If you use them, printing is very fast. If you don't, printing is very slow. How slow? Four times as slow. Which means that for each transaction, printing of the tickets will go from 4 seconds to 12 seconds.

I know, I know, eight seconds is not the end of the world. But it's a pain. Especially since what we're currently experiencing is four seconds! (BTW I've decided to multiply the number of printers by 2: for each workstation, one printer to print the customer ticket, while another printer prints our ticket. But I'd hate to be an IT person telling his customer "Well... because the program I use can't print fast, you'll just have to buy twice as many printers!")

(Why on Earth FM wants to manage fonts itself is beyond me. Windows XP and OS X already do this very well. FM should use the operating system's facilities, like 99% of applications do).

Enough said (for the time being). When the project is complete and the solution installed, I'll take the time to post my detailed comments (in the appropriate forum).

But thanks for your comments: I appreciate them. And your help!

[Søren Dyhr]

(Why on Earth FM wants to manage fonts itself is beyond me. Windows XP and OS X already do this very well. FM should use the operating system's facilities, like 99% of applications do)

While not knowing it for sure, would I guess that it has to do with the scaling in % of the layout, not being somehing similar to a standard measure in cicero, and secondly that in network are you much better off with sending vectorized data than the actual pixeled image that then have to be de-jaggied afterward. Vectorized layout scales freely!

--sd

[Genx]

..Regarding the printing of two dockets, which im assuming are duplicates, shouldn't you just use carbon copy paper?

~Genx

[mluka]

Hi, GenX; thanks for the response.

...which im assuming are duplicates...

No, they don't contain exactly the same information.

And I don't think you could use multipart paper in a thermal printer (that I know of). And the thermal printers are much more versatile in terms of what can be printed (logo, large characters, etc.)

Thanks anyway!

[LaRetta]

I believe you are correct, mluka. We still have a dot matrix for some required 'impact' forms. I wish someone would invent carbonless which doesn't require an impact printer. I also realize that this statement sounds strange because how could it work?

It sounds like you have your work cut out for you and it also sounds like you are quite up to the task. Yes, FileMaker can be frustrating but so can the love of our lives; we make allowances because they are well worth it and, as you aptly stated, the good outweighs the bad in abundance!

LaRetta