5 Replies Latest reply on Jun 13, 2011 10:29 AM by philmodjunk

    Making a Runtime App questions

    aammondd

      Title

      Making a Runtime App questions

      Post

      Ive been reading about creating Runtime Solutions FMP 11 Adv.

      And I think I get it but I was wondering if any of you experts out there have any tips  with reguard to doing this.

      My app is fairly small and self contained its not inteneded to be multi user.

      My areas of weakness in development are with Custom Menu sets and if it should run in Kisok mode or not.

      Basicly as my self training exercise in this area I build a little checkbook register database that incorporates a number of features that I have developed for my other ventures. I want to be able to give this app to my wife who handles the checkbook but doesnt have FM on her computer.

      Just looking for any suggestions. This app is not a UI/Data split solution. My other probably will be and are there issues with doing it this way?

      Any input is appreciated. 

       

        • 1. Re: Making a Runtime App questions
          philmodjunk

          I wouldn't use Kiosk mode unless I had a specific reason for doing so. Many of the menu items can be very useful to the database user.

          Likewise, I'd use custom menus sparingly and only if I can't get the results I need through other means such as using Access privileges to disable certain parts of the menu.

          Those are just very general preferences the needs of a specific project will be the main factor in what interface design decisions you make.

          It's a good idea to put a "prepare for import" script in any file you distribute. This script simply does a "Show all records" on each table in turn so that an import records action from an updated copy of your file will import all the records in the table. With such a script in place, new versions can be distributed that use a perform script call to perform this Prepare for Import script before importing records from the older copy in to the updated copy.

          Even with a split file solution, this is a useful script to put in place in your data file as you may still encounter the need to release an updated copy of the data file and then you still have to set up an import script in the new copy to pull in the data from older versions.

          • 2. Re: Making a Runtime App questions
            aammondd

            One of the things Ive done is created a more traditional records handling interface. I dont want the users to access much of what is in the menu structure nor the tradiional navigation buttons of a filemaker solution. (the book or the layout menu etc)

            • 3. Re: Making a Runtime App questions
              philmodjunk

              As I said, only if you have a reason for doing so. And this doesn't have to be an either or choice either. The passwords you define can limit menu options and you can also create and define custom menus. Each option has it's utility--it's just a matter of what you need to use to produce the interface you want

              • 4. Re: Making a Runtime App questions
                aammondd

                After playing with it some I dont think Kiosk is what I want.

                Im still a little week on the custom menu thing do you have an example Phil?

                I just need bare bones menus.

                Can I run export scripts in a runtime solution. I was reading that certain menu functions are not available.

                 

                 

                • 5. Re: Making a Runtime App questions
                  philmodjunk

                  They're pretty simple to work with. I can give you some hints, but you can probably open up a test file and play with it to figure this out--much like I did.

                  I converted a set of Filemaker 5.5 files to FMP 10 and then merged most of the single table files into a single file. The boss was used to using the window menu to jump from sub system to subsystem while working with these files. To keep him happy I used Manage Custom Menu to create a custom menu that added a new one called "Navigation" that lists the subsystems by name and which perform scripts to take him to the desired layout. I then used Layout setup to specify this new custom menu where needed throughout my system.

                  Since password controls limit employee access to these systems, that's all I needed to do. However, I've since figured out that I could have used Install Menu Set and have completely hidden this menu from view for limited access users just by checking the current user's privilege set name and installing the default menu set for the limited access users.

                  I also install custom menu sets on layouts that serve as small floating, modal dialogs via a new window or Go To Related Record script step. I change the Close window option to perform a script instead of just closing the window. That enables me to end the script with the Halt Script step to halt the paused infinite loop that I use to simulate modal behavior with my floating window, and this in turn enables the user to close the window by clicking the close control in the corner of the window. (This is something I learned from a post here by Mr. Vodka.)

                  You'll find that you have the option to mix/match/add/remove menu options to create great many different customized interfaces. Just keep in mind that if you remove a menu option, you also remove it's keyboard shortcut. If you remove delete records, for example, ctrl-E will no longer work as well, but a button that performs a script to delete the record still works.