Custom Zoom value?

[benwiggy]

Sorry if this isn't quite the right forum for it, but is there any way to specify a custom zoom value?

300% is just a little too big, and 200% is a little too small, so 250 or 275 would be great, but there doesn't seem to be an obvious way of doing this.

[bcooney]

You cannot specify custom zoom values.

[benwiggy]

Appalling.

For a very expensive application, there is a lot of basic functions that FM lacks.

[Vaughan]

Appalling. For a very expensive application, there is a lot of basic functions that FM lacks.

Absolutely.

I just built a database for a client that helps them manage their client accounts, and it has recouped an extra about $10,000 a month in income that was previously being unclaimed.

Do you think they care it cannot zoom to custom values?

If you think FMP is expensive, try pricing Oracle or MsSQL.

[comment]

300% is just a little too big, and 200% is a little too small

Perhaps it would be best to design a layout that looks right at 100%.

[benwiggy]

Perhaps it would be best to design a layout that looks right at 100%.

Ah. I'm using it wrong.

I've designed the layout to fit an A4 page. Surely not an uncommon method? At 100% on a 20 inch monitor, this is tiny. 200% is not bad, and 300% is just slightly larger than the width of the screen.

300% would be fine, except that for some reason, I get scrolling artefacts ("redraw judder") when I scroll up and down the page.

Doesn't happen at any other resolution, even if using a smaller window.

[Vaughan]

I've designed the layout to fit an A4 page. Surely not an uncommon method?

Print layouts should be designed to fit the page. Screen layouts should be designed to fit the screen. Script the print processes so the print layouts get printed.***

Put some thought into the size you'll designing the screen layouts. It's tempting to design BIG but in fact that ends in tears after it's realised that the developer has a 24 inch monitor while everybody else has 15 inch laptops.

Instead, design for the *smallest* screen that the system will be used on -- I size it to be very tight on a 13 inch laptops which is something like 1300x800 pixels (screen size differs between PCs and Macs so do your homework).

I strongly recommend developing a template to get the size right. Open FMP and create a file, put a rectangle on the layout so that in browse mode the window will just fit on the monitor without displaying scroll bars. Do it on the Mac and on a PC. On Mac OS X do this with the Dock visible and at the bottom, and another at the side of the screen. In Windows so it with the task bar in the default position at the bottom and another at the side of the screen. Do it with FMP's status tool bar displayed. Note that the size will differ between WIndows XP and Windows 7 (and possibly Vista).

If you want to be exhaustive you can have a separate layout for each variation. There will be many.

You'll notice that the size of the rectangle will be different between Mac and PC: one rectangle will be slightly wider and the other will be slightly taller. For your final screen design, size the rectangle so that it's the *smallest* of the dimensions, that way the solution will work cross platform. When designing your screen layouts, stick to this rectangle. If you have more elements that will fit then use tab controls to group and display the data. Remember that the auto-size feature will allow the objects to grow in size when the window is made bigger by the user, so that people with larger monitors can take advantage of their screen real estate.

Now work out what the text size should be for the fields and the field labels, the colours etc, etc, etc for form view and list view (and table view if developing for this: I do not). It's much easier to get this stuff sorted out at the beginning. It's easy to tell those who haven't done the forward planning: they complain about how hard FMP is to change the formatting of hundreds of fields on hundreds of layouts and lament the lack of "master" layouts etc. Good planning will avoid the necessity for such contrivances.

If you really, really want a separate design for small and large monitors then by all means, design 2 layouts for everything. But it's a lot of work and it doubles the maintenance overhead.

The zoom feature is basically a legacy feature form ye olde days. IMHO leave it set to 100% and forget about it. Let the user change it if they want, but don't develop with your interface's usability depending on it.

*** When I started developing with FMP, I dreamed of having a screen big enough to display a whole page at once.

[comment]

I've designed the layout to fit an A4 page. Surely not an uncommon method?

It depends on what you are doing. A layout should fit a physical page if it's designed for printing. For such layout, you'd probably use 150% or 200% to check the text, and 300% or 400% for graphic detail. This refers to checking the output in Preview mode - using zoom in Browse mode is not something you'd want to do on a regular basis.

[benwiggy]

I had assumed (wrongly, it seems), that one layout would be sufficient, using Browse for ... browsing and entering data on screen and using Preview as a ... preview for printing.

But you are suggesting that I create separate layouts for screen and print. OK, fair enough, but it does seem like a slight duplication of labour.

What is the reason for not using Zoom in Browse mode..?

And what is Preview mode for, if not for showing a print-ready version of the current layout?

I am the only user of the database, so no worries about catering for other platforms and monitors.

[comment]

Again, it depends on what exactly you are doing - but in general, the chances that the same layout would be both suitable for printing and comfortable for screen viewing and data entry are pretty slim. It's not only about size: there are elements like buttons, tab controls and portals that do not belong on a print layout, and stuff like headers, logos, page numbers that you don't want cluttering your browsing layout. Also in terms of usability, a screen layout should be optimized to assist the workflow, while a print layout is designed to convey the data as efficiently as possible.