Extensions - there sure is a lot going on with that project. I was wondering
what if any thoughts people here have from a Base perspective?

Have any great ideas for a Base extension? My short list:

An application launch pad is my first want for an extension. You;ll probably
recognize it by another name, which you will have to extrapolate from it's
description:

-- Designate a specific form to automatically open when the odb file opened.

-- Once an odb is file marked to open the application launch pad form on
file load ( 'show' perhaps ) the user may stop the action with some action.
A key stroke perhaps.
==== If the odb file is also password protected the user could only stop the
application launchpad form from displaying by supplying the files password.

-- The application launchpad form is an instance of a modeless dialog box.

-- The extension must allow a simple interface to add buttons to the
application launch dialog, not requiring the use of Basic IDE. (
LaunchPadButton )
==== LaunchPadButtons should support the following actions:
======== Launch Form
======== Launch Report
======== Launch New Query Designer ( disallowed on existing queries )
======== Launch New Query Wizard
======== Launch Report Designer ( ??????? How to protect system reports and
support user created reports )
======== Launch Report Wizard   ( ??????? Same question )
======== Open table
======== Launch Query
======== Run script
======== Run SQL stored procedure ( only enabled when the database
connection type supports stored procedures ) [ Also may be redundant with
Run Script ]
======== Run external program
======== Exit ( close all open frames ( documents? ) and the odb file )

The LaunchPadButtons use the extension supplied function LaunchAction() to
perform the assigned action.

LanuchAction() must perform the requested action, and configure listeners
for certain actions on the frames created in so doing. The LaunchPad dialog
is then hidden.
At a minimum the LaunchAction must setup a listener to be called when the
the frame ( not sure that is the right object, should I be thinking
documents here? ) opened is closed.
ApplicationLaunchPad must maintain a reference count on the number of frames
( documents ), launched by itself. When the last one closes the LaunchPad
dialog is again displayed.
ApplicationLaunchPad ( ALP ) should maintain a separate stack for form
activation sequence. In other words which form follows which in activation
order should be related specifically to this database application, not the
systems desktop or the OOo desktop. When a form is closed the ALP should
determine which form should then receive focus.
LaunchAction should be used by the database developer to open any subsequent
forms from forms launched by the LaunchPad. This way it should support the
following scenario:
-- User launches first form.
-- User launches second form from button on first form.
-- User toggles to form 1, then minimizes it.
-- User opens a Calc file and does some work on it.
-- User toggles back to the Base application. Then closes Form2.
-- The base application Form1 should now be the active form for the desktop.
Not the Calc file.
-- User restores Form1 and launches form2 again.
-- User toggles to form1 and closes it.
-- User minimizes form2.
-- The Calc file would now receive focus on the desktop.
-- User selects the Form1 button on the system bar and closes it.
-- The LaunchPad dialog is displayed and has system focus.

LaunchPadButtons must support both simple push buttons and drop down
buttons. For example a "Reports" button should support display a list of
available reports, while a button "Daily Deposit" would be push button
running a set report.

??????APL should support OOo versions back to 2.1

??????APL must not alter the odb file in any way that would preclude it from
being opened by an OOo installation that does not have th extension
installed. ( Actually there are cases I can think of where you might want to
produce an odb that did not act that way, one that would only open is APL is
present...a way of offering a bit more security perhaps - not sure there
would be any way to do that..but then that is what a hack is all about,
right...doing the things you 'can't' do yet.. Perhaps this is a different
extension "BaseSecurityExt" )

Well, if that gets you thinking about other features for a LaunchPad...by
all means post them up.

Here are few other ideas:

Form based table/schema designer. Allow the user to open an empty form
designer, working with Form navigator and Add Fields allow the user to lay
out a form adding 'virtual' datasources and controls. Then auto generate the
actual tables needed to support the form, replacing the 'virtua' datasources
with the proper dataform controls to use the new tables.

A wizard to add calculated fields on forms - basing the calculation on
values of other controls on the form. ( would be really slick if it interact
with the Add Fields window )

A function to supply a NotInList event for combo box controls.

A function to store the current arrangement of columns in a table grid,
store that between sessions and restore the users arrangement whenever the
control is displayed.

=================================

Any thoughts from anyone on using the extension manager for Base
applications? Here is something that I find really nice, I've been using
Extension manager oxt files to distribute basic libraries with Tool bars and
menus via the internet. I haven't begun using the database support feature
yet, hoping to give that a try this weekend. Does anyone know if the updates
of the database registry entrys is the extent of the support envisioned, or
if there is any plan to actually include an odb file into the oxt file? Will
be giving the extension versioning support a test run this weekend also.
Currently each time a send something new to someone they have to use
extension manger to remove the old copy first and the install the new one -
with 2.3 this changes as long as the oxt file carries version information.

Using the extension manager really makes distributing a custom base
application to end users simple. Then a really nice part is how easy it is
to have someone setup this up in the OOo shared configuration area. You get
a shared library(s) that the end user can't accidentally edit and a database
registration that is also protected, and your toolbars and menus also
protected. Granted a lot of the hassle that this helps with is going to go
away with the 2.3 release of OOo.

Drew Jensen

Reply via email to