Hallo Drew, Frank
We have developed a a implementation as described by Drew, wath sould
be the best practice at this day to keep or users a far as possible from
our Tables etc..
Second question: waths the actual situation of having macro's in the
base document (OO 3.0) it self ?
Greetz
Fernand
Drew Jensen wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
It should refuse to open the file.
Uhm.
I'd have a hard time implementing a logic like "do not open this
document when you cannot execute on-load-macros", this sounds ...
strange.
However, together with a "open a form when opening the DB doc" feature,
one could
- declare a minimalistic form saying "nothing here for you" as
on-open-form
- assign a macro to the OnLoad event of the DB doc (or the form),
which replaces the form with the switchboard
To me, that sounds more like a legitimate solution to the problem you
sketched.
Hi Frank,
Very good, and it does at first seem to fit the bill. If it actually
does however, depends in the end on the goal one is after.
My goal was best stated with the line
All this so that your users are kept away from the raw tables,
queries and such.
Let me try to refine the goal first.
- Use Base as a runtime platform for a data centric business process
application -
A bit better, and I think good enough for the moment. One comment on
this, notice that nothing in this statement refers to the database
engine used, embedded HSQL, local dBase files or remote MySQL /
PostgreSQL / DB2, it doesn't matter.
In fact if there were this "open a form when opening the DB doc" (I'll
call it the autorun property for the moment) for ODB files then your
suggestion of using a minimalist autorun form that turns around and
loads the switchboard form sounds like a very good 'best practices'
design pattern at the very least.
However it doesn't fully meet my goal - because, if the macro security
settings will not allow embedded scripts to run, leaving the autorun
form open and the Base file open on the desktop the user can just
close the autorun form and have access to the underlying functions.
Not what I want to happen.
Thinking about achieving my goal then it seems there is a second
property that wold be needed at the ODB file level.
"Hide Base window ( Yes / No )"
The property would have a default of NO.
It would only be active for edit if the "autorun" property held the
name of a form and when set to TRUE it changes the load behavior for
the ODB file to:
if autorun <> ""
---if hide_base_window = TRUE
--open odb file with property HIDDEN = TRUE
Ok - there are few things to think about here. Such as closing the ODB
file. It would be really nice if Base had a feature that counted how
many child windows where open IF hide_base_window = TRUE, incrementing
this counter every time a window was opened and decrementing when one
closed. When the counter hits 0, close the parent file - or something
similar, it would take a bit more thought to get that right no doubt.
Anyway - just a little idea to kick around on the list.
Till later,
Drew
-
To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org
For additional commands, e-mail: dev-h...@dba.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org
For additional commands, e-mail: dev-h...@dba.openoffice.org
