Lime CRM Desktop Client 11.3.4922

Product

Lime CRM Desktop Client

Version

11.3.4922

Date published

2026-10-21

Platform

Windows

Availability

Manual installation, Reference

Correction release for 11.3. It contains everything in 11.3.4747 and the corrections below. 11.3.4747 was the final feature release of 11.3, so its release notes remain the description of what 11.3 contains. This release adds no new features.

• VBA repairs itself for the user when it fails. When VBA cannot start or cannot compile, the client now repairs the VBA registration of the user and asks the Lime Maintenance Service to repair the VBA registration of the computer. This targets the message “Failed to compile VBA.” when it affects only some users of a database.

• Updates never restart the computer on their own, also in the VBA setup. The 11.3.4747 release notes promised this for every component. One case remained: the VBA setup could restart the computer without asking when Office held one of its files during an update. This is now corrected.

• The update service runs only current Lime setups. An old release with a known problem can no longer be brought back and installed through the Lime Maintenance Service.

• Repair of a client for users without administrator rights. TinyRepair is a new, separate download that installs the latest released client through the Lime Maintenance Service.

• VBA keeps working after a restart of Windows. On some computers, VBA worked after an update but failed after the next restart with “One of the VBA components is missing or corrupt.” This is now corrected.

• Records with a duplicated single relation open again. When two related records pointed to the same record through a single relation, the record could not be opened. It now opens, and the relation field shows the problem and how to correct it.

• The Lime Maintenance Service runs only installed modules and recently signed setups. The service runs Lime-signed setups with full rights for any user. It now runs a setup only when the setup is part of a Lime installation on the computer, or when its signature carries a trusted timestamp that is at most 90 days old. A setup counts as installed only when standard users cannot change its folder. This extends the security hardening of the update service in 11.3.4747.

• Automatic updates are confirmed with the build server before installation. Right before an update is installed, the client asks the build server again whether that version is still published in its channel. A version that was withdrawn is not installed, and its download is deleted. When the build server cannot be reached, nothing is installed in this session, and the update is offered again later. The client also checks the signature date of the update with the same 90-day rule as the service, so it no longer offers an update that the service would refuse.

• An install folder outside Program Files is protected. When the client is installed in another folder, for example C:\Lime or a folder on D:, the installer now sets the permissions of that folder: administrators and SYSTEM have full control, and standard users can read and run the files but not change them. An existing installation gets these permissions at its next update. Without them, the update service would not repair such an installation once its build is older than 90 days. Installations in Program Files do not change.

• Error reports of a failed data load no longer contain values from the query. When data failed to load, the error report sent to Lime contained the SQL statement and the query with all values, for example a search text or a personal identity number. The report now contains only the query. Every value in it is replaced by a short code that cannot be translated back to the value, and the name of the filter is removed. Successful loads send nothing.

• The message says what to do when data fails to load. The message “Failed to load data block.” now includes a recommendation for the most common causes. Examples: the sign-in at a proxy in front of the server has expired, the network connection failed, the query took too long, or the user may not read a table. For a table the user may not read, the message names the table and says how to load the data now and how an administrator can give access. For an SQL error, it names the fields of the record type that have their own SQL expression, so that an administrator can check them in LISA.

• The message says what failed when VBA cannot start, and offers to start without the customizations. When the VBA project of the database could not be loaded, the client stopped at login with only the VBA error. The message now says that the VBA project could not be loaded, whether a repair of VBA on the computer was requested, and what to do. It also asks if the client should start without the customizations. No is the default and closes the client, as before. Yes starts the client with an empty VBA project. That project can never be saved, so it cannot replace the VBA project of the database.

• The tooltip of a relation field explains a relation that has more than one related record. See the Fixed section. The technical tooltip (SCROLL LOCK) of every relation field also shows whether the relation is single or multiple, and in which table its key is stored.

