some misc info on various vba functions we don't support ( or that there is some differences ) 

CallByName  - calls methods and/or gets|sets properties of objects
==========
doable needs to use introspection and reflection interfaces from uno, all of our objects are uno objects, probably can integrate this directly as a function in ooo-basic to make use of the existing SbUnoObject code

CCur
====
in anycase it behaves differently than in Excel e.g.
output of 

Sub CCur_Sample()
    Dim A As Double
    A = 123.456789
    MsgBox A * 2 
    MsgBox CCur(A * 2) 
End Sub

result on openoffice

246.93578
246.9135

result on excel

246.93578
246.9136

is the problem just purely a one of rounding, how is the precision controlled? lots of questions but little information

look in basic/source/sbx/sbxcurr.cxx:56 

SbxINT64 ImpGetCurrency( const SbxValues* p ) 

CDec
====
this exists on windows openoffice only. The underlying SbxDecimal type has a windows only implementation and seems to use windows api code. 

seems that a decimal type is not part of the c++ standard ( yet ) see http://www2.hursley.ibm.com/decimal/ for more detail

CreateObject
============
this function does exist, however it's not the function that is the problem but what it is used for. CreateObject is used for creating ole objects, this only makes sense on windows where these objects exist. Trying to do
createObject("Word.Application.8") has zero chance of success on linux.... will work on windows openoffice though.

it may make sense to allow access to clones of useful objects in platforms where they are not available e.g. the Script.FileSystem object etc. but that is a different story.

** additionally there is some i18n issue with this which makes it fail in japanese locale

CVErr 
=====
works for me ( Debug.print doesn't and hence the runtime error )

DateSerial
==========
displays a different value, but it's not the Dateserial function that's at fault but the Format function. 

DateValue 
=========
ditto, formatting doesn't appear to use the locale specific date separator(s) ( longdateseparator ) 

not sure exactly where this is handles ( and e.g. it looks like calc does handle this, see cell-format-date types ) so it should be possible to do,

DoEvents
=========
absolutely pointless I think, we should stub this but beware 
   a) doevents is based around whatever event mechanism vba/ms-application uses, we don't have the same model and who knows what kind of edge cases this behaviour can give
1 day

Error Function ( Feedback required )
==============
there is an error function, what's the problem the error text for different error numbers is different? 

if the errors are to be made compatible its not just changing text and associated number, there will be a ripple affect I guess where the errors are called, also how they are defined

Filter 
======
should be roughly like the 'Like' expression ( in terms of the code ) as I suspect this will also take wildcards

Format
=======
Format already exists, the test exhibits one sub piece of functionality that is missing/different to implement this piece 'Long Date' as a format type.

see notes on SvNumberFormatter below

also the format function in basic always falls into 

FormatCurrency Function
=======================
everything required seems to be already supported by the number formatter, we just need to expose that code here ( see cell->format ) 
e.g. groupdigits is the thousands check box, 
with params
NumDigitsAfterDecimal(2), IncludeLeadingDigit(0), parensfornegativenumbers (true), groupdigits(true)

you could form the following format string
#,##0.00;(#,##0.00)

****  NOTE *****
there is an issue with all of the Formatxxxx methods that there are defaults to the system regional settings, in openoffice these 'regional' settings are not used, instead each locale has predefined formats for those.

you would think that this should not be a problem as generally you do not want your functions to be influenced by the regional setting ( as these can be different between differnet users/computers )

