Hi all,
Still plodding along with the idea of an example database and at the
moment I am concerned with the idea of macro coding style.
I am not sure if there is any documentation to be found on this subject:
What is considered good practices and what is to be avoided.
In looking at the example code in the developers guide what Basic there
is, is quite terse. The staroffice basic programmers guide does not seem
to much help either. So I was hoping that you folks might have some
ideas about this.
Perhaps this little example just put up on the forum might be a good
place to start:
A user asked about using a list box in multi-select mode ( I took this
to mean they wanted something like a column of type SET, which of course
HSQL doesn't have ) I also remembered that the same subject had come up
on this board in the past. Anyway - I put together a small example of
how I would do it and you can find this at
http://www.paintedfrogceramics.com/OpenOffice/EnumeratedItems.zip
A couple of things: the file includes the database and a uno.pkg file
made with the new 2.0.3 library export feature. What do people think of
this as the way to distribute any required basic macro libraries?
Another thing is that I did not include any comments in the code. My
attempt was to make it self documenting...*chuckling*...it is Basic
after all. With that said however, reviewing my own work leaves me
wondering if I am not taking quite a bit for granted. Here is one
procedure in specific from the example:
sub onChangeRecord( oEv as variant )
dim oListBox
oListBox = ThisComponent.CurrentController.getControl(
oEv.Source.getByName( "lbxInterests" ) )
FieldToSelectedItems( oListBox, Separator, oEv.Source,
"ClientInterestes" )
end sub
The line oListBox=.... is a place where someone may wonder why in the
world be so convoluted - well I know that I am going to want to use a
method on the CONTROL that is not available via the controls MODEL. In a
case such as this should I have made a point of bring this up in a comment?
Acually here is another thing about that sub procedure - it's name.
onChangeRecord, I am calling it from the event 'After Record Change'. In
looking at it now I think perhaps it would be a good idea to try and
keep the names in synch. So perhaps it would have been better to name it
onAfterRecordChange...again what do other people think on this?
Anyway - any opinions on this would be appreciated.
Thanks
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
