Leaderboard

LaRetta was one of the most fiercely loving and loyal friends I've ever had, despite never having had the pleasure to meet her in person. I'm so blessed to have worked with her until the end. She was unashamedly opinionated and caring, about people, justice, and about our craft. She sent me this passage from Barbara Kingsolver late last year: And she followed it with: I love you LaRetta, and miss you dearly. Guess I'm a little hokey too. ❤️ Your friend, Josh

For the next version of MBS FileMaker Plugin in 15.3 we add the Window.SetRoundCorners function to provide round corners. At the recent Vienna Calling conference a developer asked if we can get the edges of the card in FileMaker to be round. And yes, that is indeed possible. Once the card is shown, the MBS Plugin can find the card window and apply round corners to it. This even works on Windows: This seems to work fine in FileMaker Pro on macOS and Windows. It does of course not work for WebDirect or FileMaker Go. To add the round corners, you simply call our plugin function Window.SetRoundCorners just after showing the card. The plugin finds the front window and applies them. Here is an example: Show card with round rectangle: New Window [ Style: Card ; Name: "Card" ; Using layout: “Tabelle” ; Height: 400 ; Width: 600 ] Set Variable [ $r ; Value: MBS("Window.SetRoundCorners"; 0; 12) ] Please try with 15.3 plugin and let us know how well it works for you.

This file shows how I would approach this using the aforementioned method of filtering a portal to display only unique values. A few notes: For simplicity, I have left out the Positions and Subjects tables and used meaningful values for PositionID and SubjectID in the Assignments join table instead. This has no impact on the calculation formulae that need to be used. To some extent, this is a cop-out: I believe I could have done without the cCombinedKey field in the Assignments table. But it would have taken some time and - perhaps more importantly - the formula used for portal filtering would be much more difficult to understand. A note about your setup: I don't understand why you need the Levels table. Does it hold any other information besides an ID and the level? It seems to me that a custom value list of these levels would be quite sufficient. The other thing that puzzles me is the checkbox of these levels shown in your screenshot. It looks like users actually select multiple levels for each unique combination of Position and Subject, and your script breaks these down to individual records. And now you are asking how to combine them back to the original form? Wouldn't it be easier just to store the data as entered by the user? Link to the file (expires in 24 hours): https://wormhole.app/3D9xaz#GF8aSO2FXKXPIp8mfOLBkQ

Did you notice that MBS FileMaker Plugin 15.2 includes a new feature to add keyboard shortcuts for the result data types for a formula? If you visit the manage database dialog, you can use keyboard shortcuts to pick data types for a field: Text ⌘ T Number ⌘ N Date ⌘ D Time ⌘ T Timestamp ⌘ M Container ⌘ R Calculation ⌘ L Summary ⌘ S If you define the formula, you get a dialog like the one shown above. The MBS Plugin looks for the popup menu on the bottom left and adds the same shortcuts for the data types. If it finds the menu, it adds the shortcuts to the menu entries. This way you can press e.g. command-T to pick text. Just a little convenience, but our clients asked us for it. Enjoy!

This is a very simple arrangement. The left-most portal, where you select the category, is a portal that shows records from the current table (Category) - a.k.a a list-detail layout: https://help.claris.com/en/pro-help/content/creating-portals-list-detail.html Selecting a category in this portal causes the corresponding record to become the current record. And the portal to the Product table shows only records that are related to current record.

🕯️ I was informed today of the passing of @LaRetta this past February. Thank you LaRetta for the many years of sage wisdom and insights to our community you will be missed!

Sad news to hear. She was kind, sharp as a tack and very funny. I was fortunate to have worked with her. She will be missed.

This is indeed a great loss to the FM community. No one can equal her sharp eye for mistakes and her ability to pull a great idea out of a bucket of mediocre ones. Above all, her good spirits and great sense of humor made it a pleasure to collaborate with her. It was a privilege to know her.

Part 1: Embracing the Development Mind-Set Software development isn’t magic. There isn’t a black box where you can throw a bunch of ideas and requirements and out pops a smoothly working app that perfectly meets all of your business needs. Once you see that in print, it seems perfectly logical, but because the process is often hard to understand it feels like there is at least a little magic involved. In this seven-part series, we’ll pull back the covers and eXpose what you should know when you start the hunt for a professional developer for that custom, fix, or upgrade software project. We’ll offer tips to help you select the right developer, discuss pricing models, things to consider when signing an engagement contract, and walk you through the development process from idea to deployment. In this introduction, we offer a brief fundamental overview of what you should understand before you dive into any software development project engagement. Collaboration Development is a partnership between the client and the developer. You bring the knowledge of your business, your workflow and your needs. The developer brings the technical knowledge and software eXpertise. Both are equally necessary for development success. The developer should have a breadth of eXperience with various processes and technologies that will give you options to make your solution function smoothly within your workflow. But until you eXplain your business, your developer won’t know the intricacies of what you need. Even if you have an eXisting system, your developer still needs to know how you currently use it and how you wish you could use it. Knowledge From the developer’s perspective, it takes more than just a pile of papers, eXcel spreadsheets or a database to look at to understand your business flow. You are intimately familiar with how you do your job, often to the point where you could do it in your sleep. How things should work seems obvious to you. Rarely, if ever, will your developer be able to intuit the things you do by nature. You will have to eXplain it in great detail to make it clearly understood. This means that some things will need to be eXplained multiple times before the picture becomes clear. One strategy is to treat your developer like a new employee and teach your workflow step-by-step. You don’t have to teach all of the details of your entire business (unless the new application will manage the whole thing), but view the app like a job description and teach that job to your developer. That will make the functionality of the solution clear enough to represent the way you actually do business. It will also give your developer a foundation for making suggestions for improvement Perspective When building a full database solution you will end up looking at your business processes with a fresh eye as they go under the microscope while trying to properly eXplain them to someone new. Using development as a springboard, it is common to find things you want to change as you go through your business details. Software solutions reflect the business processes they represent. If those processes are inefficient, simply moving them from a paper representation to a digital representation will not make the underlying processes more streamlined or efficient. A custom app can make a process easier to manage, but will not fundamentally change it. Knowing this can put into perspective the effect the new software will have. Taking time to analyze eXisting processes with a focus on ways to improve them is a very important part of the development process. As part of that process your developer can make suggestions for improvements in the efficiency of managing data based on their previous eXperience with data systems. It’s up to you to decide whether the suggestions that come from your collaboration make sense to incorporate. eXpectations Once the development process starts the eXpectations on the developer can be a bit high. There is somewhat of an art to software development. Commonly when a feature is described to a developer it seems straightforward and sounds conceptually easy. Then when the developer begins to create that feature within the framework of the application there are often nuances to the feature or its integration into the eXisting database structure that weren’t anticipated. In this case the development time can be longer than eXpected because implementation of the feature ends up being different and often more complex than planned. This can create frustration for the client because the feature seems so simple to eXplain or straightforward when done manually. You might say, “We always … ” but the truth is, there’s probably at least one eXception to your rule. The eXceptions are easy to handle on paper or verbally, but every eXception has to be coded into the final working product. eXceptions are generally complex because they branch away from the established flow. Translating a manual process into an automated electronic process is most often like a duck on water. There is a lot of work and complexity under the surface to make the feature effortless to use. That takes time to figure out and then create. The duck on water is the magic. Read Part 2 of 7: What Should You Consider When Selecting a Development Partner? What Questions Might You Ask a Potential Developer? The post Survival Guide: Find, Hire and Work with a Software Developer, Successfully! (Part 1 of 7) appeared first on eXcelisys. View the full article