OpenDialog InitialDirectory does not work using RB2011 on OSX

The following code was compiled on an XP machine using RB2011 targeting Intel OSX Carbon. On XP, Vista, Windows 7 and Windows 8 there is no issue.

On OSX Mavericks the InitialDirectory is not set but seems to default to the last selected folder. The folder path is valid and the issue seems to have started in Mavericks.

Is this a know issue and is there a resolution / work-around?

Dim image_folder as FolderItem
image_folder=Volume(0).child(“Test”).child(“Images”) .child(“Large”)

Dim f as FolderItem
Dim dlg as OpenDialog
dlg=New OpenDialog

Thanks in advance


Have you tried a new version of Xojo just to see if your issue has been fixed?

Hi Greg

I don’t have access to a Mac at the moment so if anyone could test the above using Xojo on Mavericks I would appreciate it. Either way I need to remain in RB2011 for the moment so if anyone knows of a work around within RB2011 that would also be much appreciated.



Problem confirmed. Whatever the value of InitialDirectory, the dialog always opens in Documents.

The only workaround I could imagine if you absolutely cannot switch to Xojo is to brew your own selection box with Item…

You could use OpenDialogMBS class if you use our MBS Plugin.

We have come across this same problem and submitted a bug report to Apple many months ago. I don’t hold much hope of it being fixed by Apple and the only solution for us is to complete the port to Cocoa. We tried OpenDialogMBS but it was occasionally crashing on Mavericks (with a Carbon build) so couldn’t use it.

You are right ; the bug does not exist when building in RB2011 for Cocoa.

If you have crashes with our plugins, please submit test project and crash log to us.

Actually, this could be a workaround : a small Cocoa helper app which only purpose is to provide the Open dialog, which you launch from your Carbon app and communicate with through IPCSocket.

Thanks for the posts - all much appreciated. My test Mac is back in action so I have been able to start testing solutions.

I can’t go down the Cocoa route without a lot of redevelopment in which case I would be better off redeveloping in Xojo. The Cocoa helper app route seems viable but potential complex.

The MBS plugin route seemed viable so I tested this and did not experience crashes after perhaps 50 tests. However, the initialdirectory was set only about 20% of occasions (the test used the “MBS opendialog with filter” example on a system with a fresh install of Mavericks). I put the MBS solution on hold for the time being pending further testing.

I returned to my application and tried a variety of small changes to see if the issue could be obviated via a minor change. Interestingly when the folder is set as follows, the filter is removed and the InitialDirectory is set at the last possible moment…

test_folder=New FolderItem("/a/b/c", FolderItem.PathTypeShell)

…the incidence rate reduces down to a single occasion when any OpenDialog is first opened by the application. That lasted for a while and then changed when next tested (perhaps caused by installing OSX updates).

It seems that the bahaviour is more chaotic and seemingly random that I first thought. Sometimes InitialDirectory is set and sometimes not. That is also the behaviour being displayed by the MBS solution.

If the behavior is random, it maybe a rather big issue for your users.

The helper app is not that of a difficulty, really.

Have a look at the example/Communication/IPCSocket.xojo_binary_project for a way to have the helper communicate with the launching application. I have used that technique several times and it is really simple.

As I mentioned before there is also the solution to brew your own dialog with the item property of folderitem, together with a listbox file tree. Look at the example Files/FileBrowser.xojo_binary_project which seems pretty easy to customize.

Thanks Michael. It is a big issue hence my desire to find a rapid work aound to buy some time. I am not familiar with helper apps. Is the helper app developed using Xojo and does it essentially act as an intermediary between the RB2011 app and OSX?

An helper app is just a Xojo app that you launch to do something your main app does not. In Mac OS X you can place in in the Resources folder within the bundle with a copyfile. Then you launch it with Folderitem.Launch when needed.

Then use IPCSocket to communicate with the helper.

In this instance, you create a small Cocoa app with no window, which in the App Open event connects to the main app, and gets the parameters it needs to create the file open dialog : initial directory, filter, title, etc. Then it opens the dialog, then reports back through IPCSocket to the main app the result : shellpath if the user selected a file, “Cancel” if not.

Look at the IPCSocket example. It is not terribly difficult to implement. To be able to play with two instances of the IPCSocket app, build one, and run in the IDE the second instance. Then click Listen in one, and connect in the other. You will then be able to type something in one and see that in the other. Just use that feature to send the parameters and receive them.

In essence, all the helper does is pop the open dialog, then it reports and quits.