Do you have an TEdit-kind-of input box which support multiple inputs, like this:
ie. when you enter text, it should allow lookup in a TStringList/Event based and when pressing <ENTER> it should add the entry to a "list" inside the Edit box (which you can delete by clicking the "x" or by using Backspace/Delete keyboard button).
Okay, have played a bit with it, and found a couple of things:
If I create a form with just a TAdvListEditor on it and run the program, then click the input box, there's no caret shown in the box, so I can't see that it has focus (but it does have focus, as I can start typing).
In LookupNeedData event, I Assign my own list to the "List : TStrings" parameter and return an ItemIndex based on my own custom search. However, my list isn't sorted alphabetically, so when the program returns from the event, and you immedialtely afterwards do an
FLookupListBox.Sorted := True;
then my returned ItemIndex becomes wrong. You shouldn't enforce a sort, but perhaps do a manual sort before calling the event, and then accept whatever is in the list afterwards.
When I select an item in the popup list, it stays focused (in the edit box), so I have to press <ENTER> twice (first in the popup list, and then on the focused item in the edit box) in order to input the next item. This should be unnecessary (or at least configurable - sorry if it already is :-) )
For the caret, try to increase the height of the control. Windows has the annoying behavior to not show a caret when edit control height in relationship to used font size is too small.
I cannot increase the size - it is fixed at 24 (when AutoSize=TRUE). But even with AutoSize=FALSE and Height=30, there's no caret when initially receiving focus.
From the behaviour I experience, it seems like the TAdvListEditor isn't a TEdit derived component, but some form of container (TPanel/TPaintBox or the like), and that you only create a TEdit component when needed for input. That means that when there's no actual input going on, there's no TEdit created, and thus no caret.
You should also create an empty TEdit when receiving focus/clicking on the containter so that the user can see that it's ready for input OR manually draw a caret when the container component receives focus/is clicked on (and of course remember to remove it once you leave it).
Another suggestion: A "X" icon (perhaps optionally) on each item to enable deleting it using mouse alone. At the moment, you can't remove an item from the list without using keyboard.
I cannot reproduce this
so, please share details: Delphi version, component settings, DPI, ...
You have an X on each item when ShowDeleteButton = true
1 Like
Try removing the "Value 1" value from the Values collection (I have an
AdvListEditor1.Values.Clear;
in my FormCreate, but even without it, I don't get a caret when simply clicking the TAdvListEditor box. NOTE: Do not start typing after clicking).
Windows 10.0.19045 Pro, VCL UI Pack 1.9.2.0, Delphi 11.3 Enterprise Patch 1, Default settings for all components (form, TAdvListEditor), with the above line in my FormCreate event. Mixed DPI (but all interaction done on 96dpi 1920x1080 monitor).
From Help->About:
(and of course VCL UI Pack - don't know why it doesn't show up in the list from Help->About)
I retested this here but I cannot reproduce this.
I suggest to provide a test project so we know all settings & code involved.
Source + compiled executable. Verified that it behaves as described both on my PC and on a colleague's PC.
Tested on two machines, with two different IDEs and problem cannot be reproduced here.
That's really, really weird...
You are just starting the app, and single-clicking on the white area of the edit box? Nothing else, at all?
On two machines here at my work, it does the same (ie. nothing). Only when starting to type something does the caret appear. Did you try the .EXE file or did you try re-compiling the project yourself?
I'll try at my home PC when I get home, and also try installing the latest VCL UI Pack to see if that has anything to do with it...
We compiled your project on 2 machines with 2 different IDEs.
We do not run EXE files for security reasons.
So we don't know if it's my compilation or not...
Same result on home PC with above .EXE file, and with a re-compilation, using the latest, clean-installed VCL UI Pack.
One other symptom: I don't get a new mouse cursor (usually you get the crBeam) when moving the mouse into the area of the edit box. Don't know if I'm supposed to (I should, IMO).
You're free to do a TeamViewer session on my PC so you can see it for yourself (go to DM to excange ID). I know it's sometimes hard to believe if you can't see it for yourself :-) .
That's strange... This one works fine (I don't even need to click the input box, the caret is there right when the program starts).
So it must be something on my three machines (my home PC, my work PC and my colleague's PC) that prevents it from working. I'll try your version on my colleague's PC on Monday when I see him again...
It could be a compiler setting or something else, but until you try running my .EXE on your setup, we really can't determine if it's my .EXE file that is "faulty" or not. You don't have a VM that you can try it out on?
I have updated the main .PAS file with Ctrl+O-O (all compiler options) and have included an .optset file to load. This should ensure that you have the exact same options as my setup.
Please note, that I do a Build and thus also compiles the VCL UI Pack UNITs I use using these options...
Please try to re-compile and see if you can re-create the problem now...
Project158.zip (91.6 KB)
No .EXE file this time...