Lime CRM Desktop Client 11.3.4456

Product

Lime CRM Desktop Client

Version

11.3.4456

Date published

2026-05-06

Platform

Windows

Availability

Manual installation, Reference

This is a bug fix release targeting issues reported for 11.3.x.

• Inspector splitter rework. The Fields tab now retains its state when you navigate between records, the inspector splitter supports smooth drag-resize with animated transitions, and the splitter position is remembered per inspector layout.

• Improved field layout in inspectors. Mixed rows that combine a multi-line field (such as a memo or expanded list) with single-line fields no longer leave awkward vertical gaps next to the single-line fields. Inspectors with an expandable field at the bottom now extend that field to fill the remaining space, matching typical form-layout expectations.

• Filter robustness for invalid option values. Pre-existing filters that reference option-set entries no longer present in the data model — values that have been renamed, removed, or otherwise can't be resolved — no longer break the query. Invalid entries are skipped, the surviving values continue to participate, and the filter still runs.

• Filter values resolve across locales and ID formats. Filter values authored against the canonical English label, or stored in the semicolon-wrapped ID form that some integrations produce, are now resolved automatically. The user's active locale no longer has to match the value source.

• Record.Value with mixed-case field names works again. A regression introduced earlier in 11.3 caused Record.Value(“xyz”) (or any other case variant of a field name) to silently return nothing once a different field had been looked up first in the same record. Mixed-case lookups now work consistently regardless of the order they're made in.

• Filter conditions for set-typed fields match whether the value is a single string or an array. Previously the same value resolved to different conditions depending on how it was passed: Field.Value = “Privat” bypassed the option-label lookup that Field.Value = Array(“Privat”) performed. Both forms now produce identical conditions.

• Decimal precision preserved when filtering. Filter values for decimal fields were silently truncated to integer before reaching the query, so fractional values were lost. Decimal values now flow through unchanged.

• Client no longer hangs when scripts modify records during AfterSave. A VBA AfterSave or BeforeSave handler writing back to the record while the underlying record load was still in flight could deadlock the client until it was force-killed. The locking and async-load sequence is now coordinated so the handler proceeds without blocking.

• Refresh in AfterSave handlers no longer deadlocks. A Controls.AfterSave handler calling Controls.Refresh() could deadlock against the still-running save flow. Refresh now defers correctly until the save flow exits and runs from there. A small set of related save-state tracking issues were addressed in the same pass.

• Ambiguous-record errors now identify the offending record. When the duplicate-row check trips during record load, the error now names the class and record ID so the entry can be located in the data. Definitive load errors that previously got absorbed into a generic warning are now surfaced to the user.

• Stability when controls are detached. A null-pointer crash that could occur when fields fired before/after-command events on a control that had already been detached from its inspector is fixed. The previous symptom was a generic “internal error” log entry with no indication of cause.

• Avoided crashes from circular control configurations. When custom inspector layouts placed controls in mutually-referencing arrangements, an internal lookup could recurse and exhaust the stack. A guard now stops the recursion safely.

• Client-side incremental refresh reverted. The incremental refresh optimization shipped earlier in 11.3 produced unexpected load patterns on the backend in production. It is reverted in this build; refresh runs the full query as it did before the optimization. The optimization will be re-introduced once the backend impact is resolved.