• Per-user repair of the VBA registration. Before the VBA project opens, the client checks the registration of VBA, the MSForms controls and the OCX controls that Lime installs, in the part of the registry that belongs to the user. Entries that point to a missing file are removed. After a failed start or compile, the next start also removes per-user entries of the MSForms controls that point to another copy of FM20.DLL. Before the client changes anything, it saves the entries to a backup file in %LOCALAPPDATA%\Lundalogik\Lime\VbaRepair, which restores them by double-click. When the backup cannot be written, nothing is changed. When VBA could not be compiled, the client says that it repairs the registration at the next start, and VBA error messages offer a restart. This happens only once. When VBA still does not compile after the repair, the cause is probably in the VBA project itself, and the client does not offer the restart again.

• Repair of the VBA registration of the computer after a failure. Earlier, the client started the VBA setup only when the VBA component was missing. It now also asks the Lime Maintenance Service to run the VBA setup when VBA fails to start or to compile, at most once an hour per user. The request does not delay the start of the client.

• The VBA setup checks more of the registration. The VBA setup now checks every MSForms control and both MSForms type libraries against the FM20.DLL of Windows, and checks and repairs all 24 compatibility aliases of the VBA controls.

• The client handles the VBA form cache files with more care. VBA keeps cache files (.exd) for the controls that a project uses. A damaged cache file can prevent the project from compiling. The client deleted every cache file it found at every start. It now checks the cache files before the project opens, keeps the files that worked at the last successful compile, and deletes only files that changed or are unknown. When a file cannot be deleted, the error report names the program that holds it.

• The client no longer writes compatibility aliases for VBA controls at every start. The VBA setup already writes them for the computer. The client wrote a copy in the registry of each user at every start, which could hide a later repair of the computer.

• TinyRepair repairs a client for users without administrator rights. A user without administrator rights cannot run the client installer, and a damaged client cannot always update itself. TinyRepair downloads the latest released client from Lime, checks that it is signed by Lime Technologies, and lets the Lime Maintenance Service install it. An older client is upgraded and the same version is repaired. A newer client is never downgraded. When the service is stopped and the user is allowed to start it, TinyRepair starts it. TinyRepair writes each step to its window and to %LOCALAPPDATA%\Lime\TinyRepair.log. Download: TinyRepair.

• The update you agree to install is the version that is recommended now. When you choose to install an update, the client first asks the build server which version is recommended now. It waits at most 10 seconds. When another version is recommended, nothing is installed. The client downloads that version and tells you that it replaces the update. When the build server does not answer, the check before installation decides, as before. When a regular check finds that no update is recommended any more, the downloaded update and its notification are removed.

• Update downloads that are no longer needed are removed. The client keeps update downloads in %TEMP%\Lime\AutoUpdate between sessions. At start it now removes the downloads of the installed version and of older versions. Each answered update check also removes downloads of versions that are no longer recommended. Earlier, these files stayed until the next update was complete.

• Better error reports when VBA fails. The report of “Failed to compile VBA.” now states which repairs the client made and the state of the VBA registration. When a VBA-related component is not registered, the report names it.

• The update notification no longer stays on “Downloading”. From the second update check in a session, the notification showed “Downloading” and was never replaced. This also happened when the download failed or when the update service would refuse the setup, and the notification then stayed for up to 24 hours. A completed download now always replaces the notification. When a download fails or is refused, the update that was offered before is offered again. When there is no such update, the notification is removed. A download from an earlier session is offered right after the first check, without the “Downloading” notification.

• Reports show texts again for option, link, set and yes/no fields. Since 11.3, a field formula in LimeReports, and Record.Eval with lkEvalTypeAuto, returned the stored value of these fields, for example an option key or a record id, where 11.2 returned the text. They return the text again.

• The client could stop responding while a document was saved. When the modified state of a document changed on a background thread while the window was painted, both could wait for each other. This no longer happens.

• The client closes properly when Windows signs out or restarts. When Windows ended the session, the client unloaded VBA without its normal shutdown sequence. This could make the client crash during sign-out or restart. The client now runs the same shutdown sequence as when it is closed.

