One thing I've been wanting to do for ages in BaseElements is the ability to copy ( and maybe paste ) information out of BaseElements and back into FileMaker. Imagine that you've got an old analysis of a solution that has an older version of a Custom Function or a Script, and you need to put it back into your solution. Just open up BE, select the CF and hit copy and paste into FMP.

Obviously this isn't a built in function in FileMaker Pro and although it's relatively simple on the mac using applescript, there is no easy way on Windows. There was a plugin ( since discontinued I think ) that had this feature, and the new ScriptMaster Advanced from 360Works has the ability to set and get the clipboard. We've built this functionality into our own BaseElements plugin which we'll be open sourcing soon so anyone can give it a try.

So the just released beta 7 version of BaseElements 3 includes the ability to copy Custom Functions directly out of BaseElements and paste them back into FileMaker. And it has the bonus feature of including any modifications you make to the name, parameters or calculation in BaseElements into the copied version.

Hidden Features

The reason I call this a hidden feature is that it's implemented with zero interface. If you're looking at a Custom Function and you don't have an active field selection, then command-c will copy that CF to the clipboard. And if you're looking at a list or table view of CFs, then it will copy the entire found set of CFs to the clipboard. If you've got some text selected in BE then it will copy the selection instead.

I really like that it's implemented this way. There are some downsides in that some people may never find out about the feature, but hopefully the more I post blogs or when I finally finish the manual, there will be lots more places to find out about these things. But it's the fact that a feature that is really helpful, but you won't necessarily use 100% of the time, isn't taking up valuable screen real estate, where it would have to appear 100% of the time.

The ability to do GTRR into a new window by holding down the option key, and the ability to do GTRR using found set by holding shift are in the same arena. These, to me, are the two best features in BaseElements, but they don't ever announce their presence. ( They announce their presence inside ScriptMaker by their 8500 lines of code though - my kingdom for a dynamic GTRR step ).

It's always tempting to shout out these features by including them on the layout somewhere, but I think you're making a mistake in doing that, they don't need to be on the layout, leave that to the actual data, and the feature itself hides away and is called into action only when needed.

More to come.

For BE 3.0.0 the copy function will be limited to Custom Functions, and to copying only not pasting. I'm going to work on Fields next, and after that Tables, and then hopefully steps and scripts. The reason for that is the XML for CFs is relatively simple. We're not storing in BaseElements the actual XML like you do in ClipManager ( great product by the way, use it a lot, saves heaps of time, will post more later ), so we need to recalculate the XML from the stored data. For CFs that's pretty simple, some heading details and then a calc.

For fields it's more complex, there are lots of different types with storage and validation and calc options, there is a lot to recreate. Tables obviously depends on fields, so that would be next, but it's a relatively simple step once fields are done.

