1 2 3 4 Previous Next 50 Replies Latest reply on Jun 16, 2017 9:08 AM by beverly

    I've lost my Parent! - V16 - Win - MDI vs SDI


      I can't quite believe it - but FM have screwed me (and I think many others) - and I just need to rant and plead to FM to bring back MDI for Windows.


      Reference here: Single document interface support for FileMaker Pro for Windows | FileMaker


      I 'thought' that good db design was to have multiple databases - each doing their own specific job - and then link them all together for 1 big project.


      I did this and now have a very nice custom made CRM solution (done by me and one of the world's best FM developers, who I call on now and then to help with the heavy lifting - to be fair, I haven't been in touch with him for a year and so this just came up now when I tested V16).


      Now, I have about 5 databases - and all would be open and reside within the 1 single FM 'parent' window. They would be full screen *within* the FileMaker application. So, when I hit a button to switch between different dbs' - the screen would just switch easily and nicely to the other database. This then 'looks' like there is no difference when working with one database or another - it's just the one solution - all neat and tidy.


      I will add, most people now have multiple or large (or multiple & large) monitors. So, they have many different applications open at once. So, is the case for FM. FM just lives on one of my many monitors, and the application itself is not even full screen on any particular monitor.


      This has now all changed and is terrible with SDI with V16 for Windows.


      This change means that I have 1 distinct window for each and every individual database. It breaks the 'good' design of database management (or was as I thought good design). If I try to switch between databases, I now have to hunt which window I'm in and it's terrible. I know this is what Mac users have had for many years (and I understand from my developer that many FM users wanted this SDI) - but, Please FM - if you make such a radical change, can't you have *BOTH* options - MDI and SDI? Please!


      The end result for me is that I would need to do either of the following:


      - Dump FM (don't want to after so many years and so much development)

      - Completely redesign my project to include ALL databases into 1 single Database. Huge work to recreate all the relationships etc. And is bad design.

      - Work with calculations and screen control within FM to try to layer each window on top of eachother. This looks like the best workaround solution at present.


      Now, this is NOT a problem if FM16 is run at Full Screen. Each database is shown as it should and just switches nicely between eachother. But again, most of us have big and multiple monitors so this is not an option.


      I just can't understand FM breaking something that (to me) wasn't broken - and was fundamental to the product that has been shipping (on Win) since Day 1. And with no option to continue as it was in the past.


      So, this is just a rant post and a plea to FM (since you can't actually call them on the phone to complain [no one ever answers] - yet they are always calling you to get you to renew their Maintenance). Plus, I wanted to gauge if there was any interest from others (as I couldn't find any complaints so far).


      I hope I've described the situation clearly enough.


      (I’ve been using FM since 1990 – but for this project for about 5 years).

        • 1. Re: I've lost my Parent! - V16 - Win - MDI vs SDI
          Paul Jansen

          I do understand your pain.  I also have solutions that are affected as yours.  However I am one who has been asking for SDI since 2004.  Whilst there is pain in the short term, I believe the benefits of having consistent cross platform behaviour is good.  Also the ability to put database windows on separate monitors is also highly desirable in my opinion.  The fact is that SDI on Windows PCs is here to stay and we must find ways to deal with it.  Fortunately, I don't think it is too difficult to accommodate the loss of the application window.


          For the transition and for solutions that use maximised database windows inside the application window, I have two scripts to help. The first is used in any script that initiates a switch to another window.


          Script: Hide This Window


          #Use the next 2 steps in any scripts that call another file BEFORE the call to the external script

          // #Hide this window when navigating to a different file

          // Perform Script [ “Hide This Window” ]

          #Main Script functionality

          If [ IsEmpty( Get(ScriptParameter)) ]
          Install OnTimer Script [ “Hide This Window”; "Hide"; Interval: .1 ]


            Install OnTimer Script [ “Hide This Window”; "Hide"; Interval: 0 ]

            Adjust Window [ Hide ]

          End If


          The second script 'intelligently' resizes the database windows which would previously have been maximised within the application.  i have called this in my navigation scripts to ensure each layout is sized appropriately.


          Script: Size Window


          If [ IsMac or Int( GetAsNumber( Get(ApplicationVersion) )) 16 ]

            If [ Get(LayoutViewState) = 0 ]

              #If Form View just resize to fit

              Adjust Window [ Resize to Fit ]


              #If List View we need to be clever - so only adjust width not height

              Set Variable [ $height; Value:Get(WindowHeight) ]

              Freeze Window

              View As [ View as Form ]

              Adjust Window [ Resize to Fit ]

              View As [ View as List ]
          Move/Resize Window [ Current Window; Height: $height; Width: Get(WindowWidth) + 3 ]

              Refresh Window

            End If

          Else If [ IsPC ]

            Adjust Window [ Maximize ]

          End If


          Two custom functions are used:


          IsMac = If ( Abs (Get ( SystemPlatform ))= 1 ; 1 )

          IsPC = If ( Abs (Get ( SystemPlatform ))= 2 ; 1 )


          Hopefully these will give you an idea of how you might address the issues within your own solution.




          • 2. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

            Thanks very much.


            I'll review with my developer.


            I have been surprised that I couldn't find any other discussion about this.


            Am I right (wrong?) with my thinking of how 'good' db design should be?

            • 3. Re: I've lost my Parent! - V16 - Win - MDI vs SDI
              Paul Jansen

              There have been a few conversations about the implications of SDI, but not as many as I would have expected.


              Regarding "Good DB Design"  There are probably almost as many good design models as there are developers!


              What is good for your situation might not be for another business or organisation.  When I switched my primary plat form from Windows to Mac after 20 years it took some time to get used to having so many more windows open at the same time.  I still find it a bit 'messy' but I have got used to it and I don't think I am less productive.  In fact as a FileMaker developer it is great to be able to watch several windows whilst debugging scripts.


              So many choices...

              • 4. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                Congratulations, you are the first person that I've heard complain that this leap forward was a step back.


                The overwhelming majority of developers and users of windows PCs have lobbied for the per-window application window interface in FileMaker as far back as I can remember. Much more vocally than people that said the existing single application window housing multiple filemaker windows was acceptable.


                The change is hear to stay. Macs have had that type of application window forever, and FileMaker is trying to bring parity across all platforms so no matter what machine you are on, it looks and performs the same. Given how those application windows function at a base level, I highly doubt it would even be possible for them to allow the option between the two.


                I hate to say it, but you seem to have received some bad advice on what "good design" entails. There is no specific standard that says storing everything in separate files is better than using a single file. There's also the "Data Separation" model, that separates all of your UI into one file, and data tables into a second one. Ever since FileMaker 7 was released with the ability to place more than one table in a single file, developers have been gravitating away from one file = one table.


                If I was the owner of a "very nice custom made CRM solution", I would see this as an opportunity to modernize my application's UI. In the interim, I would get in touch with the developer that did your heavy lifting; most likely there are some small adjustments he can make to the window actions of your file (Like using a script trigger), that positions and sizes the windows so that they behave in a similar way as you were previously used to.

                IMHO, I have never been a fan of spawning multiple windows and switching between them as a good design practice. Maybe I'm not "one of the world's best FM developers", but I can at least hold my own. You may want to seek a second opinion as well if your contracted developer told you that UI organization method was the best way to do things; A little too "inside the box" of UI thinking to just entirely discount the way OSX UI performs.

                • 5. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                  Thanks for the passive aggressive. I can also be that way.


                  What's 'hear' to stay?


                  I'll take your abuse as a badge - and I've seen solutions that work the way 'my very nice system' works - but I guess I've only been around this industry for 30 years. I am the designer. My system presents one unified view to the user - using multiple databases (you know, the whole loose vs tight coupling concept - which I was taught during my CompSci degree - Yes, quite a while ago now). The user moves between databases seamlessly (or they did prior to V16). Now they have to jump around to all different windows if their FM is not blown out to full screen.


                  I don't think you hate to say anything at all.


                  My interface is extremely modern and intuitive. Yes, my developer is one of the best in the world - and you may well have been an audience member in one of his talks.


                  Thanks for your helpful contribution.

                  • 6. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                    I have to agree with Paul, we also face similar problems on some solutions we inherited, but have also been begging for SDI for years. The problems you are experiencing are no different had you run these databases on a Mac, as well as Windows. At least we now have consistency across both platforms.


                    I'm not sure multiple files with business logic built into each would be a choice we'd make, most of the solutions we support that have this have their roots in pre v7, where this was normal. Our preferred method is multiple data files feeding into 1 UI file, normally referred to as the 'separation model' as this spreads the data load but reduces development time (not having to call scripts across files). Others prefer a single file approach, but I don't believe many developers would commence a new solution using an old style multi-file design.


                    Although the older solutions will now require setting the window size for each file, most of our own current solutions require us to remove code. Modal windows have always required a platform check and if Windows under MDI, we'd have to run a subscript that checked the current window size, take it out of maximise state and reset the window size, then position the modal window relative to the rear window and then undo all of this as the modal window is closed. This was not elegant or pretty and now it just works as we'd hoped it would.


                    I wouldn't think there is much work resolving the problem for 5 files, we have some with 25 files upwards, which will take a bit more time, but script triggers should sort these out.


                    Kind regards



                    • 7. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                      mahacker wrote:



                      Plus, I wanted to gauge if there was any interest from others (as I couldn't find any complaints so far).



                      You won't find many complaints mainly because this feature was probably the absolute #1 request from most developers on Windows.

                      So the old behavior is not coming back.


                      Interested in what the thinking is behind 'good db design = multiple files'?  There are considerations to make for each solution whether one file or multiple is the best approach for the problem at hand, but there is not one set-in-stone dogma that dictates that there must be multiple files..

                      • 8. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                        mahacker wrote:


                        Now, I have about 5 databases - and all would be open and reside within the 1 single FM 'parent' window. They would be full screen *within* the FileMaker application. So, when I hit a button to switch between different dbs' - the screen would just switch easily and nicely to the other database. This then 'looks' like there is no difference when working with one database or another - it's just the one solution - all neat and tidy.




                        As Mike suggested, it sounds like the Data Separation Model a perfect fit for your needs.  I would venture to say that it would provide an even better FileMaker UI than you have now under MDI.


                        The "button to switch between different dbs" would instead be a button to switch between different Layouts each showing data from these different dbs.


                        Did you already consider and dismiss the Separation model?  What made you decide against it?


                        Given that your design has such a dependence on MDI, is your CRM solution unusable on Mac OS X?


                        I am one of the cross-platform developers who have been desiring SDI a very long time.



                        • 9. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                          Yes - I understand 'everyone' complained about MDI. But I suspect there is a silent mass of users who actually quite liked it - and seeing that it was in place for, ummm, forever...on Windows ...I suspect there may be others that agree with me. I didn't even know this was an issue until I saw it in the product for V16 - and I had to do some research and shake my head. I don't live and breath FM. I use it.


                          I may be the 'first' and 'only' - and that was a motivation for posting, to gauge interest - as well as a general rant.


                          I just have an issue when a fundamental feature is removed from a product that has been there since Day 1.


                          Yes - my thinking (and again from classical CompSci background) to also just my plain common sense (for sanity sake at least - so that the design is clean and manageable) and probably from reading it over the years, and I'm sure I viewed in various training db/fm training sessions is that it's best to keep a db small and efficient and it should do it's job and it's job only. Thus, multiple dbs are then linked to form 1 solution. That is, I have a db to do all the emailing for the CRM, and a separate db to hold all price quotes, etc. From this change to the UI, it seems FM are encouraging developers to go with 1 db only (if they want a single 'window'). Modular is better than one big glob.


                          Of course, the platform is so open you can do *anything*, and there are no real restrictions on design nowadays.


                          I still maintain, a single 'window' for the user makes thing nice and clean and usable.


                          I can't help but think that if this is so wanted by 'everyone' for Windows, then 'everyone' had poor solutions (or workarounds) prior to V16? (just my passive aggressive kicking back in since it was aroused earlier).

                          • 10. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                            I don't believe anyone is trying to say who is right and who is wrong, just that things move on. Remember it is some time since Word and Excel were MDI and FileMaker is just catching up.


                            Your description sounds perfectly logical, but it also fits into the separation module structure, which is currently the most popular method of achieving what you are describing. Using multiple files to store data is very sensible and the single file doesn't work for us, particularly for offline development and upgrades. However. spreading the user interface across all files would appear to inherit the worst of all worlds by having to use cross file scripts, inability to pass variables between them and no ability for a 'drop in' upgrade (or downgrade) facility.


                            As others have pointed out here, what works for each person works for them, but we all have to roll with the technology as it moves on. For instance, how many people are out there assessing the new v16 API but currently are using the Base Elements plug-in? Some will go one way and some the other.




                            • 11. Re: I've lost my Parent! - V16 - Win - MDI vs SDI
                              Paul Jansen

                              Many developers building for Windows have taken the approach of maximising the database windows and so showing only one window at a time to the user.  Switching to a different window, just obscures the other windows as they are further back in the stack.  With SDI we must now explicitly hide them to achieve the same result.  We have more control and more options with SDI, but also more responsibility to actively manage our windows - something that happened automatically with MDI.


                              Only presenting a single window at a time to the user can be achieved with several solution architectures

                              • with interface layouts in many files
                              • with a single UI file pulling data from one or more data files
                              • multiple UI files pulling data from one or more data files
                              • with everything in a single file


                              Similarly showing multiple windows at a time can now be achieved with the same choice of architecture.


                              As FileMaker has evolved we have been through this before gaining more explicit control but also having the responsibility to take actions that were previously implicit.  (remember how every set field 'included' a commit pre 7?


                              new toys to play with and more choices to make....

                              1 of 1 people found this helpful
                              • 12. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                                Thanks Paul. Helpful answer.

                                • 13. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                                  One thing I've learned from attending devcon for many years is that you can learn just as much from someone that has only used FileMaker for two days as you can from someone using it for twenty years. I was not disagreeing with you about the status or merit of your other developer. I was indeed chiding you for not sharing his name which results in us needing to trust your opinion.

                                  What I was trying to reiterate is that since FileMaker has many ways of performing the same task or presenting the same information, that maybe you should consider other points of view on what is considered the "best" approach. You've built your entire system in a closed environment of you and one other developer.


                                  You circumstantially accused FileMaker of making a poor choice where the visual and audible evidence from the community supports otherwise. This community is a place where we can agree, disagree, or even agree to disagree. Part of the beauty of FileMaker is that a lot of us acknowledge that there isn't always a "right" way to do something, but there are potentially many good ways of doing the same thing. Compare this community to something like StackOverflow, and you will quickly realize that most of our disagreeing responses are completely vanilla in contrast.


                                  I can understand being angry with a platform change that has required you to potentially have to redevelop large portions of your interface, but even after our back and forth, I still want to encourage you. Like I mentioned before, you have an opportunity to modernize (by FileMaker's standards, not yours) your interface to work on the new 16 platform and beyond. While it should be possible to continue your behavior from previous iterations in the new interface with some minor adjustments, I encourage you explore options for improving your users' experience with your app given the new tools available.


                                  Take card windows for example, could potentially be a great thing for you to integrate into your app. Making a change now may also open you up to a new network of customers by giving your solution parity across OSX, PC, iOS and WebDirect interfaces.


                                  Discuss it with your other developer. Any good developer will be open to exploring bettering their techniques, as well as the acknowledging that something that was recommended five or ten years ago may not be recommended today.

                                  2 of 2 people found this helpful
                                  • 14. Re: I've lost my Parent! - V16 - Win - MDI vs SDI

                                    I protect the privacy of people I work with - and wouldn't share his name with you - nor anyone without his permission. This is a courtesy you may not understand. I don't care if you trust my opinion or not, and care less about your recommendations or encouragements.

                                    1 2 3 4 Previous Next