View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004019 | JEDI VCL | 00 JVCL Components | public | 2006-12-13 14:11 | 2007-10-12 03:57 |
| Reporter | chuckj | Assigned To | obones | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | unable to reproduce | ||
| Product Version | 3.20 | ||||
| Target Version | Fixed in Version | ||||
| Summary | 0004019: TJvDBLookupCombo lookup does not work for partially entered integer fields | ||||
| Description | If the TJvDBLookupCombo LookupDisplay property references an integer DB field, the combo dropdown will not track properly as an integer is typed into the edit area. The same problem should exist for any data type where the loPartialKey option of the TDataSet Locate call is not supported. This probably encompasses all non-string data types. | ||||
| Additional Information | I have implemented a fix of sorts and the TJvDBLookupCombo now works better with LookupDisplay referencing an integer field. The fix is to replace the TJvLocateObject.LocateKey function in JvDBUtils.pas with the following code: Result := false; if FLookupField.FieldKind in [fkData, fkInternalCalc] then begin Result := true; case FLookupField.DataType of ftInteger,ftFloat,ftWord,ftLargeInt,ftSmallInt: Result := false; end; end; This code could definitely be improved upon! For my case, this code causes FilterApplicable to return FALSE to TJvLocateObject.Locate when an integer field is used, which causes TJvLocateObject.Locate to use LocateFull, which runs through the entire table converting the integer field to a string to do the partial compare. HELP NEEDED: There remains a smaller issue when using this code. When using a string field LookupDisplay, the partially matching selection in the dropdown remains centered in the dropdown window. When using this fix and an integer field, the partially matching selection now tends to appear at the bottom of the dropdown window, which is not as good. I do not know enough about the lookups to know what determines how the selected field is postitioned in the dropdown window. I have attached a .zip file with a small BDS2006 app which demonstrates the problem. Also included is a copy of JvDBUtils.pas with the suggested fix. | ||||
| Tags | No tags attached. | ||||
|
2006-12-13 14:11
|
JvclComboTest.zip (409,139 bytes) |
|
|
Correction to "Additional Information" section in original report: The line which reads: The fix is to replace the TJvLocateObject.LocateKey function in JvDBUtils.pas with the following code: Should read: The fix is to replace the TJvLocateObject.FilterApplicable function in JvDBUtils.pas with the following code: My apologies!! |
|
|
Does this still happen with the latest version? |
|
|
No answers |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-12-13 14:11 | chuckj | New Issue | |
| 2006-12-13 14:11 | chuckj | File Added: JvclComboTest.zip | |
| 2006-12-13 14:16 | chuckj | Note Added: 0010465 | |
| 2007-06-19 04:33 | obones | Note Added: 0013406 | |
| 2007-06-19 04:33 | obones | Status | new => feedback |
| 2007-10-12 03:57 | obones | Status | feedback => resolved |
| 2007-10-12 03:57 | obones | Resolution | open => unable to reproduce |
| 2007-10-12 03:57 | obones | Assigned To | => obones |
| 2007-10-12 03:57 | obones | Note Added: 0013890 |
