Some common questions about BaseElements.
You can also view a full list of all of the expanded questions and answers. This list also has an RSS feed if you want to keep up to date with any changes. Will be adding to this FAQ over time, especially during the beta period, so it might be worth either checking back often or using the RSS feed.
Yes, you do. BaseElements imports it's data from the Database Design Report that only FMPA can produce.
However, once the DDR has been created by FMPA, you can use any version of FMP or FMPA from 8.0 onwards to either import the DDR into BaseElements or to view the data files in BaseElements.
First generate the DDR from within FMPA. Then click the white "Import New" button at the top of the Home layout, and when it asks you for a file, select the summary.xml file generated previously.
Ok, so the first paragraph above made some assumptions about generating the DDR. DDR is short for "Database Design Report". It's a function built in to versions of FileMaker Pro since they introduced FileMaker Developer back with .fp5 files and is now part of "FileMaker Pro Advanced".
To generate the DDR for your solution, open all of the files in FMPA (FileMaker Pro Advanced) and go to the "Tools" menu. From there you've got an option called "Database Design Report...". Select that option. When the dialog comes up, change the radio button from HTML to XML and uncheck the "Automatically open report when done" checkbox. You can leave all of the other checkboxes, the "Available Files" and "Include in Report" options, checked.
It will then ask you for a place to save the file. Leave it named as it suggests "Summary.xml" and save it to a folder somewhere.
You can then close all of the files in your solution and open BaseElements.
BaseElements requires a minimum of FMP 8.0 to view any of the main layouts. Almost all of the layouts use tabs, introduced in version 8.0, to display multiple portals on a single layout.
However, to use 100% of the functions of BaseElements, you need to have version 8.5 of FMP to run the import process. The import process uses the "List" function, introduced in 8.5 to generate Table Occurrence Groups, and also to locate Script Indirection. It's also used in the Comparison Report to generate lists of layout objects.
I don't have 8.5 yet though !!!
Don't worry all is not lost, you can still take advantage of all of these things by using the Runtime version of BaseElements. Currently the Runtime application is at version 9.0, so you get all of the advantages of 9.0 without having to keep your version of FMP up to date.
You can still generate the DDR using whatever version of FMPA you have, 7.0 through 9.0, and then import into BaseElements using the runtime.
And if you really want to use the fp7 version, remember you can also open the runtime .BAS files directly in any copy of FileMaker Pro or Advanced.
Questions about the demo version.
No, the licence expires at the end of the demo period. Once you've finished the demo period, if you still want to use the included XSLT or any derivative of the XSLT you create, you will need to purchase a full version.
The licence for a demo version of BaseElements lasts for 30 days. If at the end of that time, you still want to use the software you will need to purchase a full licence.
Questions about BaseElements functions and features.
Version 1.0.5 and later of BaseElements added the option of a "Warnings" tab to detect issues that may or may not be problems in your solution or may just be issues that you'd like to be aware of.
Warnings are different from "Errors" in that an error is an obviously broken function in the database. A warning comes about, not because something is broken, but because it will work exactly as it is setup, but there are obvious reasons why the setup might not be what was intended.
The best way to use the warnings function is to look at this list on the setup, and see which of the errors you want to view and or look at, and turn some on or off depending on your development style. From there you can identify which ones are obvious fixes and should be looked at straight away, and which ones you can leave, and only address if they come up as an issue later.
Below is the explanation and details for each of the items that are currently warnings in BaseElements.
These are issues that are related to the functioning of FileMaker, not the output of the DDR.
This means you've setup accounts that have no password. Although not always an error, i.e. the default file option creates an Admin account with no password, in larger solutions with multiple accounts this isn't best practice.
The External Authentication process doesn't allow the user to change passwords, so trying to enforce the "Must change password on next login" will cause issues, or allowing the user to change the password will also cause problems.
This means that a "Join Predicate" - otherwise known as the lines matching one field to another in a relationship - are not using the same field type. This may or may not be deliberate. For example to match on a non-contiguous list of dates, you'd need to put the list in a text field and match the other side to a date field. However it's often the case that a field match from a text to a number that is done by accident will give unexpected results.
This warning is to alert you that a script step that has been disabled but has errors in it. Enabling the script step will cause the broken steps to be active, and this may cause problems, or have unintended consequences.
This is a simple one to catch, and a good thing to check for. It means you're doing a Cut, Paste, Clear, Set Field, Insert or Replace on a field that is specified as a Calculation or Summary field.
In other words, you're trying to modify a field that can't be modified.
This means you have setup privileges in such a way that you can delete records that you can't view. Which means you can't even tell what you'd be deleting when you tried to delete it - which you'd be allowed to do.
Without any TOs for this Table, it is effectively not able to be used anywhere. You could either remove the Table if it's not required, or add some TO's if you plan to use it somewhere.
This may not be an issue and may be deliberate, as you don't need Layouts for all functions, but some functions do require Layouts, and this may cause issues.
The Primary Field in a ValueList always needs to be Indexed. This will happen when you first create the Value List. If this isn't the case, the ValueList won't work, and your list will show no data.
However it is possible in some circumstances to have a ValueList using a secondary field that isn't indexed. If your value list is set to "Sort values using : First Field", then the second field doesn't need to be indexed. In fact in that case the second field could be a global or unstored calculation.
However if you sort using the second field, or show only values from the second field, then both fields need to be indexed for the ValueList to work.
This means you've added a field to a layout where the TO of the field isn't accessible from the TO of the layout. In other words, the field will show on the layout as "Unrelated Table" and won't show any data.
This means you've have created a file reference which might be pointing to itself. To get rid of the file reference you need to change all of the objects that use this file reference to refer to the objects directly so this file reference is no longer required.
If this is a different file you may want to consider changing it to a unique name to save confusion.
This means you are trying to perform a sort from an unrelated table occurence. You should remove the sort or change it to a different table occurence.
These are more "Alerts" than warnings. They are to point out issues in the DDR where either the data is incomplete, or there is inaccurate information in the DDR.
These 2 are related to bugs in the DDR output. In the options for importing and exporting data, there is an option for exporting as XML, and for processing that XML before or after with an XSLT file. You can also set the file to use in both circumstances by a calculation. However any fields, custom functions or other items that are used in that calculation aren't included in the XML output by the DDR.
So in effect a field used only in this place and no other would be listed as "Unreferenced" by BaseElements, when in fact it is in use.
This has been submitted as a bug to FMI, so I expect that it would be fixed in a future version.
If you've used FMP in a multi-file solution you may have come across this one. When you do a GTRR script step, but you're using a TO that is based on a Table coming from a different file than the layout, the layout shown in the script doesn't appear correctly.
For example, in a separation of data solution, your GTRR is going to a layout in the current file (the interface file). The TO for that GTRR is in the current file, but the Table that it's based on is in your data file. In this case although the specify dialog will show the correct name, the script itself shows the name incorrectly.
In all of the cases, BaseElements will pick up the correct layout and use that for it's reference. However the data reported in the DDR is affected by the same bug that affects the script display, so it doesn't always show the right information.
What is Indirection?
Indirection in FileMaker refers to the ability to reference an object by it's name, rather than by it's internal id. For example, when you setup a perform script step, and choose a script to perform, FileMaker stores the id of that script you're performing and saves that. That way, you can alter the name, or move the script within your file, and it will always still work. The same applies to fields used in calculations, FileMaker breaks the calculation into it's various parts and keeps all of the field, table, and custom function id's so that you can also rename those without breaking your calculation.
Indirection is when you are not referring to an object directly, you're instead referring to it by it's name. For example you setup a GoToLayout script step that chooses the layout by a calculated name. If your calculation for the name is fixed, but you change the actual layout's name, it will no longer be found and your script step will error.
There are more and more ways in FileMaker these days to use indirection to refer to an object in FileMaker. For example we now have these functions :
GetField ( "fieldname" )
Evaluate ( "myCustomFunction ( tablename::fieldname ) " )
that can refer to fields from a calculation. Also there are things like :
ValueListItems ( Get ( FileName ) ; "ValueListName")
As well as that it's possible to refer to layouts by number and also by calculated name. But these don't have to be simple calculations like the above. They could also be
GetField ( othertable::field )
Evaluate ( $$VariableName )
ValueListItems ( "otherfile" ; $VariableName )
in these cases the actual name to look for is coming from a dynamic location. In short there is nothing that BaseElements could do to work out what that variable is actually referring to at "run-time" when it's in the users hands. There may be cases where it's simple and in theory BE should be able to work it out. But there will be cases where it's impossible to tell, like if the layout name comes from a field that has user entry allowed. BE has no way of knowing what the user will type.
In short it's now possible in FileMaker to refer to objects using this indirection which could mean they show in BE as being unreferenced - if they are also used somewhere else.
Is this a limitation of BaseElements?
No, it's a limitation of any analysis tool whether it uses the DDR for it's data or not. It's a limitation we've now got because of the additional options we've got to use indirection to refer to objects in FileMaker.
I think the indirection options are worth the extra hassle we've added - they give us a lot more options and flexibility for our design choices. For example, you could have one GoToLayout script step in your entire file that goes to every layout it needs via a calculation.
How will I know if my solution is using Indirection?
As of version 1.3.0, BaseElements added a feature to find any examples of where you're using Indirection and alter the way it reports Unreferenced items. This means you can be alerted in advance if an item is Unreferenced, but possibly being referred to elsewhere.
BaseElements uses a simple checkbox to show if an object or item is completely Unreferenced. In version 1.3.0 and later, it also keeps track of whether or not objects are possibly being referred to via Indirection. There are five things that could be referred to Indirectly :
Custom Functions are found using Evaluate type functions. Fields and TOs are found via Evaluate, GetField and also Field Attribute functions. Layouts can be found via some of the Layout attribute Get functions, and GoToLayout or GTRR script steps. Scripts are found via plugins that can call scripts. And Value Lists are found via ValueListItem functions.
The total list of all of the functions it looks for is one of the setup options on the main DDR layout. So you can pick and choose which functions you want to check for.
How does BaseElements report Indirection?
If an item is Unreferenced, but your file is using Indirection for that item, it will change the look of the checkbox from a check, to a dash. You can still search for these items, as the actual value of the field is still a 1, but there is a calculated image field over the top of the checkbox that shows the dash.
Also the text colour of the totals on the DDR and File layouts has changed. It will change the Unreferenced green count to orange where the item could be referenced using Indirection.
So you can still see, total and search for unreferenced items, but you're now alerted if you should take greater care when deleting these items.
Is there anything else I can do about this?
There is also a function in BaseElements to not count an object as Unreferenced if it uses a specific naming convention. This is the [ ] that are around non deletable accounts or privilege sets. You can name any objects like scripts or other objects with the same conventions and they will not be reported as Unreferenced.
There is also an upcoming item on the todo list to set your own naming conventions for objects that are not Unreferenced. So for example you setup some conditions that say if the layout name ends in "DND", or if it has a "*" in the name, or it's surrounded by [] then it isn't unreferenced, and it won't appear in the totals, or have it's checkbox set.
If you'd like to see BaseElements do something specific, let us know via the comments and we'll do our best to include it.
First be aware of the limitations in the DDR output. There are 2 significant limitations that you should be aware of. We consider these bugs in the current (8.5v1) version of the DDR output, and have submitted them to FMI as such.
Second be aware that there are still yet more ways that you can reference items that BaseElements can't catch. Things such as external methods of accessing the database like web publishing or ODBC. And finally that BaseElements can only work with the files you have selected for use in the DDR. Any other files that reference the current one will not be included.
Background
In versions of FileMaker prior to v7, you had one list of "Relationships" for each file and this represented both the end point of the relationship as well as the field being used as a match field. v7 changed all of that where you have a graph, and it now has Table Occurrences as well as Relationships to join them. But a single TO may be connected to one other TO, or to none, or to 100. So the same concepts no longer apply.
Imagine a simple graph where you have 3 tables, A, B and C. They're joined together in that same order by 2 relationships A-B-C.
How do you tell which Relationships are being used? Imagine you have a layout for each one, and that you have a script that references a field in C. If the script is called from a layout that uses C as it's base table, then none of the relationships are used. If the script is called from a layout using B, then the B-C relationship is being used, but the other A-B relationship isn't. And if it's being called from a layout based on A, then both Relationships are used and required.
However scripting is also not that simple any more. Imagine that the script is called from a layout based on A, but does a Go To Layout based on a calculation passed as a script parameter. Which layout does it go to? And so, which Relationships does it use?
The short answer is that there is no way of knowing.
The main difference is that all of the functionality now in v7 and later refers to TOs and not relationships. You no longer know what path a reference to an end point like TOname::Field will use, just that TOname is the end point. And so given a layout based on A and a calculation that references C, you can only assume that it's possible for both Relationships to be used at some point.
So, when are TO's Unreferenced?
If you know, in the example above, that A is not used for any layouts, and not used in any calculations or other steps, then A can be deleted. It's not used anywhere.
However, if B has no layouts and is not referenced anywhere but both A and C are, then you don't know if B is used or not. Again it depends on what context the references to A and C are used, and where and how.
The short answer is that any TO is unreferenced only if there are no explicit references to it, AND it's the end point of a graph. A TO is on the end point of a graph if it only has one or no relationships to it.
Deleting unused Relationships
You can only then remove a Relationship by removing a TO that has relationships to it. So instead of thinking in terms of Relationships, think in terms of TOs and work from there.
All of these notes apply to version 2.0 and later of BaseElements only.
Now in version 2 of BaseElements, we have separate UI and Data files, so it's possible for us to issue updated UI files and leave the data file intact. Plus we have a button on the setup layout that allows you to manually import from previous versions of BaseElements. So regardless of whether or not there are data changes, it's possible to bring all your data into new versions of BaseElements when changes are made to BE.
To keep track of what changes are made and what sort of import is required, this page will list any requirements and also say whether or not you can just replace the main and UI files.
1 - Replace non Data File The BaseElements_2_Data file is unchanged and you can replace the other files ( BaseElements_2 and BaseElements_2_UI ) with the new versions from the download.
2 - Import From Previous There are changes to the data file, and you need to import any data you want to re-use using the button on the setup layout.
3 - Import Again From XML There are changes to the XSLT import process, and you need to re-import your XML files.
Note: This list assumes you're importing from the directly previous version. If you've skipped a particular release, you need to take the greatest action in all the versions in between your current and the new version.
| Version | Instructions |
|---|---|
| 2.0.7 | 3 - Import Again From XML |
| 2.0.6 | 3 - Import Again From XML |
| 2.0.5 | 3 - Import Again From XML |
| 2.0.4 | 2 - Import From Previous |
| 2.0.3 | 3 - Import Again From XML |
| 2.0.2 | 2 - Import From Previous |
| 2.0.1 | 3 - Import Again From XML |
| 2.0.0 | Initial Release |
I really really need to keep old data : There is no reason that you can't keep the old data by importing into the new files, even if the details above suggest that you re-import from XML. However the reason we list the re-import as the suggested action is that you should be aware that there are differences in the import process, so the data will have changed between versions. Keep the old imports only for historical reasons, and note that any fixes introduced in the latest version won't be included in the old import.
The short answer is no, there isn't a way to do this. We changed a lot of the data structure, added more tables that just didn't exist before (Calculations, TORefs, etc), and generally made lots of changes to the field names and methods of working. So there isn't a process to import from your BaseElements 1.x versions into 2.x. There is always the option of keeping 1.x around while you need it, and using 2.x for new imports, or re-importing any historical XML files into 2.x.
In short, no. We've designed the solution to fit best on a monitor of at 1024*768 at the least. This is to give us lots of room to fit things in and because of the nature of filemaker's layout options it's not a trivial thing to change.
I'd suggest sending a feature request to FileMaker to ask them for a more granular zoom option in the next version.
The addition of a Warnings tab to BaseElements also adds the potential for a whole raft of additional changes that we can add to help developers build better solutions.
We're definitely going to be adding these sorts of options to BaseElements over time. The options we're looking at fall into 2 basic categories :
We think that the Warnings feature could be used to enforce developer rules about the solution design. For example, if your development team has rules about field/layout/script naming conventions then this could catch places where that hadn't happened.
Or for example, if your development approach requires every script to be commented to show the function and purpose of the script, then this could also be used to pick up where a script was missing it's comment header.
For example you may decide to enforce the development rules from the guidelines document put out by a FileMaker developer group last year. BaseElements could be used to enforce either some or all of those rules.
Firstly, we'd like to pick up some of the more difficult warnings. Things like using a Variable before it's been declared in a script - this may assist in picking up typos in variable names.
There are lots of other potential uses for this we think. We've got some other ideas and we've had plenty of feedback from other people about this too.
But we're still on the lookout for feedback and ideas about how people would like to use this function, and ways that they would like to expand on the offerings already available. Contact us or leave a comment below if there's something you'd like to see.
The checkboxes that you see everywhere in the system are the "Unreferenced" box. If the box is checked, then the object it's referring to is unreferenced, and could possibly be deleted.
However there are special checkboxes for 3 of the objects : Scripts, Layouts and TableOccurrences. For these it's not a checkbox, but a calculated graphic that shows the Unreferenced status in in one of 3 ways :
Referenced - empty.
Unreferenced but may be in use - shows a dash inside a box.
Unreferenced - checked.
The "maybe" state is for a script or layout that is unreferenced, but still appears in the menu, and so it might still be in use by the users, even though you never see it referred to.
For a TO the maybe state is for a TO that has nothing referring to it, but has more than 1 relationship off it. In that case, it's possible to have a GTRR or a calculation that starts at one of the other related TO's and goes via this unreferenced one to the second TO. This would mean that the TO is required as an intermediary step in the relationship.
But also there is a maybe "dash" shown when the object is unreferenced, but the file is using Indirection to reference these types of objects. For more information about Indirection there is a separate FAQ page available.
So to be able to do a search for these TOs/scripts/layouts, when you click on the field in either mode, you get a pull-down instead of a checkbox. The values for the pull-down list are
0 - Referenced
1 - Maybe Unreferenced
2 - Unreferenced
That way you can still search on the field, but you also get a very clear instant response from the checkbox graphic.
The comparison report has an option in it to compare either by name or by id. The report is exactly the same, except for this one point, and there is a difference worth knowing about.
The comparison process creates a relationship between the old file and the new, and uses either the internal FileMaker id, or the name as the key field in the relationship.
The best way to look at the two types is to describe two hypothetical solutions, and when you'd use each report type.
Compare by ID
This option is best used to look for changes in a solution over time. So for example, your solution is in use by your client, and the client is making changes. You want to know exactly what has changed in the solution since they started work on it. A compare by ID will show you all of those details.
Compare by Name
A compare by name is best used when comparing two versions of a solution developed side by side. So for example, you're making changes in a development copy of your solution, and then replicating those change to a live version.
A compare by name is also useful in the case where you have two files that have been developed for two separate purposes, but, with either a common heritage, or a set of common features. After a while, you realise that the two files should be one, and you need to merge the two files. In merging the two files, you need to know what is the same, and can be left alone, and what is different and will need to be programmed for.
About FileMaker IDs
FileMaker creates the unique id automatically behind the scenes, and it's not something you can alter. Almost everything has a unique id. If you have a fp7 file, and make a copy of it, the ids stay the same. The ability to rename things in FileMaker comes from the hidden ids that are actually being used to reference the items used.
If you develop two sets of files independently, there is no guarantee that the ids will be the same for the same items. You might create two exactly similar files, but if you do anything out of order from one file to another, then the ids will get out of sync. So you'll end up with two files that appear and behave exactly the same, but are very different underneath.
If you purchase a BaseElements Site Licence, you also have access to use BaseElements on multiple machines at the same place of work, as well as on a FileMaker Server machine shared amongst multiple developers. You must have a Site Licence registration code to act as a client to a shared version.
The Site Licence is flexible, in that you can mix and match single user and Sharing enabled versions as you wish. You can use BaseElements on as many computers as you have developers in the same company or at the same site.
Using BaseElements on FileMaker Server
The demo version above has sharing enabled for 2 External Authentication Groups :
FMP_BE_Edit
FMP_BE_Read
that have Edit and Read only access enabled respectively.
At present sharing is only switched on for EA accounts.
The reason for this is that you may want to run BaseElements on a server that is also sharing other files for users not developers. This way you can restrict BaseElements to only those users who have access. A default or published standard FMP account would allow users to bypass the EA account, which may not always been in the best interest of the company.
If you need a specific EA group added to the files, we can do that for you. Contact us for details.
Questions about the plugins that BaseElements uses.
If the import works without error, then you can safely ignore the plugin dialogs on startup. If you are getting errors, then let us know via the contact page which errors you get, and with which version of the plugin. Failing that, and if it really bugs you, contact us, and we'll send you a version with the older versions of the plugin as you require.
We would however recommend you use the supplied version of the plugin. It contains fixes for crashes and other issues that would end up being rather annoying. ;)
You don't need the plugins for just viewing the data. Once the DDR is imported, you could remove the plugin without issue. The TroiFile plugin is required for importing data, when selecting folders to import and to create the XSLT folder that stores all of the xslt files.
Once the import is done, however, it's not required for using BaseElements, so could be removed.
The plugin is included as part of the download, and need to be copied to the extension folder of any version of FMP you wish to use with BaseElements.
Purchasing and Licence related questions.
Yes the standard version is single user as per the licence agreement, but we also sell a multi-user version. Have a look at the purchase page for details. It also describes the licence structure for each of the versions.
No, you don't need to have a PayPal account to purchase. PayPal is just used for transaction credit card processing.
When you get the page that asks for a PayPal account, just use the credit card details form instead.
Fill out our contact form and let us know the exact details. If you have purchased already but don't have a registration code, make sure to include the email address you used to purchase with, and also any other information you have such as order numbers.
Remember it can take up to 24 hours for the purchase to be processed and registration codes sent through to you, so please be patient.
Goya Pty Ltd
PO Box 327, Mt Waverley, VIC, 3149 Australia
http://www.goya.com.au/baseelements
Ph: +614 2575 8280
SOFTWARE LICENSE AGREEMENT AND WARRANTY.
Goya Pty Ltd (hereinafter "the Licensor"), offers license to install, use and distribute the enclosed software only in accordance with the terms set out in this license agreement. If you do not agree to the terms as set out herein, you should delete all copies promptly, and contact Goya Pty Ltd to request a refund.
All of our Developer Products are available on an unlocked completely un-restricted 30 day trial. We suggest that everyone take advantage of that before purchasing. Because of the nature of that policy, and the fact that you receive an electronic product that cannot be returned, we do not by default offer a refund if you decide the product does not meet your requirements.
However, mistakes in the ordering or other processes do happen, and we're very flexible with people who are willing to be reasonable. If you believe you are due a refund, please contact us and we'll certainly listen.
Ultimately it will be at our discretion as to whether a refund will be offered.
As of version 1.0.5 there is the addition of a runtime version of BaseElements that is available for download. This version has also been packaged with a single BindKey that means when there is an updated version available you only need to download the updated files not the entire run-time application.
Background
The FMP runtime process generates the entire runtime application for you. It creates, for example on the Mac, a "BaseElements.app" application, plus it packages all of the DDR files with a special BindKey that links them to the application.
Whichever version that BaseElements is at, the runtime application is at the version number of the copy of FileMaker Pro Advanced that it was generated with. What this means is that if we update BE from 1.0.5 to 1.1.0 for example, but FMPA stays at v8.5 then you don't need to download the entire application again. Just download the updated runtime BaseElements files and replace your existing ones.
Also when FileMaker releases the next update to version 8.5 (presumably to 8.5v2) then we can create a new runtime application that uses the 8.5v2 version as it's engine and automatically take advantage of any fixes or new features in that update. All without updating BaseElements, or without you losing your data files.
How does it work?
If you want to use the runtime, then the first time you download, make sure you grab the full download. Unzip it and copy to wherever you want and use as normal.
When there is an update to FMP or FMPA, we will release a matching BaseElements runtime update for the current release, including a new application download. In this case, you only need to download the application files again, and literally replace your old app files with the new ones. All of your data remains safe.
When there is a BaseElements update, then you only need to download the updated BaseElements files. Move the old "*.BAS" files out of the folder if you want to import your data from them. Copy in the new "*.BAS" files from the download. Once that's done you can import from the old files if you want, or just continue to the use the new files and do a new DDR import..
If you've got any queries, don't hesitate to contact us, we're always happy to help out.
Questions about the FMPA Database Design Report.
You need to generate the data in XML format not HTML format.
HTML is a bit like a self generated cross-reference, but it's not complete and is difficult to search site wide.
While you're there, remember to fill in a feature request that the options for XML/HTML are remembered each time so you don't have to change it every time.
BaseElements will import accurately the DDR generated from FMPA 7.0 and above. We recommend using 8.5 if possible due to the large numbers of fixes since 7.0, but it is and will remain working with 7.0.
It will also import some data from versions of the DDR prior to 7.0, but it is not tested with those versions and because of changes to the way FileMaker works, it won't import all of the data in those files.
The font we chose is called "Tahoma". It's not the best font by any means, but it has one critical factor that no other cross-platform font has : that it's the same height on both mac and windows. There are some more documents about this on the GoyaBlog, but basically, you've got 11 choices for a default installed font, and none of them are the same on mac and windows.
However, if you assume that the user has some other microsoft software installed on the mac such as office, then you also have the option of using Tahoma. If you don't have office and don't ever plan to install it, do a google search for "download tahoma font mac" and you'll find plenty of places you can get it from.
Also, if you're not worried about the look, it won't affect how well the software works.