Issue with NotesUIWorkspace.Prompt on 12.0.2 64/32Bit

Daniele Grillo (grydan.it) has brought to my attention a bug related to HCL Domino Designer 12.0.2 64Bit.
If the NotesUIWorkspace.Prompt method is used in LotusScript with certain types, and the script is created in Domino Designer 12.0.2 64Bit, the function calls do not work in HCL Notes 12.0.2 32bit.
In detail these are the types

  • PROMPT_OKCANCELLIST
  • PROMPT_OKCANCELCOMBO
  • PROMPT_OKCANCELEDITCOMBO
  • PROMPT_OKCANCELLISTMULTI


The issue has been confirmed by HCL Support and is tracked under SPR# PSHECLNFST.

I have created a small database that you can use to test the behavior yourself.


Notes Client 12.0.2 (Danube) – “Workspace_Navigator_Width”

HCL Notes 12 introduced the new Workspace Navigator that replaces the well known tabs at the top to the left sidebar.

You can hide the Workspace Navigator or reduce it’s size to display the tab icons only.

New in HCL Notes 12.0.2 is a notes.ini variable Workspace_Navigator_Width that stores the last size on client shutdown.

As far as I could find out, the default values are

  • 10 (hide/collapse)
  • 55 (tab icons only)
  • 170 (default width )

I prefer the “tab icon” style. The question is: “How can I make the setting persistent?” . If I extend the Workspace Navigator to it’s full size or hide it during a client session, the width would be saved in the notes.ini, and the Workspace Navigator opens with the saved width on next client startup.

I have played with Desktop policy, but found that doing it via policy is not reliable.

panagenda Marvel Client Essentials to the rescue. panagenda Marvel Client Essentials are part of HCL Notes and Domino. Refer to this document to enable the tool in your environment.

Open Marvel Client config and create a new Object -> A5 *.ini & Variables .

Save & close the document. When you now start your Notes Client 12.0.2 the Workspace Navigator will open to the tab icons only state.


Discovering the unexpected is more important than confirming the known

Without question, this quote by the great statistician George E. P. Box certainly applies to software development in general and Beta testing in particular.

Beta testing is one of the most important phases of the software development lifecycle. Quality, performance, stability, security and reliability are some factors that are achieved by doing beta testing.

Beta testing is the best chance to find bugs and usability issues before a product is fully released. While internal testing can uncover many problems, nothing can truly simulate real users trying to complete real tasks.

HCL has released the 2nd code drop of the upcoming release of (Notes)/Domino “Danube” (12.0.2). Every customer with active maintenance can participate in the Early Access Program. The software is available for download at Flexnet. https://hclsw.co/flexnet

There is a forum where you can provide feedback https://hclsw.co/danube-eap-forum .

Tim Clark (HCL) recently said that “We’ve noticed that not many people are trying out the Domino Early Access drop.”

I do not know what the reasons are. I know for sure that Beta testing can be very time consuming. But you do not have to test all the features from a code drop. Test one feature and comment on everything you see or do not see during your test.

If you do not want to setup a machine just for the Beta testing, maybe Docker is an option for you. Daniel Nashed has done a great job providing Docker images for all kind of Domino server environments. https://opensource.hcltechsw.com/domino-container/

There are no guidelines how to do a Beta test. Also there is no “playbook” that gives step-by-step instructions how to test a feature.

It’s all up to you. Be smart, act stupid. Be a rogue. If you can break a feature, anybody can. Better this happens during Beta testing than in production, right?

If a feature works as described. OK. But I can assure you that in all the years I am participating in Beta programs there is always bits and pieces that needs to be changed to make a feature idiot proofed rock solid, make log messages and console output more understandable or improve useability. This all helps to build a great product. And you can be part of the process.

Always keep in mind that discovering the unexpected is more important than confirming the known.