Lazarus
Programming => Databases => Topic started by: micheus on August 28, 2017, 04:24:10 pm
-
Still translating my eleven years old Delphi project to Lazarus, today I face another issue.
I used a DBLookupComoboBox as a menu like for user to select an item that is used to fill another table, plus two controls to show other item details - see the attached image.
When user hit a Save button I took the KeyValue property to add to the destination table.
I set the ListSource, ListField and KeyField, but the control didn't have its DataSource and DataField set.
Usually - in Delphi - by selecting an item on the dblookuplist its ListSource generates a data change events and the other controls get their content updated in accord with the item selected.
I just found that it doesn't works in Lazarus. I can select any item in the dblookuplist and the other controls never get updated - they stays on the first item value.
By doing this: DBLookupListBox1.Items.ValueFromIndex[DBLookupListBox1.ItemIndex]
I can get the selected text on the list - the ListField, but how could I get the KeyField value?
By doing that I would be able to workaround this issue.
-
I'm using TDBLookupComboBox, everything works as expected.
What exactly doesn't work for you?
Also, your picture shows ListBox, not ComboBox.
but the control didn't have its DataSource and DataField set.
Why so?
-
Yeah, you are right. It's a DBListbox, but the behaviour is that.
"Why so?"
Because I don't need it. I fill that field by my self by reading KeyValue. At least I used to do with Delphi.
It's used like a menu and by selecting one element - usually - makes the listsource fire OnDataChange event. That is not happening with Lazarus.
-
For unbound use You should leave DataSource and KeyField empty.
And if you want the underlying ListSource dataset to scroll with the control you need to set ScrollListDataset to true !!!
-
Because I don't need it. I fill that field by my self by reading KeyValue. At least I used to do with Delphi.
It's used like a menu and by selecting one element - usually - makes the listsource fire OnDataChange event. That is not happening with Lazarus.
Looking at your picture, I would rather use a single-column DBgrid (for list) and any other db-aware controls for the rest of dataset fields, but not any of LookupXXX controls, because there's no "lookup" as such in your case. And this way everything is scrolled automatically.
I don't remember how it is done in Delphi, but scrolling LookupDataset with LookupXXX controls (imo) is not a good idea, especially when there are multiple datasets/fields which are using this single instance of this particular LoookupDataset (what is a typical scenario for a Lookup mechanism).
-
if you want the underlying ListSource dataset to scroll with the control you need to set ScrollListDataset to true !!!
Thanks rvk.
That probably should do what I needed, but unfortunately it's bugged.
Sometimes the "bookmark" (I didn't check how Laz is managing the scrolling in its code) is moved to the wrong record. Sometimes it just don't change and other is pointing to other record.
The video bellow shows the Delphi app working on the left side and the Lazarus one on the right for better understanding what I'm talking about.
https://www.youtube.com/embed/ytz2bpgQfjk
Cheeers
Micheus
-
That probably should do what I needed, but unfortunately it's bugged.
I see what you mean in your video.
Although you should have just showed the Lazarus version and not switched back each time to the Delphi version.
I only noticed at the end of you video the scrolling doesn't happen for only two of your records. Is that correct?
I also noticed your database on the Lazarus version is completely screwed up. You have ? characters. If you are mixing utf-8 with ansi or other encoding here, you can't expect the behavior to be predictable. So first fix the database before checking if the scrolling is correct. If after that the behavior is still buggy we can check if there is something in code that's preventing it from advancing to the next/previous record. (maybe there is an hidden exception due to that faulty encoding)
-
I only noticed at the end of you video the scrolling doesn't happen for only two of your records. Is that correct?
Yes, 1st<->2nd and 4th<->5th.
I also noticed your database on the Lazarus version is completely screwed up. You have ? characters. If you are mixing utf-8 with ansi or other encoding here, you can't expect the behavior to be predictable.
Yeah, the database is still using ANSI charset and WIN1252 collate. And I know Lazarus works with UTF8 - I'm already preparing a conversion script to fix that, but as all table's keys uses Integer values I didn't think it could be a problem at this point of my conversion process.
So first fix the database before checking if the scrolling is correct. If after that the behavior is still buggy we can check if there is something in code that's preventing it from advancing to the next/previous record. (maybe there is an hidden exception due to that faulty encoding)
I'm going do that.
Thanks for your advises.
-
... but as all table's keys uses Integer values I didn't think it could be a problem at this point of my conversion process.
Is it at all possible those two records have the same key/integer value? (record 1+2 and 4+5 have the same key?)
That would defenitly prevent the underlying dataset to scroll to the correct record.
(try adding a db-field displaying the key)
I tested the TDBLookupListBox with a sample dataset and it worked perfectly with scrolling the underlying dataset.
-
Is it at all possible those two records have the same key/integer value? (record 1+2 and 4+5 have the same key?)
That was the case. :(
Thank you so much for force me to take a look at the old Delphi form I still have in a VirtualBox.
For some reason in the conversion process the KeyField was changed from the NOM_PROGRAMA (a text description) to COD_PROGRAMA (integer key). That NOM_PROGRAMA is the same as the ListField property, so now everything is working fine.
That table uses a composed key (COD_ENTIDADE, COD_PROGRAMA), so that was causing the strange behaviour since the COD_ENTIDADE has repeated values for different COD_PROGRAMA. Sorry for not have noticed that.
Thank you rvk! :)