Lime CRM Desktop Client 11.3.4874

Product

Lime CRM Desktop Client

Version

11.3.4874

Date published

2026-10-19

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.

• 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.

• 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.