Hello, While I am very happy with the file explorer example within the JDE (I have 4.2, 4.5, & 4.6 - take your pick) I am extremely interested in using the existing media explorer to allow the user to find, select, and return the path & filename of the selected file back to my application via plain 'ol java calls...

It was implied that the net_rim_bb_file_explorer can be invoked in an "inter-application" way but this fails to point out how to usefully derive meaningful information from the execution of the explorer.

To re-iterate, I'd like to call net_rim_bb_file_explorer (or some library which composes it) and get a filename and path after the user has found what they were looking for.

The "inter-application" bit seems a bit complex for something that should be an API call but I am darned if I can find it after 3 hours in the docs and google....

The media explorer is extremely sweet and I think that there are probably a lot of people who would like access to this bit of code... any ideas?

ApplicationMenuItem instances registered with this ID appear when the File Explorer applicaion is running and rendering a file. If you use this ID, you must also provide an ApplicationDescriptor that describes your application. Your application will be started to run the code in the ApplicationMenuItem.run() method. You may also register a mime type String with your menu item as the context parameter. If you do, your menu item will only appear when a file matching the registered mime type is being viewed.

So we register a callback within our own application to be called externally when the media explorer is enabled and the user is selecting a file... When the selection is made, our menu item is added to the list and our application is executed so that the callback can act upon the file. Great.

This falls short of the intent of my original post for the following reasons: (IT IS COOL THOUGH)

1) If my program is program "A" (instance 1 or "A1") and I "Invoke" the net_rim_bb_file_explorer

2) The file explorer displays my menu item for the user to select and the user selects the menu item I embedded

3) The file explorer invokes a new instance of my application "A" (instance 2 or "A2")

4) A1 never gets to play with the returned path name and file

5) A2 has no context with which to handle the path name and file it has been given...

This problem set spawns the following questions:

When the OS tries to spawn an application and that application is already running, does the OS simply transfer to the existing instance or does it spawn a second instance? If the former, then the above callback may work. If the latter, then I'm still in the same boat.

Sorry if I'm being verbose, but this is an interesting problem that I know can be solved.

(I am going to attempt a test of the above issues and will continue this thread with my results. If anyone can throw some light on it in the mean time... Thanks )

The call for the run method of an ApplicationMenuItem occurs in a different process than your application. Therefore it'll fire regardless of whether or not your application is already running. The tricky part of this can be trying to share variables between the two. A simple work around to this is to store information you wish to pass between the two processes in the RuntimeStore.

Mark SohmBlackBerry Development Advisor

Please refrain from posting new questions in solved threads.Problem solved? Click the Accept As Solution button.Found a bug? Report it using Issue Tracker

This odd form of interprocess communication is highly unportable and fundamentally flawed in design. With an OS update the change of entry point into net_rim_bb_file_explorer could change and the whole strategy bricks the berry. (BTW - where is the info for entry points of 0,1,2 etc? Coudn't find that either...)

Access to the file explorer API would save alot of people alot of time. It would also, I believe, improve the overall user experience since a consistent UI across different third-party applications would be presented.