Jump to content

jjjjp

Members
  • Content Count

    177
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jjjjp

  • Rank
    member

Profile Information

  • Title
    Program dirsctor
  • Industry
    University
  • Gender
    Male

FileMaker Experience

  • Skill Level
    Intermediate
  • FM Application
    13 Client

Platform Environment

  • OS Platform
    Mac
  • OS Version
    Sierra
  1. I have been using FM Pro on FM Server 13 since 2014 to organize a multi-college series of workshops with a handful of colleagues at other colleges in my university. The database is essential to our operation, but the number of users other than me needing to access it at any time is quite minimal. I must upgrade Server because my colleagues have upgraded to FM Pro 16 for a different, much larger operation that runs out of a different academic unit. FM Pro 16 isn't compatible with FM Server 13. Unfortunately, I can no longer easily purchase a standalone version of Server. The new cost of running Server is going to average to about 10 times the cost over the last four years. The rep at Filemaker suggested that I share some other unit's version of FM at my university. Is there an easy way to upload and download a database to the administrative console without needing to ask for direct access to the console? I will need to propose an arrangement that doesn't give me administrative access to other databases on the console. But I will also need to be able to replace the current version of my database at any time without having to call on somebody else with the necessary privileges. Perhaps there are scripts that do this for either Mac or Windows platforms? Or, even better, does FM Server offer a simple way of providing limited access?
  2. I completed the process of creating posters using conditional formatting and iterating on a set of global values (as discussed above). I ended up using 6 iterations. I ran into no unexpected issues. The basic idea was fairly straightforward to implement. Still, implementing this was a fair bit of work and quite complex at times. The real challenge was writing code to recognize patterns in the workshops in each series; preparing records that corresponded to the rows in tables (each pattern required a different strategy); and checking for irregularities. In all there were 8 layouts, or templates, corresponding to 5 basic patterns. Seven were for regular patterns, one for the case of no regular pattern at all. Were I to treat each series as irregular and create posters simply as lists of workshops, descriptors, and dates, this whole task would have been much simpler, but much less interesting. I ended up going with 6 iterations per field. There were edge cases that I felt made at least 6 necessary. One also wants enough gradation to limit possible white space. Wherever possible, I grouped multiple fields together. Typically, there were 5 groups per layout. That amounted to about 240 font sizes to set via conditional formatting. I think it was definitely the right decision to go with conditional formats rather than the other way we had discussed. It was quite easy this way to run through each iteration and see how everything looked in Preview mode. Thanks again for the excellent advice.
  3. Looks good. I completely missed the last instruction. It looks like I now have all options open. Thanks for getting me back on track.
  4. I tried to implement what I believe you are suggesting and wasn't successful, but I'm lagging far behind—in FM 13. I'm attaching a simple test database. If the layout that opens on launch (TestListViewWithGrid) properly resizes cells in FM 16 in Preview mode, then that will mean that my addition of line objects is correct and FM 13 hasn't solved the vertical-line problem. If cells aren't properly resized, then I must have gotten the vertical lines wrong. Please have a quick look if you can? TestListWithGrid.fmp12 I wish I were up-to-date on FM, but I must use what my colleagues all use as part of a licensing arrangement for a database with much wider use at my university. We may be moving up at the very least to 14 in the near future. I will plan to look into that. But the best solution right now is probably just not to worry about vertical lines. No lines definitely wouldn't work, but horizontal lines on their own work surprisingly well for tables. (See attached.) w+ poster 01 start to finish tue mid sep hor lines.docx
  5. I realized there would be a problem almost as soon as I got started, but much better to hit roadblocks early rather than late. For the tables in these posters, I will need solid borders. In the past, when I have used the resize feature in list view, I recall that I haven't used borders. That would have been for a good reason: the vertical borders will all extend differently depending on the amount of text. I'm attaching part of a PDF from a past layout that relied on resizing of cells, but I've added solid borders on two sides of each cell in an attempt to create a grid. One immediately sees the problem. Any ideas on how I might solve this? Otherwise I'm ready to accept, as Wim says, that some things FM just isn't set up to do. table border problem.pdftable border problem.pdf
  6. Will do. I could never have thought of this on my own, so thanks very much again.
  7. True, particularly as you say that font sizes must be integers. Yes, I'm starting to see how this works. I won't have to set scads of global variables this way, which would be a lot easier. So, say, four separate conditions in Conditional format, with conditions looking like SystemGlobal::Iteration = 1, SystemGlobal::Iteration = 2, etc. And then I choose the font under More Formatting . . . . Multiple conditions, then, all work separately, I take it. I have never used more than one condition. Out of curiosity: if more than one condition is satisfied, the lower one cancels out the higher if they conflict on a format? In the Script, I run through the 4 globals in a loop, and for each layout do a Preview, test for number of page, and then exit the loop if # pages is 1. That sounds like the better option.
  8. Is it? I would have thought it's an awful lot of work. Compared to what I was initially thinking, it will bring the task a lot closer to workable. I was assuming—don't know why—that text sizes needed to be set to integral values, and I hadn't thought of using calculations in the list. I'll think about this some more, but I'm never comfortable with solutions that may not cover all possible cases—that aren't airtight in theory. Also, I don't want the user fiddling with options, so ultimately it seems it's down to iterating and testing either way. Maybe I'm not fully understanding this solution, but running through a finite # of cases seems in some ways harder than scaling down a global value in a loop. I take your point, but Filemaker I know; OS-level automation or scripting, I don't. And the FM solution will guarantee that there's no work for users—no Word files to tweak after the fact, even if they are all prepared with no need to get involved in Mail Merge. Word, e.g., as far as I know, doesn't have something that uniformly scales down fonts, as Mac Pages does. Important thing is I'm now in a position to decide whether I'm up for the coding. Thanks for the ideas.
  9. That's a terrific solution. I assume I'd have to start with a largish value and iterate down, in a loop, till everything fits on a page? Is there a simple way (or any way) to know that I've run over a page? Will, e.g., Get ( WindowHeight ) take into account all of the scaling down all of the resizing of cells and rows? What I mean is doing something equivalent to Fit on Page or at least Scaling when printing from some browsers.
  10. Well, the nicest solution would be for all fonts to decrease more or less uniformly in size, but I imagine that would be a scripting nightmare. I would settle for reducing the scale of the image so that the vertical dimension no longer runs over a page. That might sometimes make for a skinny poster, but it would probably be acceptable.
  11. Thanks, using grand summary definitely solved the problem of the header not resizing. I agree that there's something to be said for using Word. In particular, one then has the option of tweaking font sizes, etc., to get everything on a page. For the other users, however, who don't necessarily have much experience with Mail Merge, it would be a plus to have all of the PDFs (fifteen or so of them in any given year for this application of the database) ready-made at the click of a button. So maybe it makes sense now to ask: is ensuring that everything gets on a page as problematic as it would seem to be? I want to dump all the files on the Desktop, without any intermediate intervention from the users.
  12. I'm trying to do something that is turning out to be much more difficult than I thought. I want to produce posters for series of workshops, one poster for each series. I have accomplished this in the past using Mail Merge in Word. To simplify somewhat: In FileMaker, I have a script that creates an Excel file, one row per poster. The data gets pasted automatically into fields in the appropriate Word file, and I can produce PDFs from there. Different types of series need their own word file, but there is a manageable number of possibilities. I am attaching examples of two typical posters. Here's the problem I seem to be having in arriving at a solution that occurs entirely in Filemaker. The poster has a top section consisting of information common to all workshops. The middle section is a table, one row per date. The bottom section consists of information common to all of the series. All three sections have variable length text, so they will need to take advantage of FM's ability to remove blank space by sliding up and resizing the enclosed parts. I've considered 3 options. All have problems: Create layouts that mimic the Word Mail Merge files. If I could get this option to work, it would be the easiest for me, because there would be the least change from how I now manage the posters. There would need to be a table in the middle section with borders. The table would have a fixed number of cells. The problem here is that there is no elegant way to create a functional Word-like table in Form View. I could improvise a table composed of individual cells, but the problem is that I would have no way of getting all the cells in a row to expand vertically to the same height. They would all have different amounts of text. Use a portal in the middle section. I would need to do a fair bit of work to create the necessary fields and relationships. But that part is do-able. The problem is that inside a portal, the cells just don't seem to be resizing even though I have set each cell and the portal row to do that. Use List View. For this option, I would create a Title Header and Title Footer, respectively, for the top and bottom sections. The problem here is that the Header appears to be vertically fixed. It doesn't shrink if not all the vertical space is needed. Going back to relying on Mail Merge is a definite option, but I thought I would give this a serious try. (Note that for now, I have put aside the question of getting long posters to print on one page.) w+ poster 02 essential skills sat mid sep.pdf w+ poster 02 essential skills sat mid sep.pdf w+ poster 01 start to finish tue mid sep.pdf
  13. It sounds, then, as though the problems were probably due to a bug, but with a very small possibility that the two databases were interfering with each other. Thanks for the responses.
  14. I'm not sure I understand the question completely, but here's more about the situation: The user ran his own copy of FM (13.0v9), which I recently helped him install, on his Mac, while I screen-shared from my Mac. The two databases were running remotely on separate servers at different locations on my university's network. The databases on the two servers were up to date and stable.
  15. I recently gave a demo of my FM software to a future user and ran into problems I never did before, problems that wouldn't have come up under normal circumstances: error messages from FM or a window that should have remained hidden replacing the window that should have remained on display. (I wasn't able to take screenshots or record details at the time.) I tried to reproduce the problem later but was not able to. It did strike me that the one thing unusual about the situation was that I was also demonstrating another completely separate database, written by somebody else, that the user would also be using in the future. My question is whether having two databases open at the same time can cause unexpected things to happen in one of them? Is it therefore consistent with best practices to operate only one FM database at the time? Or are there ways to write scripts, in particular to manage window, that can keep the database insulated? If two databases cannot interfere with each other, then I will have to assume that there is some hard-to-reproduce bug in my code.
×

Important Information

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