but if forced we could I guess use bits from the old pre-i18n framework code which according to Eike is in the International class in /cvs/util/tools/source/intntl/Attic/* 
( no idea what state that code is in )

FormatDateTime
=============
there is a small difference according to kohei
"except that the second ( longdate format ) line has the day of a week in
parens appended to the end in Calc, while Excel doesn't display the day
of a week."
it should be possible to either modify the data in i18npool/source/localedata/data/ja_JP.xml or pass the desired format directly to the numberformatter

FormatNumber
============
see comments in FormatCurrency

FormatPercent
=============
see comments in FormatCurrency

GetAllSettings 
==============
only possible to use our own registry, either using the configuration or berkelydb

GetAttr
=======
Archive or System types are not detected on windows, additioanlly on systems where hidden doesn't make sense this probably won't work, need to add window specific code at least to handle the archive type
currently uses the ucb (or filestat ) to detect the attributes for 
readonly, hidden, directory

GetObject
=========
similar to CreateObject, but seems a little different, vote no!! even to implement a windows implementation is only ever possible


GetSettings & SaveSetting
===========
associated with GetAllSettings ( all part of the same bag )

IMEStatus
=========
just saying no

Monthname
========
needs localisation in i18npool/source/localedata/data/ja_JP.xml

Partition
=========
funny function that seems to have an adequate explanation, also I suspect some edgy cases

QBColor
=======
This is marked as not working in MSOffice, ( due to a bug in the test macro )
works but needs to be modified in openoffice

an alternative table needs to be defined to be used when the compatibility option is set. see RTLFUNC(QBColor) in basic/source/runtime/methods.cxx

Replace
========
seems like simple search/replace functionality should be plenty of examples in the code

Seek
====
need to detect when the file doesn't exist and return ( whatever excel does *1* i think ) in that case.

StrConv 
=======
according to kohei
"Actually, Writer already provides the same functionality in Format >
Change Case.  There is full<->half width conversion, and Hiragana
Katakana conversion there.  So, the code must be lying somewhere, or it
may even be available via UNO...."

we just need to find it ;-)

also the LCID are defined by
http://support.microsoft.com/?kbid=221435 
Tab
===
should be similar to Spc 
refer to RTLFUNC(Spc) in basic/source/runtime/methods.cxx
method looks like it should more or less be a copy ( e.g. share code ) except instead of using spaces we use tab in this case 

Time
=====
it should be possible to either modify the data in i18npool/source/localedata/data/ja_JP.xml or pass the desired format directly to the numberformatter, verified that changing the first time format to include seconds ":ss" works

Timer
=====
result is quite differnt 
it displays a date

TypeName
========
works nearly the same, 
a) doesn't detect ole object type 
b) returns object as the type of Object when the Object is null, in vba the return is 'Nothing'

Val
===
different results
according to excel help val should only read up to something it doesn't understand e.g. ',' then it should stop and evalate that


some notes on the Number formatter
==================================

access to localized date formats ( and also various number formats ) is via the SvNumberFormater ( svtools/source/numbers/zforlist.cxx ) class
 ( which in turn also uses the  NumberFormatCodeWrapper ( unotools/source/i18n/numberformatcodewrapper.cxx )


the date format codes are sorted and stored against indices representing there function like NF_DATE_SYSTEM_LONG ( long date format ), available codes are gathered e.g. in 

SvNumberFormatter::ImpGenerateFormats():2354 
	aNumberFormatCode.getAllFormatCode() ( sucks in the format codes from the i18n locale service )

then there is a strange operation
	mpAdjustFormatCodeDefault() that does the sorting ( I think ) 


the number formatter uses the underlying data for the locale as generated from e.g. i18npool/source/localedata/data/ja_JP.xml into i18npool/unxlngi6.pro/misc/localedata_ja_JP.cxx
thing lik localization of month, day, era etc. date & currency formats etc. all live in this file.

interestingly the default format for say the long date is not what the number format uses when you try and uses in FormatDateTime

e.g. ULONG nIndex = pFormatter->GetFormatIndex( NF_DATE_SYSTEM_LONG, eLangType );

it seems to pick up the *first* format for the type e.g. the first DateFormat for the long date in the case above. ( that doesn't seem correct )


useful entry points

BOOL SvNumberFormatter::IsNumberFormat(const String& sString,
									   sal_uInt32& F_Index,
									   double& fOutNumber)

you can stick any string in here ( like a string date ) and get a converted to a number.

To apply a specific format to a number ( and remember that number could be a double date ) you could try 

BOOL SvNumberFormatter::GetPreviewString(const String& sFormatString,
										 double fPreviewNumber,
										 String& sOutString,
										 Color** ppColor,
										 LanguageType eLnge)

there must be also another direct way to do this I guess, but I didn't find it

