Am Donnerstag, den 10.05.2007, 13:07 -0400 schrieb Andrew Jensen: > 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?
I haven't really thought about it, but writing services to be used from BASIC should be possible already. I do see problems coming up, if the extension is meant to be the controller of an application, not sure if that's possible. > 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. Yes, really necessary. I remember old Staroffice having a directory "startup" or the like and any document in there would be opened at starting up. > -- 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. Something like holding the SHIFT key when opening ... > ==== 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. This too is a very common task. AFAIR Access did this by having a wizard or similar building up and binding the buttons on a form to the entries in a database table. At least for "database people" this would come in handy. > 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. The frame is the topmost item, yes. > 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. This is something I was thinking about, too. Concluding it boils down to making forms (and document windows) behave like the debatable MDI-windows. On the other hand it has a great potential of confusing and annoying users not aware of this hierarchie enforcing technique. Problems arise when a user is working with an ALP-driven database and wantS to quickly work with a document not realted to the database app. > 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. If OO.o-base is meant to be an "application builder" what you call APL is deeply needed. With some work all of this should be doable in BASIC or in an extension, but having a pre-canned solution would be very attractive. > 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. I'm still waiting for the "macros in databse files" feature to go the full step from OO.o 1.1 completely ... Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
