Necarie Posted December 7, 2010 Posted December 7, 2010 I'm redesigning a database solution that uses Filemaker like a page layout program. The focus is how pages appear when they are printed, and because the information in the database varies so much, people are constantly required to change font sizes and sometimes field positions. The current solution uses one popup window for data entry and a second window for the preview (and by preview, I don't mean Filemaker's preview mode, but the display of the data entry on a graphical layout in browse mode). Right now, changing something in one window requires closing the other, and it feels constricted and awkward. I was asked to make editing between these screens more convenient and have the data entry in the same window as the page preview. Since Filemaker doesn't seem to have features to allow me to put the data entry box in an include or frame, I have to copy/paste the data entry box onto every layout each time I make any adjustment. There are a dozen layouts at the moment for various page sizes, but to make matters worse, some of these layouts are for tabloid/poster size pages which have to be viewed zoomed out so they fit on the screen. On the zoomed out layouts, I use an extra large data entry box and change the object pixel sizes/fonts to give the illusion that the data entry box is in the same place. It's a little blurry, but it works. I did try out an alternative dual window view that attempted to open both layouts in windows side-by-side and keep the record navigation synchronized, but it did not feel user-friendly due to the window alignment and focus. My question is, can anyone think of a better way to do this? This seems a lot better than the original on the user's end, but is very time consuming on the developer's end and may only get worse as I may eventually have a lot more layouts than I do now. I'm using FileMaker Pro 10 Advanced, and I'm developing on both a Mac and a Windows. I'm still pretty new to Filemaker development.
Genx Posted December 8, 2010 Posted December 8, 2010 Really confused... can we have a screenshot or something?
Vaughan Posted December 8, 2010 Posted December 8, 2010 So you want a print preview next to the data entry fields? Use the Save as PDF step to put the pdf in the temp folder and preview the pdf in a web viewer. (This is a bit more complicated than first appears because the current layout is NOT the one that will be printed, since it has the web viewer onit!) I'd manually update the pdf preview: IOW the user clicks an "update preview" button after their edits are done. It may be possible to make it more dynamic but the performance hit of saving to pdf and previewing it after every field modification or record commit needs to be determined.
dansmith65 Posted December 8, 2010 Posted December 8, 2010 I'm pretty confused as well, but would a tab control help? One tab for data entry, another tab for preview.
Necarie Posted December 10, 2010 Author Posted December 10, 2010 Sorry my post was confusing. Unfortunately, I can't post screenshots because of company policies, but I created some very simplified and generic graphics that I hope will explain how I am using FileMaker. Please keep in mind these are just to give an idea with fake fields/layouts/graphics; the real one is more complicated. I'm not sure if the reason I need it like this makes sense to others - the preview needs to be visible all the time because it is used like a graphic layout program that requires a large database and calculations (which is why it's in filemaker instead of indesign, quark or illustrator). Changes to the text formatting and graphics are frequent. So if someone needs to tweak something and constantly needs to update a preview window manually each time or go through tabs to see their change, then keep flipping back and forth when it doesn't quite look right, it becomes annoying and takes a lot more time than it should. This is the current implementation: The preview window shows and is synced, but it's locked. Switching between windows requires closing the other window and reopening it when you go back. Many of the functions require alternating between windows and frequent opening and closing. My employer does not like this and wants the data entry in one window. So I made this: Employer likes it, and it requires less steps when editing is required for the end user. However, since I can't make it work like an include where I make a single data entry box and reference it in each layout (at least according to my research), I am pasting the data entry box on every layout manually. That was fine at first, but it's not practical when there will eventually be hundreds of layouts. My compromise is a dual layout with the data entry appearing as some kind of popup, but I need to synchronize the windows so the records always match between windows without locking either window from the user. It needs to be two windows so I don't have to paste the data entry into each layout everytime there is even a minor change, but it needs to have the "feel" of being one window. This is the script I'm using to synchronize the windows: Set Variable [$current; Value:Get ( RecordID )] Select Window [Name: “Preview” ; Current file] Show All Records Freeze Window If [Get ( RecordID ) != $current] Loop Go to Record/Request/Page [Next; Exit after last] Exit Loop if [Get ( RecordID ) = $current] End Loop End If If [Get ( RecordID ) != $current] Loop Go to Record/Request/Page [Previous; Exit after last] Exit Loop if [Get ( RecordID ) = $current] End Loop End If Select Window [Name: “Data Entry”; Current file] The script works, but I don't feel satisfied with it. I'm not sure if it's a limitation of Filemaker or my knowledge of its abilities. I'm just looking for feedback on how I am doing this and if anyone knows of any better or more efficient methods. Also, could anyone point me in the right direction about getting all windows in the file to close if one is closed?
comment Posted December 10, 2010 Posted December 10, 2010 it's not practical when there will eventually be hundreds of layouts. Couldn't you have one (Filemaker) layout, with the different (graphical) layouts being on tabs?
Necarie Posted December 10, 2010 Author Posted December 10, 2010 You mean the data entry box being on the layout, with a tab box next to it containing the various layouts? That might work if tab switching can be used in calculations/scripts. I have several scripts set up to determine which layout to use for a record without requiring the user to navigate to it manually - can I do that with tabs? Another issue I'm seeing is the tab box itself would have to be an non-printing object, but making it non-printing makes everything on it non-printing. The layouts are based on size, not content (I use global fields and calculations for changing graphics and calculations determine field placement), so the tab would have to be invisible and allow the fields on it to slide properly when printing. Some records will be a couple of inches and others will be poster size. Thanks for the ideas so far, and I hope I'm not misunderstanding too badly.
Genx Posted December 11, 2010 Posted December 11, 2010 Another issue I'm seeing is the tab box itself would have to be an non-printing object, but making it non-printing makes everything on it non-printing. The layouts are based on size, not content (I use global fields and calculations for changing graphics and calculations determine field placement), so the tab would have to be invisible and allow the fields on it to slide properly when printing. Some records will be a couple of inches and others will be poster size. You can set the tab background to white (or whatever your background color is) and resize the tabs them selves to a pixel size of 0 - makes them effectively invisible.
comment Posted December 11, 2010 Posted December 11, 2010 I have several scripts set up to determine which layout to use for a record without requiring the user to navigate to it manually - can I do that with tabs? Yes, provided you assign an object name to each tab. Then you can use Go to Object[] to select the tab. Another option would be to duplicate an existing layout instead of starting a new one from scratch. Syncing the two windows could be simple - IF you can be sure that both windows have the same found set. Otherwise you must loop as your script shows - although I believe this too could be simpler: Set Variable [$current; Get (RecordID)] Select Window [Name: “Preview” ; Current file] Show All Records Go to Record [First] Loop Exit Loop If [Get (RecordID) = $current] Go to Record [Next; Exit after last] End Loop Select Window [Name: “Data Entry”; Current file] But I would agree with your employer that keeping it all in one window is best.
Necarie Posted December 11, 2010 Author Posted December 11, 2010 You can set the tab background to white (or whatever your background color is) and resize the tabs them selves to a pixel size of 0 - makes them effectively invisible. It makes them invisible on the screen, but not to the printer. If I have to make the tab large enough to accommodate a piece of paper that is, for example, 18x24 inches and I can't set the tab background as a non-printing object, then the 2x3 inch card in the next tab will also print as if it needs all 18x24 inches; I won't be able to set up sliding based on non-printing objects to get multiple cards per page. There are similar issues with the widely varying page sizes and the zoom - some layouts need to be viewed at 50% or 75% so they'll fit on the screen, while most will be viewed at 100%. I can make a layout automatically zoom out easily enough, but this also causes the data entry box to become tiny. Yes, provided you assign an object name to each tab. Then you can use Go to Object[] to select the tab. Good to know even if the tab layout doesn't work for this project. Another option would be to duplicate an existing layout instead of starting a new one from scratch. You mean every time I need to edit a field in the data entry section to delete all my layouts and duplicate them all back from one, or are you talking about something else? Syncing the two windows could be simple - IF you can be sure that both windows have the same found set. Otherwise you must loop as your script shows - although I believe this too could be simpler: Set Variable [$current; Get (RecordID)] Select Window [Name: “Preview” ; Current file] Show All Records Go to Record [First] Loop Exit Loop If [Get (RecordID) = $current] Go to Record [Next; Exit after last] End Loop Select Window [Name: “Data Entry”; Current file] But I would agree with your employer that keeping it all in one window is best. Without "Freeze Window", the window flickers as the script runs and it seems slower. "Freeze Window" makes it look like it is happening instantly instead of processing something. It's a small detail and not essential to functionality, but gives it a bit more of a polished feel when using it. Anyway, this script looks like an improvement and I'll test it in my file tomorrow to see how it looks. Thanks.
comment Posted December 11, 2010 Posted December 11, 2010 You mean every time I need to edit a field in the data entry section to delete all my layouts and duplicate them all back from one, or are you talking about something else? There is something fundamentally wrong here, and I can't (yet) put my finger on it. How often do you anticipate making such changes? And if you do make a change, shouldn't it be propagated to the layout section as well - in all existing layouts? One gets the uneasy feeling that you intend to make changes to both layouts AND data structure as part of the normal workflow. This is not something to be recommended. Perhaps you should elaborate more on the purpose of this solution (and why aren't you using a page layout application for page layout).
Necarie Posted December 11, 2010 Author Posted December 11, 2010 There is something fundamentally wrong here, and I can't (yet) put my finger on it. How often do you anticipate making such changes? And if you do make a change, shouldn't it be propagated to the layout section as well - in all existing layouts? One gets the uneasy feeling that you intend to make changes to both layouts AND data structure as part of the normal workflow. This is not something to be recommended. How I'd like to make such changes is to be able to edit the data entry box on one layout and have that automatically appear updated on the rest of the layouts. If I can't do that (and I'm getting the feeling there is no "good" way to do it in filemaker), I am seeing how good I can make a graphical preview window with a popup data entry field look and function. Even with the current method of having the data entry in the same window as the preview, I only need to copy/paste the data entry section to the other layouts when it's updated, and make sure it lines up using the object info panel. There is no need to touch the data structure when one does this. It actually isn't a big deal to update now, with only a dozen layouts, but it will become to impractical to stick with this as more layouts are added. Perhaps you should elaborate more on the purpose of this solution (and why aren't you using a page layout application for page layout). It's basically an automated layout program that creates signs and other marketing material. There are hundreds of thousands of products that could be records (not that they are in the same database at the same time as they tend to get wiped periodically). The data that populates it is not compiled by the same people who print it - it is sent in via excel sheets or web forms and imported into filemaker. The people who print it also do not do the designs or graphics in the program - those are also sent and imported. In addition to needing to be imported from spreadsheets, it needs to be able to perform calculations. It can calculate savings from promotional prices, scan recipes and display the appropriate allergen warnings, convert unit sizes automatically, and so on. In an ideal situation, all the printer has to do is import the records, scroll through them to make sure they are displaying correctly, and click print. Unfortunately, the text lengths that populate the fields vary so much that it is often required to adjust the text size (which is the main reason to have the always visible preview), sometimes stuff is missing or there are other mistakes made by the people sending the information, and sometimes the layout elements themselves need to be tweaked a bit.
comment Posted December 11, 2010 Posted December 11, 2010 edit the data entry box on one layout and have that automatically appear updated on the rest of the layouts. If by "edit the data entry box" you mean modify it in Layout mode, then no - there is no "good way" to propagate the change to other (existing) layouts. However, I am still not sure of the nature of such changes and their frequency. Perhaps you only need to add more parameters to the data entry section, and shift the modifications - as much as possible - from the layout level into the data layer. For example, text size can be easily controlled by entering the desired size into a field. 1
Recommended Posts
This topic is 5095 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 accountSign in
Already have an account? Sign in here.
Sign In Now