• SHIFT+F5 refreshes the list also when the filter or view cannot be reloaded. SHIFT+F5 first reloads the filter and the view from the server. When that failed, for example for an ad hoc filter or after the session had expired, the list was not refreshed and an error was shown. The list is now refreshed anyway. The refresh button with SHIFT now does the same as SHIFT+F5.

• Action pads can read ActiveExplorer.Classname again. In 11.3, an action pad that used Lime Bootstrap could read only ActiveExplorer.ClassName. Action pads that check Classname lost menus and buttons that depended on it. Both names now work, as in 11.2.

• An action pad in an inspector could stay empty. In some cases the embedded browser of an action pad was never started when the inspector was shown. The client now starts it when the pane is painted without one.

• Record.Format keeps an unfinished placeholder as text. A placeholder without its closing character, for example A <vbscript:1+1, could add text from outside the string to the result. The opening character is now kept as text, and later placeholders are still translated.

• Record.Eval with an empty VBA string no longer crashes the client. An unassigned VBA string, or vbNullString, made Record.Eval and Record.SafeEval crash. They now report the normal error for an empty expression.

• VBA keeps working after a restart of Windows. An update could remove files that VBA needs, for example the Visual C++ 2010 runtime, while VBA was in use in another session. Windows then deleted the files at the next restart, and VBA failed with “One of the VBA components is missing or corrupt.” The VBA setup now cancels such pending deletions for every file that it installs.

• A record opens when a single relation has more than one related record. A single relation can store its key in the related table. When two related records pointed to the same record, the record could not be opened, and the message named only the record type and the id. The record now opens. The relation field is shown in red with the text “more than one … is linked to this record”, and the field is not saved. A click on the field lists the related records, so that they can be relinked or deleted. When a record cannot be opened for another reason, the message now shows the details of the error again.

• Mass update keeps the updated records in the list and shows their new values. With “Reload list after update” selected, the list was loaded again with its filter after a mass update. Records that no longer matched the filter disappeared from the list. A filter with a question, for example InputBox, asked the question again, and the client could stop responding. The client now reads only the updated records again, without the filter. The records stay in the list with their new values until the list is refreshed. The checkbox is now called “Reload the changed records in the list after update”. For VBA developers: Records.Refresh has a new flag, lkRefreshUnfiltered, which reads the specified records without the filter of the collection.

• Explorer.BeforeCommand and Explorer.AfterCommand give the local name of the field again for update field. Since 11.3, the Parameter of these events for lkCommandUpdateField was an object instead of the local name of the field. VBA code that compared Parameter with a local name failed with error 438, and in some solutions nobody could use update field. Parameter is now an object whose default property is the local name. Code written for 11.2 works again, and code written for 11.3 can still read Parameter.LocalName, Parameter.Name and Parameter.Field.

• A double-click on any tab maximizes or restores the tab pane. When the tabs had their minimum width and the tab strip scrolled, a double-click worked only on one tab.

• Mail files are imported by their contents. A dropped or saved mail file was imported as an Outlook message or as an internet message only from its file extension. A .msg file saved from new Outlook or from another mail program could then fail with “Error importing”. The client now reads the beginning of the file to decide.

• Mail files open and print without classic Outlook. On a computer with new Outlook and without classic Outlook, opening or printing a .msg or .eml document gave a MAPI error. The client now opens and prints such files through Windows, which gives them to new Outlook or to the program for the file type. When the mail viewer cannot print, the client also prints through Windows.

• The client detects 64-bit Outlook correctly. On some computers with both a normal and a Click-to-Run Office registration, the client read the bitness of Outlook incorrectly and started the Outlook integration in the 32-bit host.

• Long document names and network paths work in more places. A document with a long name in a deep folder got a path of exactly 260 characters. Outlook and Windows do not accept such a path, so for example a saved mail with a long subject could not be opened (0x800300FC). Paths are now at most 259 characters, also in lco.MakeFileName. A path that starts with \\ (a network path) also keeps its first two characters.