Script steps are a whole other box of hurt. There are 150 odd script step types and each one has very different coding for what data it comes with and how it's laid out in the XML. Have a look at the XML DDR pdf document for v11 if you want to get an idea of what's involved. The problem though with scripts is that we import into BaseElements the script text ( which isn't the same as the XML ) and also any reference items. So lots of the settings and options aren't included. These would need to be included in order to regenerate the XML. The reasons for that are two-fold : keeping the import time down, fewer items is faster imports, and also 99% of the time you won't need all of the details in individual fields, but you can see all of the details in the step text.

So the options with steps are to try to turn the actual text back into XML, or import more data. I'm going to play with both over time and see how it goes. I may end up with some sort of hybrid approach.

Pasting into BaseElements

This one I haven't worked out a full use case for just yet. It seems logical that if you can copy out of BaseElements, you should be able to paste back into BE. But where and how? Obviously if you're looking at a CF, pasting a script doesn't make sense. Even if you're pasting a CF what should happen? Should it over write the current CF? What if there is more than one in the clipboard?

My opinion is that it shouldn't alter any of the current data in BE. I don't think that helps in maintaining a record of your solution as it was imported at the time.

So there would be need to be somewhere else that you could paste into. Maybe some sort of scratch pad or toolbox type option. I'm still considering how to go with this, including the option of tight integration with ClipManager, so that I don't have to implement my own toolbox at all, I'd just use the ClipManager one, and reference it.

I'd love to know other's opinions on how best to use this and if they see a use case for it. Send me email, fill in the form, or reply on twitter.

One of my big priorities for BaseElements 3 was to reduce the number of objects on each layout to reduce complexity, and make it easier to work within BaseElements. There is a lot happening in BE, and trying to make things clearer will always help.

First, no more id fields.

One of the first things I thought about was the id fields. These aren't real fields or details in FileMaker, these are the internal ids that FileMaker generates for every object (layout, script, field, TO etc) that users never see until they run the DDR. We import these and use them for matching of related records.

In BE 1.0 the ids took centre stage, they were listed first, before the object name itself. I realised that this wasn't necessary, and in version 2, they were moved to the end of the item, as well as being removed from the portals altogether. You never needed to see the ids in a portal to understand what was going on, so removing them just meant I could show more detail in portals.

So in version 3 I was thinking about them again, and decided that they didn't need to be on any layout at all. I've almost never used them, but if they're required for one particular use case, then the fields are still there and whoever needs them can just add the field to the layout as required. ( There is full layout access in BaseElements )

I think this is wise, as 99% of the time, they're not used, and take up space and make everything else harder to work with. For the 1%, they're still available on demand whenever needed.

Second, the "Items that use this" count.

The other item I didn't like was the counts for "Items that use this xxx" or "Items used by this xxx". For example this one in the fields layout :

This takes up a lot of room, and doesn't provide a wealth of information, considering that in most cases more than half of the totals were empty. When I started doing conditional formatting on the tabs, I realised I could easily use that to display the "in use" or "not is use" status that these counts were taking up. There were two other functions that these fields were showing : the actual number, and the quick link that you had by clicking on the field label to go directly to that item.

My first attempt was to try to build the count into the tab name itself. Because it's a field not an actual tab name, that could work, but I couldn't come up with a format that looked good and displayed the right level of information. In the end I went back to think about it a little more. The critical thing is whether or not there are related records, the actual count is almost superfluous. If there are 3 or 30 it's not important as long as you know they are there. So the highlight works well enough, and I disposed of the counts.

The only other thing was the quick links. I haven't yet put these back into BE3. I'm not sure if there is a good way to go about it. You could have the ability to go directly to a list of items by option clicking on the tab or something similar. The only issue is that I'm alreading using option, shift and command clicking to do different things with GTRR so it may confuse things. And there isn't any sort of user interface convention that does this that I know of, so it would be a very non-obvious feature. I'm still considering options there...

Another quick update on last nights b5, which contains a couple of quick fixes for false errors, some adjustments to the FM Go compatibility report and an updated plugin for good measure. Download away :

BaseElements_Mac.dmg - fp7 files.
BaseElements_Mac_Runtime.dmg - Runtime.

BaseElements_Win.zip - fp7 files.
BaseElements_Win_Runtime.zip - Runtime.

Update : There is an issue with the plugin version on windows, so stick to b5 if you're testing on windows :

BaseElements_Win.zip - fp7 files.
BaseElements_Win_Runtime.zip - Runtime.

The next release will also have a fix for layouts that were incorrectly reporting Unreferenced. I should have this new version released in the next day or two.

I've just finishing uploading BaseElements 3 beta 4 :

BaseElements_Mac.dmg - fp7 files.
BaseElements_Mac_Runtime.dmg - Runtime.

BaseElements_Win.zip - fp7 files.
BaseElements_Win_Runtime.zip - Runtime.

There is a windows as well as a mac version, and the fp7 version now has sharing enabled for all accounts. The full list of changes is :

• More plugin error checking and reporting.
• Fixed an issue where odbc Data Sources weren't being imported.
• Fixed a false error in OSBC usernames and passwords - thanks Doug Rowe.
• Fixed a superfluous warning in Layout Fields.
• Added a dialog about running on PowerPC on Mac.
• Changed the display of the BaseElements wording on layouts to display properly in FileMaker Go.
• Built in a Minimum Required FMP version for calculations and script steps.
• Changed the licencing so that the single user version can be shared with FileMaker Server to a single user.
• Added more display checkboxes for layout objects to show printing, sliding etc.
• Added a portal filter calculation portal to the Object layout.
• Began work on a FileMaker Go Compatability Report.
• Some plugin fixes and enhancements.

There is a lot in there, so I'll write some more about it in the next day or so, but it's now late here and it's time for dinner :)

One quick note, if you're using it on windows it will only load xml from a local path, not from network drives. ( You can map the path to a network drive and it will work fine. ) This is something in the way that the file paths are handled inside libxslt, and I haven't yet got a solution to that one.