We should be able to use a language everywhere.
This is a clear example where you can use Formula but not LotusScript.

I would like to standardize all my development in 1 language (Java), so I can do a faster development reusing code (not coding the same in Java, LotusScript and Formulas in different places of my application). But the problem is that in some places we can only use Formulas, in other places we can only use LotusScript (as in many events of the "Database Script"), etc...

So, I promote this idea and propose to extend it to the Java language also.

DO NOT DO IT!
The default file format used by MS Office 2007 is proprietary. It does NO adheres to any standard. This file format will NOT be the default file format of any future product (not even MS itself will use it, MS has already announced it'll use as default the format defined by ISO standard ISO/IEC 29500).

I'll demote this idea. I'll promote any another idea on the way of better integration with the ISO standard office file format ISO/IEC 26300 (OpenDocument).

Being able to view ISO/IEC 29500 (OXML) format documents could also be interesting in the future, but not needed today since no available product, as far as I know, produces office documents conforming to this standard.

The Office 2007 file formats are NOT the "standard" file formats approved by ISO/IEC 29500; so it's not worthy to waste any effort to support them.

Strconv(nameString$, SC_ProperCase) do not behave the same when 'special' characters exist in the string, for example '-' in the word "Real-Time".

The proposed pcase() function would be an opportunity to make it behave like the formula @propercase() counterpart.

The old privative MS Office formats (.doc; .xls; .ppt) are NOT a fact of life for me.
It's not crucial at all.

Efforts should be put in a better integration of the OpenDocument Format (ODF) [ISO/IEC 26300 standard file formats] with Lotus Notes/Domino; for example in the (easy, out of the box) import/export of documents and views. It should also be trivial to create reports (text documents or spreadsheets) in OpenDocument Format from our lotusscript and Java code.

I see some "real" problems with the handling of signatures today that should be addressed with a much higher priority than the "stetic" issue you are proposing:

The big issue is that signatures should be stored in the mail database, not externally because it breaks on roaming, etc...

Policies for signatures are NOT usable, because when you reply an e-mail the signature is included at the bottom of them e-mail (after the another person message) and NOT just right afer your reply.

And if I'm viewing the "Unvoted" ideas, clicking "Next Idea" should show me the next "unvoted idea" (it this specific case, I'm not interested in watching ideas I have alread voted).

@1 Me too.

The MessageID is specially needed for messages in different languages. If I get an error in Spanish Lotus Notes, it gets sometimes very difficult to guess which would be the english message to be able to search for it.

I'm not able to see it would be any useful for me or my users.

I don't like the idea of changing the class interface (signature of methods).
In case of changing thinks, there are more things to think about, for example generics:
Vector getItems();

could become:
List<Item> getItems();

I think we already have it.
Look at field "Change Password on First Notes Client Use" ant set it to "Yes".

It is located at the Security Setting policy, Password Management TAB. When you set the field "Use Custom Password Policy for Notes Clients" to "yes" you will get an optional "Custom password policy" TAB with this and many other fields.

This is absolutely needed.

Yes, we need it, but it should be more sophisticated than just sorting by one field.
The Java language has a very good approach for this which could be somehow reproduced in lotusscript.

I'd like to have displayed:
Random ideas which I've not voted yet

If not enough available, fill in the list with ideas which have new comments since I voted for them

We already have the RSS feeds, which include comments and are far more convenient than an e-mail notification.

*.xls is a propietary non-standard format. The documentation of this format is not publically available. No way it is worthy to spend a minute on this old and odd format.

Let's concentrate our efforts in an excellent compatibility with the standard ISO OpenDocument format (ISO/IEC 26300).